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: Possible problems with maven-style configIds WAS: Warning of change in configId format
Date Wed, 23 Nov 2005 22:14:43 GMT

On Nov 23, 2005, at 2:02 PM, Dain Sundstrom wrote:

> On Nov 23, 2005, at 3:27 PM, David Jencks wrote:
>
>>
>> On Nov 23, 2005, at 1:12 PM, Dain Sundstrom wrote:
>>
>>> On Nov 23, 2005, at 1:58 PM, David Jencks wrote:
>>>
>>>> I've investigated this a little bit and think it might be  too big 
>>>> a lurch in a new direction for 1.0.  Here are a few of the things 
>>>> that would have to change or appear to be problems:
>>>>
>>>> 1. constructing the configId from groupId + artifactId + version + 
>>>> type.  This is pretty easy.
>>>> 2. finding stuff in a repo and/or config store from the configId.  
>>>> This is fairly easy
>>>> 3. Constructing the ObjectNames that include the configId in 
>>>> J2EEApplication and/or J2EEModule.  This requires quoting the 
>>>> configId which is a big pain and is apt to cause  difficulties 
>>>> everywhere.
>>>> 4. We have been using URI for the configIds internally.  I think if 
>>>> we use this new format this should change.  The : character appears 
>>>> to have a specific meaning in URIs and it is decidedly different 
>>>> from what we are meaning by it.  We could perhaps introduce a 
>>>> scheme and write
>>>> configid:groupId:artifactId:version:type.  I could not tell from a 
>>>> bit of research on URIs whether this is consistent with their 
>>>> intended semantics.  Does it make sense to have URIs of this form?  
>>>> Should we just change our configId type to something else?
>>>>
>>>> At this point I think we need more discussion before we proceed 
>>>> along this route.  I have some of it implemented.... please speak 
>>>> up.
>>>
>>> My opinion, is we don't make incompatible changes between major 
>>> releases, so if we decide not to do this now, it will be harder to 
>>> do it later.
>>>
>>> Anyway, I see your point, so lets talk about what changes you want 
>>> to implement pre-1.0?
>>>
>>> If you are changing the configuration ids, I'd like to make sure the 
>>> format is something we can easily parse into groupId, artifactId and 
>>> version.  For example, we could go with:
>>>
>>> org.apache.geronimo/j2ee-server/1.0
>>
>> Should we change our dependency URIs to the same format?  I'm 
>> inclined to think we should.  I would prefer to include the type 
>> (car|jar) for completeness and to distinguish dependencies from 
>> configIds.
>
> I know it will make the files much longer, but I'd prefer we drop or 
> deprecate support for the single line dependency declaration, which 
> means we require the full format:
>
> <dependency>
>    <groupId>org.apache.geronimo</groupId>
>    <artifactId>kernel</artifactId>
>    <version>1.0</version>
> </dependency>

Look in the configs/assemblies builds.  All dependency elements are 
generated by the plugins, and are in this format.
>
>> So I think this format proposal takes care of (3) and (4) and I 
>> already implemented (1) and (2) although with the : separator.  I'm 
>> not sure if this format might cause confusion anywhere between a 
>> resolvable path URI and this more abstract configId format.
>
> It is possible.  Who will actually see it?  If it is just us geronimo 
> programmers, we should document it.  If it is users, I think we should 
> think about mitigating the impact.

I'm mostly wondering about jsr-77 object names.  But, we already have 
both meaningless configId uris and, in ear module names, path uris for 
relative position in the ear.  So I'm not sure this would introduce any 
more confusion.

>
>>> Are there any other changes of note?
>>
>> Using the plugins rather than tons of jelly is a big change, but I'm 
>> not sure what else might be a change "of note".  Also for a while now 
>> the plugin-based build has been extracting dependency info from 
>> project.xml rather than requiring you to duplicate it.
>
> Cool.  I was really asking about changes to the internal stuff or to 
> the plans themselves.

Well, I'd recommend if we decide to change to this uri format that the 
Repository implementations accept them rather than the current path 
based uris they are accepting.

ConfigIds in plans should all change.  Plans we supply are all (in 
configs build) using (generated) dependencies and imports of the long 
format already.  IMO you should be specifiying all the parents using 
import tags anyway in the long format (this is done in configs build as 
well (as soon as I commit the next cleanup :-)).

I'm starting to think this is doable by 1.0.  It would be nice to hear 
other opinions...

thanks
david jencks

>
> -dain
>


Mime
View raw message