To me the biggest problem here is still backwards compatibility and
if/how we can support it. Dain suggested (privately) that we might
have a conversion table for our configids so that an old plan would
still deploy. This is possible but really ugly. I will look into just
how ugly :-) I'd certainly appreciate any other opinions on how
serious a problem this is and what we can do about it.
Now to more specific responses:
On Nov 18, 2005, at 6:59 AM, Aaron Mulder wrote:
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?
well, maybe. The packaging plugin is the only way currently to get a
car file into a maven-like repository, and it only uses the actual
maven repository at the moment. The identity of path inside the maven
repo and configId is currently a convention, but IMO a really good one.
I'd like to see if a packed-car repository config-store works, but I
doubt I'll have time to try it before 1.0.
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?
Right, for me this is a requirement for separate jetty/tomcat builds.
- 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)
AFAIK we don't have clustering yet... there's nothing stopping you
from using whatever badly thought out :-) configIds you want, but I
think we should encourage people to use configIds with systematic and
useful info in them -- i.e. the maven style ones.
- 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.
The entire configId system works pretty much by convention: they are
just URI's internally. Our current config-store is sort of unusable
from the perspective of looking at it as a directory. IMO it would be
much better if we used the configId as the path in the config store.
However, I'm not proposing to experiment with this for 1.0. You can
write lots of tools to manipulate cars, but I don't really see the
point in having the name unrelated to the configId and leaving out
version information.
The maven repository got involved with the packaging plugin. As I
understand the original idea for configurations was that they would be
independently distributable packages, such as are produced by the
packaging plugin; since it's a maven plugin, it puts its output in the
maven repo. IMO the entire current modules/assembly way of building
geronimo is an unfortunate hack that has distorted our view of geronimo
capabilities and that got implemented only because we made a slight
mistake early on in development priorities. There's nothing stopping
anyone from writing more tools, but the only working ones I am aware of
is the packaging and assembly plugins.
- 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"?)
For the actual configId, I am really strongly in favor of consistency,
and consistency by convention with maven. For display, there are lots
of choices, and I have no preference. For instance, we could group
configIds by groupId.
If you go ahead, do you have a sense for how long it would take to
implement and test the change?
The jetty and tomcat servers now build and start and run the respective
copies of the console. Please try them out. I've done little except
try the console and welcome apps. For instance, I don't know if the
command line deployer works. I'd like to try the tck on them soon, but
there are backwards compatibility obstacles with the plans at the
moment.
After a few more people troubleshoot the manual build process I'd like
to add it to the standard build.
thanks
david jencks
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
