geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Blevins <>
Subject Re: Sample plan bits for configId branch, please review!
Date Wed, 15 Feb 2006 20:17:37 GMT
This is also awkward and not quite right.  But throwing it out there  
hoping someone can think of something better....



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>
>       < 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 <> 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