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>
