geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject Re: Sample plan bits for configId branch, please review!
Date Wed, 15 Feb 2006 18:59:52 GMT
Here's a new version to  look at incorporating some feedback.   
General comments are at the end, followed by some specific  
responses.  It looks like most people liked the second example so I  
have only worked on it.

<configuration xmlns="">
       < dependency>
       < dependency>
       < dependency>
   <!--Deployer used to process modules and plans-->
   <gbean name="Deployer"  

The previous examples omitted the inverse-classloading, suppress- 
default-environment, and class filter elements.  They  are included  

"scope" has been renamed "load".  A particular artifact can have only  
classes (e.g. jar) or both classes and services (car) associated with  
it.  The default would be to use everything available, so we only  
need restrictive elements for the car files, classes and services.   
I've put include as a separate element.

I've added enclosing elements for the properties and dependencies.

I've taken Bruce's idea of a single name string that can be parsed by  
the naming system.  I think that this further reduces our dependency  
on the naming system chosen, but I am open to arguments the other  
way :-)

As Dain noted with the original, at least the version will normally  
be optional.

  I'm not sure about the names of name-keys and name-key.  These are  
really intended for use by the naming system and are rarely used, so  
I prefer to name them that way rather than "properties".  What could  
other properties be used for?  How would we distinguish them from the  
ones for the naming system?

I am very reluctant to have a format with so much overlap with the m2  
dependency without using the same element names.  This way you can  
copy an m2 dependency out of your pom and add the load tag if  
necessary.  I think changing the element names is going to cause too  
much confusion.  I agree that the xml should clearly express our  
function and purpose.... the problem is figuring out what does  that  
best.  I liked the classloader element and separately named  
dependency-structure elements since I thought it showed the purpose  
more blatantly.  I worry a bit that this structure will not make it  
very clear that car dependencies with <load>services</load> are not  
going on the classpath.

I don't quite understand your example.  While configId has the same  
xml structure as a dependency, it is the name of the current  
configuration, not a reference to something outside the current  
configuration.  Do the load/include elements in this example work for  
you in place of the ambiguous scope in the previous example?

Thanks everyone and please keep commenting!
david jencks

On Feb 15, 2006, at 9:45 AM, Aaron Mulder wrote:

> On 2/15/06, Dain Sundstrom <> wrote:
>> If we are going with maven style dependencies I think we should
>> follow their xml ( as
>> close as possible.  If we are going to split from their format, I
>> would like the difference to not be subtle, which would rule out
>> dropping just the Id and reusing elements named "scope" or "type" for
>> something other than what they mean in maven.
> I hear you, I'm just not that concerned with how close we stick to
> maven syntax since what we're doing here is in many cases quite
> different from what maven does.  For example, if I want to force the
> CORBA ORB to be started before my EJB app is deployed, I don't think
> "naturally, I should use Maven for that!", but that's one of the
> things these elements are used for.  I would much rather have clear
> and easy syntax for what *we* want to do.
> Thanks,
>     Aaron

View raw message