I wouldn't make a determination based on quantity of version numbers, rather it should be based on intent/purpose.
If at the war level you want to control precisely what versions and/or what exclusions dependencies have...then DM at that level is the way to go. Conversely if you are okay with the child modules/jars specifying dependencies/versions/exclusions the war will end up with jars that follow the maven dependency/transitive rules which are based on 'closest' wins. -Dave On Tue, Mar 9, 2010 at 11:55 AM, Ron Wheeler <[email protected] > wrote: > Dennis Lundberg wrote: > >> On 2010-03-09 15:52, Ron Wheeler wrote: >> >> >>> I am interested in getting some feedback on a route that I am leading my >>> group down. >>> The prevailing opinions range from "innovative" to "no one else is crazy >>> enough to do it like that". >>> >>> The project is a portal (http://www.napaexcellence.ca) that consists of >>> many separate WAR files tied together in a Jetspeed portal. >>> The project is built on Spring, Hibernate, MySQL and Tomcat with >>> Jetspeed providing access to portal information about users, groups, >>> roles, etc. The webservices use CXF. >>> The project depends on about 60 third party jar files. Most of them >>> shared by several projects. >>> >>> We started out with every project having its own libraries but have >>> gradually moved to sharing libraries in Tomcat's shared library folders. >>> We are moving from Tomcat 5.5 to Tomcat 6 so sharing has become a bit >>> easier. >>> >>> I am trying to control the versions of libraries in use since multiple >>> versions of the same library cause a great deal of grief from time to >>> time. >>> >>> I have come up with the idea of using maven POM files more intensively >>> to build the shared libraries. >>> >>> I have created a hierarchy of POM files. >>> >>> There is a pom describing the Tomcat and jsp libraires. The Tomcat >>> libraries are of course provided and the POM creates a jar containing >>> the 3 other jars. >>> Hibernate and MySQL are described in a POM (added in jtds since we also >>> need to hit a MS-SQL database in some applications) >>> Spring, CXF, JSF and Jetspeed each have their own POM >>> There is a big POM of the miscellaneous libraries with 20-30 jar files >>> identified. >>> There are POM files that pull together common combinations such as >>> Tomcat, Spring, Hibernate, MySQL through transitive dependency on the >>> individual POMs. >>> >>> The biggest task is to properly identify the versions in use and set up >>> the exclusions for third party dependencies so that only 1 copy of >>> libraries in transitive dependencies get included (commons-*, log4j, >>> velocity, etc.). >>> >>> My goal is to get everyone using the same version of things to build >>> their portlets. >>> >>> >> >> You can accomplish this by defining all of your dependencies (with the >> version you want to mandate) in the <dependencyManagement> section of >> your top parent POM. The you can remove the <version> from dependencies >> in all the child POMs. >> >> >> >> > That was one of the ideas that we kicked around. > I thought that this would result in a huge list of 60+ version numbers in a > single file that would be harder to manage then a smaller specific list in > the pom that covered the functional area and included all of the information > about the library(version, exclusions). > > On the plus side, your suggestion does make the child poms more stable > since a change at the master level will propagate to the children. > > Which of these these approaches would the forum recommend as a "best > practice". > > > I also want to simplify the POMs of the individual projects to make new >>> projects easier to start. >>> I expect that we will get a bit of a performance improvement on startup >>> since fewer files will be opened to get the jars required to run the >>> whole portal. Each project WAR file will also be much smaller since it >>> will only carry its own code. >>> >>> As an aside, running the Nexus repository has been a really great help >>> in getting this approach organized. >>> >>> Any comments would be appreciated (specially those in favour of my >>> approach ;-) ). >>> >>> Thanks to everyone who contributes to the forum. It is a great place to >>> get advice. >>> >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> >>> >>> >>> >> >> >> >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
