Good points.
The dependency management was mentioned earlier.
Perhaps my staff was right on that one :-) . I am being outvoted 2-0.

See below for my comments.

Ron

David Hoffer wrote:
Ron,

A couple of thoughts come to mind.  Dependency management will go a long way
towards solving your version issue (and also custom excludes rules).
We use excludes in the library poms to exclude older versions of transitive dependencies of libraries that we use.
 Also
since it sounds like you have lots of wars, could you create an ear using
it's shared lib folder?  Maven has good support for that too.  You could
deploy in JBoss or suitable container.
We are using Spring and Tomcat rather than JBoss so I think that we need WAR files. These are deployed as separate projects. They are currently on the same machine as the main portal Engine (Jetspeed) but could be deployed on Tomcat on another server and used remotely if we need that level of scalability.

We do have our own sharable library jars that we build in their own projects and deploy as shared libraries in the Tomcat lib.

-Dave

On Tue, Mar 9, 2010 at 7:52 AM, Ron Wheeler
<[email protected]>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.
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]

Reply via email to