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 23:15:19 GMT

On Nov 22, 2005, at 2:51 PM, Dain Sundstrom wrote:

> 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.
>
> groupId:artifactId:version:type[:classifier]
>
> 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:
>
> org.apache.geronimo:j2ee-server:1.0
>
> which I think is a lot cleaner then the m1 and m2 paths, as doesn't  
> repeat information:
>
> org.apache.geronimo./cars/geronimo-j2ee-server-1.0.car
> org/apache/geronimo/geronimo-j2ee-server/1.0/geronimo-j2ee-server 
> -1.0.car
>
> Does that seem reasonable?

I like that a lot.  I have been wondering how to extract the pieces of  
the repo path back out of the configId.
>
>>> 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.

I like this too, especially if someone else implements it:-)

thanks
david jencks

>
> -dain
>


Mime
View raw message