David Hoffer wrote:
I wouldn't make a determination based on quantity of version numbers, rather
it should be based on intent/purpose.
Good point.
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.
I want to avoid the WARs getting their own versions of shared libraries
since the libraries are shared and having a number of different version
of the same jar causes unnecessary complications and intermittent
errors, specially if they end up in the Tomcat shared library folder.
For non-shared jars, I expect the WAR project to specify the dependency
that it needs and the author/maintainer to be responsible for any
maintenance to that dependency.
Currently the webapp projects depend on poms rather than jars for their
shared dependencies. That means that if your project requires Spring
(they all do) then you declare a dependency on the right version of our
company's Spring POM that sets the "approved" version for Spring and has
all the exclusions that we need to avoid conflicts with other shared
libraries that we have installed in the Tomcat lib.
This should avoid the "closest win" rule having a bad outcome.
Once again, thanks for the comments.
Ron
-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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
