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 <[EMAIL PROTECTED]> 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
