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