geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david_jen...@yahoo.com>
Subject Re: Jetty and Tomcat builds
Date Sun, 24 Jul 2005 17:01:41 GMT
+100

Is this something you plan to work on or should someone else pick this 
up?  Do you think this can get into M5/get done by mid-august?

thanks
david jencks

On Jul 23, 2005, at 8:08 AM, Jeremy Boynes wrote:

> 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