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 > >