geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Hogstrom <>
Subject Re: Sample plan bits for configId branch, please review!
Date Wed, 15 Feb 2006 20:51:17 GMT

Dain Sundstrom wrote:
> I prefer to have them a properties, and then we can support multiple  
> naming systems and use them for future extension.

I like properties as well.

> -dain
> On Feb 15, 2006, at 12:17 PM, David Blevins wrote:
>> This is also awkward and not quite right.  But throwing it out  there 
>> hoping someone can think of something better....
>> <compound-name>
>>    <name-component>
>>       <key>base-name</key>
>>       <value>geronimo.maven:J2EEServer=geronimo</value>
>>    <name-component>
>> </compound-name>
>> -David
>> On Feb 15, 2006, at 10:59 AM, David Jencks wrote:
>>> 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=" 
>>> deployment-1.1">
>>>   <environment>
>>>     <configId>
>>>       <groupId>geronimo</groupId>
>>>       <type>car</type>
>>>       <artifactId>geronimo-gbean-deployer</artifactId>
>>>       <version>1.0.1-SNAPSHOT</version>
>>>     </configId>
>>>     <properties>
>>>       <property>
>>>         <name>base-name</name>
>>>         <value>geronimo.maven:J2EEServer=geronimo</value>
>>>       </property>
>>>     </properties>
>>>     <dependencies>

I'd prefer to make the version and type as optional.  Version would default to 
some server default.  Also, type can default to *car*. My preference for order 
would be groupId, artifactId, version and type.  If its going to break 
compatbility with Maven then leave it.  However, I'm also not in favor of 
letting the underlying technology bleed through and make the user experience 
more complicated than it needs to be.

>>>       < dependency>
>>>         <groupId>geronimo</groupId>
>>>         <type>car</type>
>>>         <artifactId>geronimo-system</artifactId>
>>>         <version>1.0.1-SNAPSHOT</version>
>>>       </dependency>
>>>       <dependency>
>>>         <groupId>geronimo</groupId>
>>>         <artifactId>geronimo-common</artifactId>
>>>         <version>1.0.1-SNAPSHOT</version>
>>>         <load>class</load>

I'd prefer multiple <include> tags like


or the ever popular


>>>       </dependency>
>>>       < dependency>
>>>         <groupId>geronimo</groupId>
>>>         <artifactId>geronimo-deployment</artifactId>
>>>         <version>1.0.1-SNAPSHOT</version>
>>>         <include/>
>>>       </dependency>
>>>       < dependency>
>>>         <groupId>geronimo</groupId>
>>>         <type>car</type>
>>>         <artifactId>geronimo-j2ee</artifactId>
>>>         <version>1.0.1-SNAPSHOT</version>
>>>         <load>service</load>
>>>       </dependency>
>>>     </dependencies>
>>>     <inverse-classloading/>
>>>     <suppress-default-environment/>
>>>     <hidden-classes>
>>>         <filter>org.apache.commons.logging</filter>
>>>     </hidden-classes>

Ooh...looks OSGi like above :)

>>>     <non-overridable-classes>
>>>         <filter>java</filter>
>>>     </non-overridable-classes>
>>>   </environment>
>>>   <!--Deployer used to process modules and plans-->
>>>   <gbean name="Deployer"  
>>> class="org.apache.geronimo.deployment.Deployer">
>>> The previous examples omitted the inverse-classloading, suppress- 
>>> default-environment, and class filter elements.  They  are  included 
>>> here.
>>> "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.

There may be some other items that could be loaded like resource bundles or 
something that we haven't thought of.  I think we should allow for exansion in 
the future.

>>> 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.
>>> Dain:
>>>  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?
>>> Aaron:
>>> 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
>>> going on the classpath.
>>> Paul:
>>> 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 ( maven.html) 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