I would also prefer having as many optional elements as possible in
configID.
- sachin
On Feb 15, 2006, at 3: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 <[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
