geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Boynes <jboy...@apache.org>
Subject Jetty and Tomcat builds
Date Sat, 23 Jul 2005 15:08:19 GMT
There was some brief chatter on IRC about doing both Jetty and Tomcat 
builds automatically and having a separate dist directory. I just wanted 
to take the opportunity to remind folk about the packaging and assembly 
plugins and what they were trying to achieve.

Sometime last year we discussed replacing the assembly module and its 
huge maven script with a more modular structure that separated out the 
deployment steps from the final assembly. Each plan would be built as a 
distinct maven module (under the configs top-level directory) and then 
these pre-built configurations would be assembled together into various 
distributions (under the assemblies directory).

The packaging plugin supports the first step: it runs within maven, 
converting deployment plans to configuration bundles as output artifacts 
which get placed in maven's repository. Maven's dependency system 
ensures that they get built in the right order.

The assembly plugin supports the second step: assembling a final 
distribution out of artifacts (both dependencies and pre-built 
configuration bundles) taken from the maven repo.

These were intended to support things like different Jetty vs. Tomcat 
builds by allowing the Jetty or Tomcat bits to be placed in their own 
plans that could be packaged once and used in different distributions as 
needed.

I made a start on this in the Spring but ran into a couple of bugs in 
the kernel:
* Dependency information is lost for executable configs and this
   prevents the maven-based builder from loading the tree properly.
   At runtime these depdencies are loaded from the manifest classpath,
   but at build time the relative paths can't be resolved properly

* The regular deployer works around this by using the classloader
   that loaded the Configuration class as the root of the classloading
   tree. This works when everything is using the same dependencies (and
   the same versions of them) but does not allow cross-version builds
   (which can happen when the packager is running as a plugin).

* The classloading tree is not flexible enough to allow the Jetty/Tomcat
   specific components to be broken out into separate bundles. Some form
   of import/export mechanism similar to OSGi's is needed.

These aren't hard but are pretty low-level and it didn't seem a good 
idea to start messing in these areas on the run up to CTS. Given the 
recent issues with trying to get two distributions going it might be 
worth reopening them.

--
Jeremy

Mime
View raw message