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]
