geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Blevins <david.blev...@visi.com>
Subject Re: Sample plan bits for configId branch, please review!
Date Wed, 15 Feb 2006 21:23:19 GMT
So we should call it something like:

<configuration>
...
   <naming-properties>
     <property>
       <name>base-name</name>
       <value>geronimo.maven:J2EEServer=geronimo</value>
     </property>
   </naming-properties>
...
</configuration>

Cause IMHO, having a <configuration> element with a <properties> sub  
element implies something all together different:

<configuration>
...
   <properties>
     <property>
       <name>base-name</name>
       <value>geronimo.maven:J2EEServer=geronimo</value>
     </property>
   </properties>
...
</configuration>


-David



On Feb 15, 2006, at 12:51 PM, Matt Hogstrom wrote:

>
>
> 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="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>
>
> 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
>
> <include>classes</include>
> <include>services</include>
>
> or the ever popular
>
> <include>*</include>
>
>>>>       </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 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