I have been working on assembling geronimo using the packaging and
assembly plugins. This gives us the ability to put together versions
of geronimo with different capabilities without duplication. For
instance, we now have a jetty-only and a tomcat-only version of
geronimo. To build these,
cd configs;maven -o multiproject:install; cd ..
cd assemblies/j2ee-jetty-server;maven -o;
cd ../j2ee-tomcat-server:maven -o
This relies on using the packaging plugin, which builds configurations
and puts them into the local maven repository. As such, it uses the
maven id as the configId: they typically look like
${groupId}/cars/${artifactId}-${pom.currentVersion}.car
I think this is a big improvement over the unsystematic hand-invented
ids we have been relying on up to now, but it is a backwards
incompatible change that will require changing any plan that mentions a
parentId (many plans do not need to: the builders include default
parents sufficient for the geronimo classes needed for the app to
load). It will also require changing the <module> element in gbean
references that include them.
I think we should just go ahead with the change, and announce it
loudly. We could provide "adapter plans" with no content of any kind
that have e.g. a configId of org/apache/geronimo/rmi-naming and a
parentId of geronimo/cars/geronimo-rmi-naming-1.0-SNAPSHOT.car. This
would allow plans that have only old-style parentIds to deploy
successfully, but would not help with the gbean references.
I beileve in a slightly related development we are planning to change
the groupId to org.apache.geronimo before v1. Doing these changes more
or less at once might reduce confusion.
Comments? Objections?
thanks
david jencks
