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: <mailto:ant-user-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:ant-user-help@;jakarta.apache.org>
