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
