geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david_jen...@yahoo.com>
Subject Re: Warning of change in configId format
Date Tue, 22 Nov 2005 19:35:02 GMT
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 <david_jencks@yahoo.com> 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
>>
>>
>


Mime
View raw message