ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From George_Schl...@ssga.com
Subject Re: "Elements of Ant Style": the ./lib directory
Date Sun, 03 Nov 2002 13:20:13 GMT

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


Mime
View raw message