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 Thu, 24 Nov 2005 01:26:32 GMT

On Nov 23, 2005, at 3:46 PM, Aaron Mulder wrote:

> On 11/23/05, Dain Sundstrom <dain@iq80.com> wrote:
>> 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:
>
> I object to doing this.  I really think most users are going to want
> to give their applications short and sweet config IDs like "AppName".
> OK, yes, that means you can't use the packaging plugin to install
> them, but I as a user am totally comfortable with that, and I don't
> see why I should have to do something like the huge block below for
> every little module I write.  P.S. I also would be opposed to needing
> to specify the parentId using 4 attributes.

First, I think Dain is talking mostly about dependencies here.  In this 
case if we continue to support the short form you would write

<uri>yourGroup/yourArtifact/yourVersion/jar</uri>

rather than

<uri>yourGroup/jars/yourArtifact-yourVersion.jar</uri>

which to my untutored eyes looks shorter and simpler.  However, I think 
encouraging people to use the long form is clearer and leads to less 
confusion and it can be installed by maven from your project.xml.

All simple apps shouldn't need to specify  any parentIds at all in any 
way, one line or import-style multiline.  The builders insert the 
parentIds that are needed for that kind of j2ee module to run.  Unless 
you are doing something unusual like having applications depend on each 
other this should work.  If it doesn't we probably need to adjust the 
default parentIds in the builders.

Anyone who is doing something complicated enough to require explicitly 
specifying parent ids will probably not mind the extra clarity and 
structure the longer format provides.
>
> So I won't kick and scream too much if you change our server
> components to use stuff like that in their own plans, but I will be
> pretty grumpy if users are required to use that in order to write any
> basic Geronimo plan containing a configId and parentId.  And since
> there's no distinguishing between the elements that point to a
> location in the repository and the elements that simply take an
> abstract URI (another mistake IMHO but David J continues to overrule
> me on this one)
Could you be more explicit about what you are talking about here? So 
far I have no idea.


> , if you're going to be allowed to name your database
> pool "MyPool" and then create an app "MyApp" with "MyPool" as a parent
> or dependency, we can't insist that people use the Maven-style format.

If you are using a custom database pool in your app, why wouldn't you 
include the pool configuration in your plan in one of the numerous 
supported ways?

Once you get to "sharing between multiple apps" situations, I think 
these are sufficiently complicated that requiring users to pay 
attention to who they are (groupId) and how far along their project 
parts are relative to one another (version) will only help them.
>
> I think this would all be a lot more palatable if we could think up a
> way for a user to use a short name like "MyApp" and we use more large
> and explicit naming under the covers but allow the user to do
> everything with only "MyApp", but I think that might be challenging.

Well, once we have a defined and meaningful format for config Ids, we 
have the possibility of supplying defaults somewhere in the system.  
For instance, we might tell the deployer that if the groupid is 
missing, it should default to your company groupId.  Similarly for the 
version.  I'm not sure how plausible it is to push this into module 
tags in references, but we might be able to come up with something.  If 
we continue on our current path of random and meaningless configIds no 
such defaults are possible.

thanks
david jencks

>
> Aaron
>
>> <dependency>
>>     <groupId>org.apache.geronimo</groupId>
>>     <artifactId>kernel</artifactId>
>>     <version>1.0</version>
>> </dependency>
>>
>>> 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.
>>
>>>> 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.
>>
>> -dain
>>
>>
>


Mime
View raw message