geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dain Sundstrom <d...@iq80.com>
Subject Re: Sample plan bits for configId branch, please review!
Date Wed, 15 Feb 2006 20:28:09 GMT
I prefer to have them a properties, and then we can support multiple  
naming systems and use them for future extension.

-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="http://geronimo.apache.org/xml/ns/ 
>> 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>
>>       < 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>
>>       </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>
>>     <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.
>>
>> 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 not 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 <dain@iq80.com> wrote:
>>>> If we are going with maven style dependencies I think we should
>>>> follow their xml (http://maven.apache.org/maven-model/ 
>>>> 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
>>


Mime
View raw message