ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ken Gentle <>
Subject Re: "Elements of Ant Style": the ./lib directory
Date Mon, 04 Nov 2002 14:18:11 GMT
At 11:01 PM 11/3/2002 -0800, you wrote:

>----- Original Message -----
>From: "Ken Gentle" <>
>To: <>
>Sent: Saturday, November 02, 2002 10:07
>Subject: "Elements of Ant Style": the ./lib directory
> > I've finally received my copy of "Java Development with Ant", and want to
> > thank Steve and Erik for a great reference!
>we love positive feedback
> >
> > I'm generally in agreement with these suggestions, but one stands out as
> > diametrically opposed to my common practice.  in section D.4.5, Directory
> > Structure, the recommendation is to keep library files "with the
> > project".  As most projects are managed from some type of SCM tool, that
> > kind of implies keeping those lib/jars in the SCM system.
>not so sure about this kind of feedback tho :)

That's not negative feedback - or it wasn't intended to be.  I was not 
trying to say the practice is bad, or wrong, but that I've used other 
methods to achieve similar results without incorporating jars/olb/.a files 
in the repository.

> > It also seems to encourage deploying and distributing these
> > dependent libs, giving us yet another flavor of "DLL Hell".
>I'd define DLL hell as the mess of support problems you'd get by not
>controlling all dependent libraries, but instead taking what you got, the
>counterpoint to that was when some app overwrote a lib with a different
>version of a needed library. Static linking to MFC was a good way of
>reducing this effect.

Understood.  I'm not advocating "taking what you got", but instead of 
including the libs in the repository, why not include only the information 
about the dependency and pull things together for inclusion at 
deployment/distribution time (or not - one might also include the list of 
dependencies as part of the distribution as installation pre-requisites).

>Java can have the same problem, and a special mention must go out here to
>the version of Oracle client software I installed that went and gave me a
>java 1.1. install, complete with .jar bound to that version, despite java1.3
>being present. Second mention goes to the Java1.3 runtime that deletes the
>binding of .jar to java1.4 in the registry when you uninstall it *after*
>installing java1.4. Then there was the time that tomcat had an ant.bat in
>tomcat/bin, which was in the path ahead of ant/bin...
> >
> > I'm in the process of setting up the build environment for a new
> > employer/project (why do *I* always seem to end up doing this?),
>Because (a) you secretly enjoy it or (b) you dont trust anyone else.

Ouch -- that was a rhetorical question.  I don't particularly care for it, 
so it must be that "trust" thing... ;^)

> >and the
> > other senior guy on the team leans towards including the "lib" stuff in
> > project SCM.  I'm willing to be talked out of my bias, I think, but I'd
> > like to hear some other opinions and practices around dependent libs.   I
> > know that I'm tired of having yet another copy of jaxp/xalan/xerces
> > downloaded with every new open source project I'd like to use.
>There is a lot to be said for a skinny redist as well as a fat redist, but
>that doesnt mean you dont need SCM control of your libraries.

I need SCM to record the changes in my source and its dependencies.  That 
doesn't necessarily mean I have to keep the libs themselves under SCM.

Thanks for your "feedback".  I'll have to give this some more thought.  It 
will certainly go in the "toolbox" for consideration for the next 


>To unsubscribe, e-mail:   <>
>For additional commands, e-mail: <>

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message