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