You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@ant.apache.org by Ken Gentle <j....@acm.org> on 2002/11/02 19:07:24 UTC
"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!
Having used ant for several years now on varying sized projects, I was very
interested in the section on "Elements of Ant Style" (Appendix D) to see
how the conventions I've learned/developed stack up against the experts.
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.
I've always resisted putting libraries into SCM for a particular project,
especially if there are related projects that share those same
dependencies. I tend to install the libs to a single location (/opt/lib
and /opt/tools (lib for run-time dependencies, tools for, well, tools!)),
then share that location so that is accessible by all developers and
development boxes. If a developer wants a local copy to improve access
times, OK, but it is the developer's responsibility to keep up with changes
to the "authoritative" source (Y.O.Y.O.M.F.) A single Ant properties file
is all that is needed per project to pull in the appropriate version of a
lib from the right place.
Including the libs with each project, and having all of that under SCM,
seems to be wasteful of bandwidth and disk space. These libraries don't
change often relative to project source code, and things that don't change
shouldn't be under SCM -- they're documented as external
dependencies. I've worked from repositories that include the "lib" dir as
described and suffered through CVS bringing down the whole 5+ mb lib dir
over a slow link -- especially when I already have a copy of the lib
locally. It also seems to encourage deploying and distributing these
dependent libs, giving us yet another flavor of "DLL Hell".
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?), and the
other senior guy on the team leans towards including the "lib" stuff in the
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.
So what is the general consensus? Include them or not? Please explain the
reasoning or experience that made you lean one way or the other.
Thanks in advance!
Ken
P.S.: This idea (distributing/SCM'ing the lib dependencies) seems so
reminiscent of the static versus dynamic linking debate for compiled
languages in the 80's. Static linking resolves all dependencies during the
build, but bloats the executable -- dynamic linking reduces code size and
enables more re-use of resources, but introduces dependencies on the
environment.
P.P.S: Seems to be rearing its head again in the J2EE space (include all
the dependencies in the war/ear jar).
=============================================================
J. Kenneth Gentle (Ken) | Email: j.kenneth.gentle@acm.org
=============================================================
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: "Elements of Ant Style": the ./lib directory
Posted by Steve Loughran <st...@iseran.com>.
----- Original Message -----
From: "Kendall Collett" <kc...@convio.com>
To: "Ant Users List" <an...@jakarta.apache.org>
Sent: Saturday, November 02, 2002 10:40
Subject: Re: "Elements of Ant Style": the ./lib directory
> From the perspective of performing builds, I prefer to have all the
> libraries under SCM (except for those intimately tied with the JDK like
> rt.jar). The primary reason is that I think it makes the build more
> repeatable by reducing dependencies on the environment in which the build
is
> being performed. For example, you don't have to worry about a build break
> where some developer checks in code which builds in their environment
(e.g.
> because they have a more recent copy of some library). If you have all
the
> non-JDK libraries under SCM, then you can specify "ignore" for
> build.sysclasspath and pretty much avoid this scenario.
yes, this is v. important when you start working with daily builds of things
like Axis or struts, or even xdoclet. You need to be able to roll back your
entire app to a version that worked, and that means versioning all that it
depends on.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: "Elements of Ant Style": the ./lib directory
Posted by Kendall Collett <kc...@convio.com>.
>From the perspective of performing builds, I prefer to have all the
libraries under SCM (except for those intimately tied with the JDK like
rt.jar). The primary reason is that I think it makes the build more
repeatable by reducing dependencies on the environment in which the build is
being performed. For example, you don't have to worry about a build break
where some developer checks in code which builds in their environment (e.g.
because they have a more recent copy of some library). If you have all the
non-JDK libraries under SCM, then you can specify "ignore" for
build.sysclasspath and pretty much avoid this scenario.
In terms of packaging (or not packaging) libraries for distribution with the
product, I think that's a different, more complicated problem.
Kendall
PS: In my experience, I don't find bandwidth limitations to be that much of
an issue; since the libraries don't usually change, "cvs update" usually
doesn't have much to do.
----- Original Message -----
From: "Ken Gentle" <j....@acm.org>
To: <an...@jakarta.apache.org>
Sent: Saturday, November 02, 2002 12: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!
>
> Having used ant for several years now on varying sized projects, I was
very
> interested in the section on "Elements of Ant Style" (Appendix D) to see
> how the conventions I've learned/developed stack up against the experts.
>
> 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.
>
> I've always resisted putting libraries into SCM for a particular project,
> especially if there are related projects that share those same
> dependencies. I tend to install the libs to a single location (/opt/lib
> and /opt/tools (lib for run-time dependencies, tools for, well, tools!)),
> then share that location so that is accessible by all developers and
> development boxes. If a developer wants a local copy to improve access
> times, OK, but it is the developer's responsibility to keep up with
changes
> to the "authoritative" source (Y.O.Y.O.M.F.) A single Ant properties file
> is all that is needed per project to pull in the appropriate version of a
> lib from the right place.
>
> Including the libs with each project, and having all of that under SCM,
> seems to be wasteful of bandwidth and disk space. These libraries don't
> change often relative to project source code, and things that don't change
> shouldn't be under SCM -- they're documented as external
> dependencies. I've worked from repositories that include the "lib" dir as
> described and suffered through CVS bringing down the whole 5+ mb lib dir
> over a slow link -- especially when I already have a copy of the lib
> locally. It also seems to encourage deploying and distributing these
> dependent libs, giving us yet another flavor of "DLL Hell".
>
> 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?), and the
> other senior guy on the team leans towards including the "lib" stuff in
the
> 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.
>
> So what is the general consensus? Include them or not? Please explain
the
> reasoning or experience that made you lean one way or the other.
>
> Thanks in advance!
>
> Ken
>
> P.S.: This idea (distributing/SCM'ing the lib dependencies) seems so
> reminiscent of the static versus dynamic linking debate for compiled
> languages in the 80's. Static linking resolves all dependencies during
the
> build, but bloats the executable -- dynamic linking reduces code size and
> enables more re-use of resources, but introduces dependencies on the
> environment.
>
> P.P.S: Seems to be rearing its head again in the J2EE space (include all
> the dependencies in the war/ear jar).
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: "Elements of Ant Style": ant files separation
Posted by Steve Loughran <st...@iseran.com>.
My recommendation is
-break your project into sub projects at sensible places, each with their
own deliverable (jar, ear, docs) that can be tested
-have a build file for each sub project
-have a master build file for the whole thing, using <ant> to call down
-use XML includes to pull in common declarations across all build files.
-have helper build files for common tasks, these files are like subroutines
that take parameters as properties and do things for the big files. e.g.
javadoc, jmxdoclet,
-use junit report to build a big fancy report of the entire test run. people
love that.
----- Original Message -----
From: "Emerson Cargnin - SICREDI Serviços" <em...@sicredi.com.br>
To: "Ant Users List" <an...@jakarta.apache.org>
Sent: Monday, November 04, 2002 8:47 AM
Subject: Re: "Elements of Ant Style": ant files separation
I'd like to make question about the architecture of ant files:
I have a big financial system, with a lot of modules, so we planned to
separate the big build file into smaller build files, what should be the
preffered way
- creating one build file for each module
- creating one build file for each layer, say, web, ejb, eyc...
I prefer the first approache, but the people here seems to preffer the last.
And if i use the first, how to keep what not change in a single build
file and let each module keep just what changes? I know i can have
build.properties file to separate properties that change, but it doesn't
extend to different targets....
I saw the fisrt approache at jboss project.
One problem with the first approache is when you use CMP entities that
have CMR's, becouse it need to be deployed in a single ejb-jar.xml
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: "Elements of Ant Style": ant files separation
Posted by Emerson Cargnin - SICREDI Serviços <em...@sicredi.com.br>.
I'd like to make question about the architecture of ant files:
I have a big financial system, with a lot of modules, so we planned to
separate the big build file into smaller build files, what should be the
preffered way
- creating one build file for each module
- creating one build file for each layer, say, web, ejb, eyc...
I prefer the first approache, but the people here seems to preffer the last.
And if i use the first, how to keep what not change in a single build
file and let each module keep just what changes? I know i can have
build.properties file to separate properties that change, but it doesn't
extend to different targets....
I saw the fisrt approache at jboss project.
One problem with the first approache is when you use CMP entities that
have CMR's, becouse it need to be deployed in a single ejb-jar.xml
Steve Loughran wrote:
> ----- Original Message -----
> From: "Ken Gentle" <j....@acm.org>
> To: "Ant Users List" <an...@jakarta.apache.org>
> Sent: Monday, November 04, 2002 6:18 AM
> Subject: Re: "Elements of Ant Style": the ./lib directory
>
>
>
>>At 11:01 PM 11/3/2002 -0800, you wrote:
>>
>>
>>>----- Original Message -----
>>>From: "Ken Gentle" <j....@acm.org>
>>>To: <an...@jakarta.apache.org>
>>>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.
>
>
> I know, I was just teasing. And its nice to see people going into the
> details of the book and seeing how well it aligns with their own thoughts
> and experience, because having been through different projects, you will
> know different things which work/dont work.
>
>
>>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).
>
>
> that makes sense. Provided there is enough info in there to get (maybe
> build) the versions of dependent libs used in with any build, you dont need
> your own copies.
>
>
>>>>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... ;^)
>
>
> yup
>
>
>>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.
>
>
> If you have another way of storing dependency info in SCM, *and* propagating
> changes out to all the team, then go for it -and tell us what you did.
>
> -steve
>
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
| Emerson Cargnin |
| Analista de Sistemas Sr. |
| Tel : (051) 3358-4959 |
| SICREDI Serviços |
| Porto Alegre - Brasil |
|xxxxxxxxxxxxxxxxxxxxxxxxxx|
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: "Elements of Ant Style": the ./lib directory
Posted by Steve Loughran <st...@iseran.com>.
----- Original Message -----
From: "Ken Gentle" <j....@acm.org>
To: "Ant Users List" <an...@jakarta.apache.org>
Sent: Monday, November 04, 2002 6:18 AM
Subject: Re: "Elements of Ant Style": the ./lib directory
> At 11:01 PM 11/3/2002 -0800, you wrote:
>
> >----- Original Message -----
> >From: "Ken Gentle" <j....@acm.org>
> >To: <an...@jakarta.apache.org>
> >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.
I know, I was just teasing. And its nice to see people going into the
details of the book and seeing how well it aligns with their own thoughts
and experience, because having been through different projects, you will
know different things which work/dont work.
> 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).
that makes sense. Provided there is enough info in there to get (maybe
build) the versions of dependent libs used in with any build, you dont need
your own copies.
> > > 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... ;^)
yup
> 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.
If you have another way of storing dependency info in SCM, *and* propagating
changes out to all the team, then go for it -and tell us what you did.
-steve
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: "Elements of Ant Style": the ./lib directory
Posted by Ken Gentle <j....@acm.org>.
At 11:01 PM 11/3/2002 -0800, you wrote:
>----- Original Message -----
>From: "Ken Gentle" <j....@acm.org>
>To: <an...@jakarta.apache.org>
>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
>the
> > 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
project/product.
Ken
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: "Elements of Ant Style": the ./lib directory
Posted by Steve Loughran <st...@iseran.com>.
----- Original Message -----
From: "Ken Gentle" <j....@acm.org>
To: <an...@jakarta.apache.org>
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 :)
> 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.
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.
>and the
> other senior guy on the team leans towards including the "lib" stuff in
the
> 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.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: "Elements of Ant Style": the ./lib directory
Posted by Erik Hatcher <ja...@ehatchersolutions.com>.
Ken Gentle wrote:
> While I haven't (yet) gone to the level of defining a version property,
> this is what is spec'ed in the properties file - one or more "jars",
> including version information in the path (usually).
The .version properties are just the way I developed doing it, but
again, nothing wrong with defining it your way. I do need two
properties for some libraries, such as Struts. The TLD and DTD files
are needed, so I use struts.dir and struts.version. I define both a
.dir and .jar (and .version too) for all libraries, but the only one
that is used in the build for most is a .jar property.
> I'd already pulled CruiseControl (and gotten it into the environment) to
> use as a CI engine, when I revisited Maven (prompted by a Javaworld
> article, maybe?) Maven looks really nice -- maybe it'll be worth the
> effort to switch over...
For the record, I've still not used Maven other than to try it out to
build some of the Commons projects that require it now.
> No argument there -- but since we're all going to be generating them
> with XDoclet (Ch. 14!) now, there will be a lot less pain! (My
> compatriot is pushing this one - I've never used it, but is has to be
> better than maintaining all those descriptors by hand!)
XDoclet, yeah baby! A subject dear to my heart. I'm using it full-on
in our builds and its working very nicely. The 1.2beta release is quite
a nice improvement. Its not without its share of caveats, though, but
I'd never do EJB without it. And its great for one-off passive
generation (I generate starter Struts JSP and corresponding field label
resource definitions with it).
If you are maintaining descriptors by hand, run, don't walk, to your
nearest web browser and download and try XDoclet.
Erik
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: "Elements of Ant Style": the ./lib directory
Posted by Ken Gentle <j....@acm.org>.
Wow, Erik, now that's service!
At 01:25 PM 11/2/2002, you wrote:
>Ken Gentle wrote:
>
>>locally. It also seems to encourage deploying and distributing these
>>dependent libs, giving us yet another flavor of "DLL Hell".
>
>Agreed, to some extent. But have a look at Chapter 8 in our book to see
>how I organize library directories such that I don't simply have an
>unstructuring dumping ground called "lib". Its an organized tree of 3rd
>party libraries allowing me to easily switch between library versions by
>simply saying -Dstruts.version=1.1b2 for example.
While I haven't (yet) gone to the level of defining a version property,
this is what is spec'ed in the properties file - one or more "jars",
including version information in the path (usually).
>>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.
>
>Have a look at Maven. It maintains a 'lib.repo' directory and
>automatically pulls down dependent libraries if you don't have them.
I'd already pulled CruiseControl (and gotten it into the environment) to
use as a CI engine, when I revisited Maven (prompted by a Javaworld
article, maybe?) Maven looks really nice -- maybe it'll be worth the
effort to switch over...
>>P.P.S: Seems to be rearing its head again in the J2EE space (include all
>>the dependencies in the war/ear jar).
>
>Yes, I have issues with the WAR/EAR thing too - I've not had success
>deploying some dependencies in one place in an EAR and it seems some are
>needed in both the EAR and sub-WAR's too.
>
>I think J2EE suffers more from DD-hell... deployment descriptors, that is. :)
No argument there -- but since we're all going to be generating them with
XDoclet (Ch. 14!) now, there will be a lot less pain! (My compatriot is
pushing this one - I've never used it, but is has to be better than
maintaining all those descriptors by hand!)
> Erik
>
>
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
=============================================================
J. Kenneth Gentle (Ken) | Phone: (610) 255-0361
Gentle Software, LLC | Email: j.kenneth.gentle@acm.org
=============================================================
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: "Elements of Ant Style": the ./lib directory
Posted by Erik Hatcher <ja...@ehatchersolutions.com>.
Ken Gentle wrote:
> I've finally received my copy of "Java Development with Ant", and want
> to thank Steve and Erik for a great reference!
Thank you, Ken.
> 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.
Let me just clarify a little first. I do not advocate keeping the same
JAR file in SCM multiple times. A global/master 'lib' directory that
spans across all projects is plenty sufficient and in fact this is how I
organize our SCM in my day job.
I'm by no means so hard core about this particular 'element' that I
can't see your side of things - and there is nothing wrong with doing it
your way, of course. I like being able to simply configure SCM access
on a machine and then have everything needed (since I also put Ant
itself into our SCM!). Once I pull a project from SCM, I 'install' Ant
by pointing to what I just checked out.
> locally. It also seems to encourage deploying and distributing these
> dependent libs, giving us yet another flavor of "DLL Hell".
Agreed, to some extent. But have a look at Chapter 8 in our book to see
how I organize library directories such that I don't simply have an
unstructuring dumping ground called "lib". Its an organized tree of 3rd
party libraries allowing me to easily switch between library versions by
simply saying -Dstruts.version=1.1b2 for example.
> 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.
Have a look at Maven. It maintains a 'lib.repo' directory and
automatically pulls down dependent libraries if you don't have them.
> So what is the general consensus? Include them or not? Please explain
> the reasoning or experience that made you lean one way or the other.
I say keep them in SCM, but not necessarily under each project. If
there are compelling reasons in your project/environment that make this
a bad idea, by all means adjust your process. After all, I'm agile, so
I'll go with the flow! :)
> P.P.S: Seems to be rearing its head again in the J2EE space (include all
> the dependencies in the war/ear jar).
Yes, I have issues with the WAR/EAR thing too - I've not had success
deploying some dependencies in one place in an EAR and it seems some are
needed in both the EAR and sub-WAR's too.
I think J2EE suffers more from DD-hell... deployment descriptors, that
is. :)
Erik
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: "Elements of Ant Style": the ./lib directory
Posted by Ge...@ssga.com.
So what is the general consensus? Include them or not? Please explain the
reasoning or experience that made you lean one way or the other.
(Disclaimer:this is the IMHO of relative newbie to all this)
Though I'm no fan of keeping libraries and other binaries in SCM, I am
starting to like the idea of a "common" project in the repository, where
all thirdparty and common libs are kept in a standard structure. An owner
of each lib can be determined, and they can import new versions and
tag/label them appropriately with a version tag (e.g. XALAN_2_4_1). Each
projects that needs such libraries then controls which versions of the libs
are used for particular versions of their products via tagging the libs
with the same product version tags that they use for their source (for
example, PROJECT1_3_4_0_DEV could be applied to xalan.jar version that is
tagged XALAN_2_4_1 ). Using CVS, it is easy to create an alias module for
each project that pulls appropriate stuff from the common project and from
the actual project. As a release manager (or anyone really), I just check
out my PROJECT1 module with the appropriate project tag (using ant
buildfile to do this makes things even nicer), and I get all the right
stuff. As a developer, I can update the "common" or "lib" part of my
checked out project with the project-version tag (or to make things even
easier, there is a CVS patch that allows a module to be created with a -r
tag option) (again, using ant to make this happen is even nicer).
The summary is that there is one location for all the common stuff that can
be managed centrally, and each project just needs to tag the right version
of the components they need. Though this is taking space in the repos, and
there is some added downloading, it is only 1 copy of each version of
common stuff that everyone draws from (rather than 1 in each project of
unknown origin and questionable version), so it is relatively easy to
manage, easy to look at the common part of repository and see what versions
of common libraries and components that each project uses (facilitiates
impact analysis for changes), and it is easy to troubleshoot library
version issues. This setup has also helped on several occasions when we
have had to modify/add on to some open source packages- it is easy and
non-intrusive to make a branch to do so. It also allows for more standard
ant build files (in that each project finds common stuff the same way). I
am not extremely fond of how many projects (especially the J2EE ones) each
include their own copies of such libs in their WAR's EAR's, etc., but I
believe that the current state of J2EE app architecture and proprietary
nature of appservers, IDE's etc. is such that it is very difficult to
manage external library dependencies - at least I can't figure out a real
simple solution to it (thus my motivation for the above setup). There may
be shortcomings that others will no doubt bring up, but I haven't run into
them. I hope I understood the question, and that this is useful.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>