geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dain Sundstrom <>
Subject Re: Warning of change in configId format
Date Tue, 22 Nov 2005 22:51:49 GMT
On Nov 22, 2005, at 1:35 PM, David Jencks wrote:

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

I think using the maven repo path for the configId is problematic.   
The layout of the repository will change over time, and is actually  
completely repository dependent.  We have already seen a change  
between maven 1 and maven 2.  I would prefer that the ID follow the  
maven single line notation for an artifact.


In this case, we don't need a classifier and we can always assume  
type is "car", so we will end up with something like:


which I think is a lot cleaner then the m1 and m2 paths, as doesn't  
repeat information:


Does that seem reasonable?

>> 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 think this is one of the things we address now, or defer until  
Geronimo 2.0, whenever that is.

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

Well if we want to use maven artifact to manage our repository, we  
are going to need a groupId, artifactId and a version.  We could  
simply make groupId and vendorId equal what ever random string the  
user give us and make the version a time stamp.  I think it would be  
better if the deployment tool prompted for the groupId and artifactId  
if there wasn't a geronimo plan in the archive, but it isn't necessary.


View raw message