Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@geronimo.apache.org
Received-SPF: pass (asf.osuosl.org: domain of jrsisson@gmail.com designates
 64.233.162.192 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:user-agent:x-accept-language:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding;
        b=HF1GitvAx4QT/XXeR6tNYfjhv1z1tarwXhl9nStM3IPHAfhgwGHKROF3zOYr5udW+GE2tGfBHqUmgzw+2ETwV/BZLU/tSPWKGWJrxGlisufyx1aUeN9hATQRNQeEjyrzXM0/uIRX8qMoGVlEpGK63d9JEyTgyv5lf8IRVwonC7M=
Message-ID: <4383D118.4030508@gmail.com>
Date: Wed, 23 Nov 2005 13:16:56 +1100
From: John Sisson <jrsisson@gmail.com>
User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716)
MIME-Version: 1.0
To: dev@geronimo.apache.org
Subject: Re: Warning of change in configId format
References: <c46802aa0bcfad62a60f21c28c2b98c8@yahoo.com>
 <74e15baa0511180659q384aa34aobfe5614d74dc4ea9@mail.gmail.com>
 <5fda22591a1c1147bbd56a2b5de6b29b@yahoo.com>
 <97F6E651-AB76-4FC5-A4D7-B82B272B84FE@iq80.com>
In-Reply-To: <97F6E651-AB76-4FC5-A4D7-B82B272B84FE@iq80.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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 the maven single line notation proposed above.  Having it follow 
a more structured format like this could give us more flexibility in the 
future than freeform names.

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

If we think there might be issues migrating users from 1.0 to a later 
release that has a different configId scheme then I think we need to 
address this now.

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

In regards to using a maven style repository for configurations:

I'm not sure if I have misunderstood whether you are proposing to change 
the way configurations are stored...

How do you picture a configuration in the configuration store (maven 
style) being placed there and accessed by geronimo instances in a 
cluster when a configuration is deployed? 

Will there be a central repository containing versioned configs that all 
instances in the cluster will access?  What happens if the machine 
containing the central repository dies? 

Or will each instance (could be on the same machine or remote machines) 
have its own repository (seems to go against the maven repository concept)?

Currently the current config store stores web app files in an expanded 
directory format.  If we were to use a maven repo as the config store 
then I am assuming that isn't possible and containers  such as 
Tomcat/Jetty would have to read files from the CAR?  If so, does this 
have any implications?

We would also have to think about maintaining the repository (enable old 
configurations to be removed so we don't use up too much disk space) as 
it would build up quickly, especially in a development environment where 
new versions are deployed and tested often.

It seems (since you mentioned maven artifact above) you are suggesting 
that a maven would need to be installed to properly manage geronimo 
configurations in a repository.  If this is the case I think this needs 
to be made clear to everyone to get their buy in.

Regards,

John

>
> -dain
>