I assume it will be the case that the configId declaration in the file
will therefore control which repository location the CAR is installed
in -- so if you change the configId, it changes the install location.
Is that correct?
Here are my issues:
- It's a pretty significant change for the "last gasp before 1.0". I
would *really* prefer to hold off on this so we have some time to
think it through and work with it a bit longer before committing to it
as the future, but I'm afraid that you won't deliver separate
Jetty/Tomcat builds without it. What do you think?
- I want to make sure that application configIds or configIds for
services created by the user (e.g. database pools, security realms)
can still be anything at all ("foo") and don't have to follow the
Maven style naming. Further, I don't think that not using Maven-style
configIds for your application should limit your capabilities in any
way (no, "can't deploy to a cluster if you can't use the packaging
plugin if you didn't use Maven-style configIds" or anything like that)
- Along those line, are you proposing that this is the only way to
handle CAR import or export? That isn't my sense. I thought the
original plan was to import/export content from the Config Store
directly. I'm not really sure when the repository got involved, but
I'd like to hear the case for it. I mean, if I deploy application
foo, and it goes into directory 14 in the config store, can't we just
have a tool that zips and exports directory 14 as "foo.car" and then
another tool that imports "foo.car" as directory N+1 in the config
store of the destination? I'm not saying that's right or you're
wrong, it's just this kind of thing that makes me think I'd really
prefer to work through this in detail at ApacheCon rather than putting
in the change at the last second before 1.0.
- On a parctical note, I'm afraid the config IDs will become too long
for the deployer to fit on a single line, and it would make the
list-modules view pretty terrible (any chance we can establish a
policy of omitting the groupId if it happens to be org.apache.geronimo
and leaving out the "type" since IIUC it will always be "car"?)
If you go ahead, do you have a sense for how long it would take to
implement and test the change?
Thanks,
Aaron
On 11/18/05, David Jencks <[EMAIL PROTECTED]> wrote:
> 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
>
>
