You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by David Jencks <da...@yahoo.com> on 2006/02/15 02:03:47 UTC
Sample plan bits for configId branch, please review!
We need some widespread thought about the new xml schema we're
getting in 1.1. Dain and I are not particularly thrilled with the
element names but haven't thought of improvements. We also thought
of an alternate way of presenting the info and would like opinions on
which is better.
The schema currently in svn in the configid branch results in plans
that start like this:
<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>
<!-- name-key elements are very unlikely to be used by anything
except "root" system plans
such as j2ee-system. Included here only to show what they look like -->
<name-key>
<key>domain</key>
<value>geronimo.maven</value>
</name-key>
<name-key>
<key>J2EEServer</key>
<value>geronimo</value>
</name-key>
<classloader>
<import>
<groupId>geronimo</groupId>
<type>car</type>
<artifactId>geronimo-system</artifactId>
<version>1.0.1-SNAPSHOT</version>
</import>
<dependency>
<groupId>geronimo</groupId>
<artifactId>geronimo-common</artifactId>
<version>1.0.1-SNAPSHOT</version>
</dependency>
<include>
<groupId>geronimo</groupId>
<artifactId>geronimo-deployment</artifactId>
<version>1.0.1-SNAPSHOT</version>
</include>
</classloader>
<!--reference is a new element, the meaning is that the configuration
must be loaded and started before this one, but the classloader of
the config is not a parent -->
<reference>
<groupId>geronimo</groupId>
<type>car</type>
<artifactId>geronimo-j2ee</artifactId>
<version>1.0.1-SNAPSHOT</version>
</reference>
</environment>
<!--Deployer used to process modules and plans-->
<gbean name="Deployer"
class="org.apache.geronimo.deployment.Deployer">
An alternate layout is more similar to m2 with the idea of different
functions for a dependency shown by a "scope" element. Scope doesn't
seem like the right element name for us. (sorry about the lousy
indenting)
<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>
<!-- name-key elements are very unlikely to be used by anything
except "root" system plans
such as j2ee-system. Included here only to show what they look like -->
<name-key>
<key>domain</key>
<value>geronimo.maven</value>
</name-key>
<name-key>
<key>J2EEServer</key>
<value>geronimo</value>
</name-key>
< dependency>
<groupId>geronimo</groupId>
<type>car</type>
<artifactId>geronimo-system</artifactId>
<version>1.0.1-SNAPSHOT</version>
<scope>full</scope>
</dependency>
<dependency>
<groupId>geronimo</groupId>
<artifactId>geronimo-common</artifactId>
<version>1.0.1-SNAPSHOT</version>
<scope>class</scope>
</dependency>
< dependency>
<groupId>geronimo</groupId>
<artifactId>geronimo-deployment</artifactId>
<version>1.0.1-SNAPSHOT</version>
<scope>include</scope>
</dependency>
< dependency>
<groupId>geronimo</groupId>
<type>car</type>
<artifactId>geronimo-j2ee</artifactId>
<version>1.0.1-SNAPSHOT</version>
<scope>service</scope>
</dependency>
</environment>
<!--Deployer used to process modules and plans-->
<gbean name="Deployer"
class="org.apache.geronimo.deployment.Deployer">
Here, the scopes have meaning as follows:
both -- both classes and services (gbeans), like import
classes -- only classes, if a car don't start the gbeans for us, like
dependency
services -- only gbeans, don't add classes to our classpath, like
reference (new element shown in first example)
include -- copy the artifact into the current configuration. This
seems like a separate dimension not related to the previous scopes.
Again, please study these and comment.
Many thanks
david jencks
Re: Sample plan bits for configId branch, please review!
Posted by Dain Sundstrom <da...@iq80.com>.
Note version number elements will be optional. I will post a
description of the resolution strategy for version numbers after I
get a bit of the code working. You just never know until you code
something :)
-dain
On Feb 14, 2006, at 5:03 PM, David Jencks wrote:
> We need some widespread thought about the new xml schema we're
> getting in 1.1. Dain and I are not particularly thrilled with the
> element names but haven't thought of improvements. We also thought
> of an alternate way of presenting the info and would like opinions
> on which is better.
>
> The schema currently in svn in the configid branch results in plans
> that start like this:
>
> <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>
> <!-- name-key elements are very unlikely to be used by anything
> except "root" system plans
> such as j2ee-system. Included here only to show what they look
> like -->
> <name-key>
> <key>domain</key>
> <value>geronimo.maven</value>
> </name-key>
> <name-key>
> <key>J2EEServer</key>
> <value>geronimo</value>
> </name-key>
> <classloader>
> <import>
> <groupId>geronimo</groupId>
> <type>car</type>
> <artifactId>geronimo-system</artifactId>
> <version>1.0.1-SNAPSHOT</version>
> </import>
> <dependency>
> <groupId>geronimo</groupId>
> <artifactId>geronimo-common</artifactId>
> <version>1.0.1-SNAPSHOT</version>
> </dependency>
> <include>
> <groupId>geronimo</groupId>
> <artifactId>geronimo-deployment</artifactId>
> <version>1.0.1-SNAPSHOT</version>
> </include>
> </classloader>
> <!--reference is a new element, the meaning is that the
> configuration must be loaded and started before this one, but the
> classloader of the config is not a parent -->
> <reference>
> <groupId>geronimo</groupId>
> <type>car</type>
> <artifactId>geronimo-j2ee</artifactId>
> <version>1.0.1-SNAPSHOT</version>
> </reference>
> </environment>
> <!--Deployer used to process modules and plans-->
> <gbean name="Deployer"
> class="org.apache.geronimo.deployment.Deployer">
>
>
> An alternate layout is more similar to m2 with the idea of
> different functions for a dependency shown by a "scope" element.
> Scope doesn't seem like the right element name for us. (sorry about
> the lousy indenting)
>
> <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>
> <!-- name-key elements are very unlikely to be used by anything
> except "root" system plans
> such as j2ee-system. Included here only to show what they look
> like -->
> <name-key>
> <key>domain</key>
> <value>geronimo.maven</value>
> </name-key>
> <name-key>
> <key>J2EEServer</key>
> <value>geronimo</value>
> </name-key>
> < dependency>
> <groupId>geronimo</groupId>
> <type>car</type>
> <artifactId>geronimo-system</artifactId>
> <version>1.0.1-SNAPSHOT</version>
> <scope>full</scope>
> </dependency>
> <dependency>
> <groupId>geronimo</groupId>
> <artifactId>geronimo-common</artifactId>
> <version>1.0.1-SNAPSHOT</version>
> <scope>class</scope>
> </dependency>
> < dependency>
> <groupId>geronimo</groupId>
> <artifactId>geronimo-deployment</artifactId>
> <version>1.0.1-SNAPSHOT</version>
> <scope>include</scope>
> </dependency>
> < dependency>
> <groupId>geronimo</groupId>
> <type>car</type>
> <artifactId>geronimo-j2ee</artifactId>
> <version>1.0.1-SNAPSHOT</version>
> <scope>service</scope>
> </dependency>
> </environment>
> <!--Deployer used to process modules and plans-->
> <gbean name="Deployer"
> class="org.apache.geronimo.deployment.Deployer">
>
> Here, the scopes have meaning as follows:
>
> both -- both classes and services (gbeans), like import
> classes -- only classes, if a car don't start the gbeans for us,
> like dependency
> services -- only gbeans, don't add classes to our classpath, like
> reference (new element shown in first example)
> include -- copy the artifact into the current configuration. This
> seems like a separate dimension not related to the previous scopes.
>
> Again, please study these and comment.
>
> Many thanks
> david jencks
>
Re: Sample plan bits for configId branch, please review!
Posted by Bruce Snyder <br...@gmail.com>.
On 2/15/06, Dain Sundstrom <da...@iq80.com> wrote:
> On Feb 14, 2006, at 8:32 PM, Bruce Snyder wrote:
>
> > 1) It seems like the name-key elements should be wrapped in another
> > element. Perhaps an element named name-pattern or something similar.
>
> Maybe we just make these generic properties:
>
> <properties>
> <property>
> <name>domain</name>
> <value>geronimo.maven</value>
> </property>
> <property>
> <name>J2EEServer</name>
> <value>geronimo</value>
> </property>
> </properties>
Yes, using the properties element is a good idea. I like that.
> On Feb 15, 2006, at 5:13 AM, Aaron Mulder wrote:
>
> > The biggest change I'd request is to take the Id of the end of group
> > and artifact. I don't think it adds anything, and it makes it harder
> > to read and repeat (is that Id or ld, for example). If we really have
> > to keep it, I'd prefer artifact-id and group-id, but I really don't
> > see why we shouldn't just use group, type, artifact, and version.
>
> 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.
While I agree in theory, let's see how this proves out in practice. I
think building on the Maven concepts is fine.
Bruce
--
perl -e 'print unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
);'
Apache Geronimo (http://geronimo.apache.org/)
Castor (http://castor.org/)
Re: Sample plan bits for configId branch, please review!
Posted by Sachin Patel <sp...@gmail.com>.
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 <da...@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
>>>>
>>>>
Re: Sample plan bits for configId branch, please review!
Posted by David Blevins <da...@visi.com>.
On Feb 15, 2006, at 2:31 PM, David Jencks wrote:
>
> On Feb 15, 2006, at 2:04 PM, David Blevins wrote:
>
>> On Feb 15, 2006, at 1:38 PM, Dain Sundstrom wrote:
>>
>>> On Feb 15, 2006, at 1:23 PM, David Blevins wrote:
>>>
>>>> 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:
>>
>> [...]
>>
>>> Also I would prefer to not imply that these properties are
>>> limited to only "naming-properties". I gut tells me that this
>>> will be a useful extension place in the geronimo configurations.
>>
>> Ok. I was under the impression via DJ's comments that these were
>> only for naming.
>>
>> On Feb 15, 2006, at 10:59 AM, David Jencks wrote:
>>>
>>> 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?
>>
>> And your comment on using any naming system made me think my
>> impression was definitely write. I guess this isn't one of those
>> agreed upon things just yet.
>>
>> So what is the general idea behind them? A generic bucket for
>> properties that are easily available to all gbeans in my
>> configuration?
>
> I originally thought of them as having only to do with the naming
> system, but after Dain suggested "properties" I realized that we
> might think of something else to use them for in the future. They
> would be available to parts of the deployment infrastructure such
> as the naming system, but not really to any gbeans.
I like this. Nice, simple, flexible. It's great to have things
strongly defined and structured out for what is known, but nice to
have a bucked for the unknown to exist. Gives you a nice place too
look for stuff you may want to deal with better some day.
One other use case I could think of is "hinting" the deployment
system to maybe user more strict or loose rules, more or less
validation, more implicit or explicit reference linking. Just some
ideas, these aren't features we have yet obviously.
-David
Re: Sample plan bits for configId branch, please review!
Posted by David Jencks <da...@yahoo.com>.
On Feb 15, 2006, at 3:07 PM, John Sisson wrote:
> David Jencks wrote:
>>
>> On Feb 15, 2006, at 2:04 PM, David Blevins wrote:
>>
>>> On Feb 15, 2006, at 1:38 PM, Dain Sundstrom wrote:
>>>
>>>> On Feb 15, 2006, at 1:23 PM, David Blevins wrote:
>>>>
>>>>> 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:
>>>
>>> [...]
>>>
>>>> Also I would prefer to not imply that these properties are
>>>> limited to only "naming-properties". I gut tells me that this
>>>> will be a useful extension place in the geronimo configurations.
>>>
>>> Ok. I was under the impression via DJ's comments that these were
>>> only for naming.
>>>
>>> On Feb 15, 2006, at 10:59 AM, David Jencks wrote:
>>>>
>>>> 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?
>>>
>>> And your comment on using any naming system made me think my
>>> impression was definitely write. I guess this isn't one of those
>>> agreed upon things just yet.
>>>
>>> So what is the general idea behind them? A generic bucket for
>>> properties that are easily available to all gbeans in my
>>> configuration?
>>
>> I originally thought of them as having only to do with the naming
>> system, but after Dain suggested "properties" I realized that we
>> might think of something else to use them for in the future. They
>> would be available to parts of the deployment infrastructure such
>> as the naming system, but not really to any gbeans.
> I am wondering whether having both naming properties and other
> properties under the one <properties> element may make it difficult
> for any tools (e.g. a GUI/web based tool that can read/build plans)
> to identify and display the naming properties when reading the
> plans without hard coded knowledge of the property names used for
> naming.
I think we are going off the deep end here :-). Currently the only
use anyone has thought of for this is to supply the domain and server
name components of gbeans in configurations with no parent such as
j2ee-system. I don't think anyone who has the knowledge to set one
of these configurations up will have any problems doing it in say
pico rather than a gui tool :-). Really, if you are setting one of
these up, you are setting up an entirely different kind of geronimo
server, not just a minor reassembly such as going from j2ee-tomcat to
minimal-tomcat.
thanks
david jencks
>
> John
>>
>> thanks
>> david jencks
>>
>>>
>>> -David
>>>
>>
Re: Sample plan bits for configId branch, please review!
Posted by Dain Sundstrom <da...@iq80.com>.
On Feb 15, 2006, at 6:01 PM, Sachin Patel wrote:
> Is it possible to define an enumeration of the possible properties?
The idea I have, is that literally any value would be allowed. The
one value David Jencks and I mentioned is something that a user
should never see or mess with.
-dain
Re: Sample plan bits for configId branch, please review!
Posted by Sachin Patel <sp...@gmail.com>.
- sachin
On Feb 15, 2006, at 6:07 PM, John Sisson wrote:
> David Jencks wrote:
>>
>> On Feb 15, 2006, at 2:04 PM, David Blevins wrote:
>>
>>> On Feb 15, 2006, at 1:38 PM, Dain Sundstrom wrote:
>>>
>>>> On Feb 15, 2006, at 1:23 PM, David Blevins wrote:
>>>>
>>>>> 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:
>>>
>>> [...]
>>>
>>>> Also I would prefer to not imply that these properties are
>>>> limited to only "naming-properties". I gut tells me that this
>>>> will be a useful extension place in the geronimo configurations.
>>>
>>> Ok. I was under the impression via DJ's comments that these were
>>> only for naming.
>>>
>>> On Feb 15, 2006, at 10:59 AM, David Jencks wrote:
>>>>
>>>> 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?
>>>
>>> And your comment on using any naming system made me think my
>>> impression was definitely write. I guess this isn't one of those
>>> agreed upon things just yet.
>>>
>>> So what is the general idea behind them? A generic bucket for
>>> properties that are easily available to all gbeans in my
>>> configuration?
>>
>> I originally thought of them as having only to do with the naming
>> system, but after Dain suggested "properties" I realized that we
>> might think of something else to use them for in the future. They
>> would be available to parts of the deployment infrastructure such
>> as the naming system, but not really to any gbeans.
> I am wondering whether having both naming properties and other
> properties under the one <properties> element may make it difficult
> for any tools (e.g. a GUI/web based tool that can read/build plans)
> to identify and display the naming properties when reading the
> plans without hard coded knowledge of the property names used for
> naming.
Is it possible to define an enumeration of the possible properties?
>
> John
>>
>> thanks
>> david jencks
>>
>>>
>>> -David
>>>
>>
Re: Sample plan bits for configId branch, please review!
Posted by John Sisson <jr...@gmail.com>.
David Jencks wrote:
>
> On Feb 15, 2006, at 2:04 PM, David Blevins wrote:
>
>> On Feb 15, 2006, at 1:38 PM, Dain Sundstrom wrote:
>>
>>> On Feb 15, 2006, at 1:23 PM, David Blevins wrote:
>>>
>>>> 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:
>>
>> [...]
>>
>>> Also I would prefer to not imply that these properties are limited
>>> to only "naming-properties". I gut tells me that this will be a
>>> useful extension place in the geronimo configurations.
>>
>> Ok. I was under the impression via DJ's comments that these were
>> only for naming.
>>
>> On Feb 15, 2006, at 10:59 AM, David Jencks wrote:
>>>
>>> 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?
>>
>> And your comment on using any naming system made me think my
>> impression was definitely write. I guess this isn't one of those
>> agreed upon things just yet.
>>
>> So what is the general idea behind them? A generic bucket for
>> properties that are easily available to all gbeans in my configuration?
>
> I originally thought of them as having only to do with the naming
> system, but after Dain suggested "properties" I realized that we might
> think of something else to use them for in the future. They would be
> available to parts of the deployment infrastructure such as the naming
> system, but not really to any gbeans.
I am wondering whether having both naming properties and other
properties under the one <properties> element may make it difficult for
any tools (e.g. a GUI/web based tool that can read/build plans) to
identify and display the naming properties when reading the plans
without hard coded knowledge of the property names used for naming.
John
>
> thanks
> david jencks
>
>>
>> -David
>>
>
Re: Sample plan bits for configId branch, please review!
Posted by David Jencks <da...@yahoo.com>.
On Feb 15, 2006, at 2:04 PM, David Blevins wrote:
> On Feb 15, 2006, at 1:38 PM, Dain Sundstrom wrote:
>
>> On Feb 15, 2006, at 1:23 PM, David Blevins wrote:
>>
>>> 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:
>
> [...]
>
>> Also I would prefer to not imply that these properties are limited
>> to only "naming-properties". I gut tells me that this will be a
>> useful extension place in the geronimo configurations.
>
> Ok. I was under the impression via DJ's comments that these were
> only for naming.
>
> On Feb 15, 2006, at 10:59 AM, David Jencks wrote:
>>
>> 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?
>
> And your comment on using any naming system made me think my
> impression was definitely write. I guess this isn't one of those
> agreed upon things just yet.
>
> So what is the general idea behind them? A generic bucket for
> properties that are easily available to all gbeans in my
> configuration?
I originally thought of them as having only to do with the naming
system, but after Dain suggested "properties" I realized that we
might think of something else to use them for in the future. They
would be available to parts of the deployment infrastructure such as
the naming system, but not really to any gbeans.
thanks
david jencks
>
> -David
>
>
>
>
>
>
>
>
>
Re: Sample plan bits for configId branch, please review!
Posted by David Blevins <da...@visi.com>.
On Feb 15, 2006, at 1:38 PM, Dain Sundstrom wrote:
> On Feb 15, 2006, at 1:23 PM, David Blevins wrote:
>
>> 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:
[...]
> Also I would prefer to not imply that these properties are limited
> to only "naming-properties". I gut tells me that this will be a
> useful extension place in the geronimo configurations.
Ok. I was under the impression via DJ's comments that these were
only for naming.
On Feb 15, 2006, at 10:59 AM, David Jencks wrote:
>
> 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?
And your comment on using any naming system made me think my
impression was definitely write. I guess this isn't one of those
agreed upon things just yet.
So what is the general idea behind them? A generic bucket for
properties that are easily available to all gbeans in my configuration?
-David
Re: Sample plan bits for configId branch, please review!
Posted by Dain Sundstrom <da...@iq80.com>.
On Feb 15, 2006, at 1:23 PM, David Blevins wrote:
> 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>
The xml is more like this:
<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>
</environment>
</configuration>
I think it is fairly clear that these are properties of the
environment. Also I would prefer to not imply that these properties
are limited to only "naming-properties". I gut tells me that this
will be a useful extension place in the geronimo configurations.
-dain
Re: Sample plan bits for configId branch, please review!
Posted by David Blevins <da...@visi.com>.
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 <da...@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
>>>>
>>>>
>
Re: Sample plan bits for configId branch, please review!
Posted by Matt Hogstrom <ma...@hogstrom.org>.
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 <da...@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
>>>
>>>
>
>
>
>
Re: Sample plan bits for configId branch, please review!
Posted by Dain Sundstrom <da...@iq80.com>.
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 <da...@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
>>
Re: Sample plan bits for configId branch, please review!
Posted by David Blevins <da...@visi.com>.
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 <da...@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
>
Re: Sample plan bits for configId branch, please review!
Posted by Paul McMahan <pa...@gmail.com>.
>
> 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.
In my example I just (lazily) copy/pasted the configId from higher up in the
DD which I suppose would have created a circular reference :-) My intent
was actually just to show the suggested element structure, which would look
like:
<dependency>
<configId>
<groupId/>
<type/>
<artifactId/>
<version/>
</configId>
<load/>
</dependency>
The rationale behind making <configId> a child of <dependency> (as well as
<environment>) would be to make a clear separation between identifying the
target of the dependency vs. describing the way that Geronimo should enable
it (start its gbeans, load its classes, import it, etc). It would also
allow the dependency element to automatically inherit any future changes in
the schema for the configId element.
All that being said, I could certainly understand a counter argument for
mirroring maven's dependency element. When it comes to tight integration
with maven I'm starting to "stop worrying and love the bomb" ;-)
Do the load/include elements in this example work for
> you in place of the ambiguous scope in the previous example?
Yes -- makes sense, thanks.
Best wishes,
Paul
Re: Sample plan bits for configId branch, please review!
Posted by John Sisson <jr...@gmail.com>.
Dain Sundstrom wrote:
> On Feb 15, 2006, at 10:59 AM, David Jencks wrote:
>
>> <properties>
>> <property>
>> <name>base-name</name>
>> <value>geronimo.maven:J2EEServer=geronimo</value>
>> </property>
>> </properties>
>
> I like this but I think the name should be name spaces to avoid
> conflict. Also we are the only ones that will touch this property so
> if it is long it doesn't matter. How about
> org.apache.geronimo.j2ee.BaseName?
I agree we should be using name spaces. If we think there may be other
naming systems in the future, would it be worth having a prefix before
the j2ee part of the name space to make it easier to find all uses (e.g.
using grep or an IDE search function) of geronimo's naming properties
regardless of the naming system used? E.G:
org.apache.geronimo.name.j2ee.BaseName
org.apache.geronimo.name.fooNamingSystem.BaseName
'name' may not be the best choice in the example.. I chose it because
'org.apache.geronimo.naming' is already used as a package name.
John
>
> On Feb 15, 2006, at 10:59 AM, David Jencks wrote:
>> < dependency>
>> <groupId>geronimo</groupId>
>> <artifactId>geronimo-deployment</artifactId>
>> <version>1.0.1-SNAPSHOT</version>
>> <include/>
>> </dependency>
>
> For those that are not aware, include means to literally include the
> contents of the dependency jar into the car created by the
> configuration. This makes it easy to create stand alone self
> executing configurations. I suggest we move this feature to the
> deploy tool using an optional flag and leave it out of this xml file.
>
> On Feb 15, 2006, at 12:51 PM, Matt Hogstrom wrote:
>> I'd prefer to make the version and type as optional. Version would
>> default to some server default. Also, type can default to *car*.
>
> I think type "jar" will be the most common. My guess is a component
> will have 0-2 parents most of the time, but lots of jars.
>
>>>>> <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>
>
> Since "include" has an existing meaning in Geronimo service plans, I
> suggest that we name this element "import" to avoid any possible
> confusion.
>
>> or the ever popular
>>
>> <include>*</include>
>
> We are only talking about 2 items which isn't a big deal. Also David
> mentioned somewhere that the default in the absence to any "load"
> (name David is using) tags it to do both classes and services.
>
> -dain
>
>
>
>
Re: Sample plan bits for configId branch, please review!
Posted by Dain Sundstrom <da...@iq80.com>.
On Feb 15, 2006, at 10:59 AM, David Jencks wrote:
> <properties>
> <property>
> <name>base-name</name>
> <value>geronimo.maven:J2EEServer=geronimo</value>
> </property>
> </properties>
I like this but I think the name should be name spaces to avoid
conflict. Also we are the only ones that will touch this property so
if it is long it doesn't matter. How about
org.apache.geronimo.j2ee.BaseName?
On Feb 15, 2006, at 10:59 AM, David Jencks wrote:
> < dependency>
> <groupId>geronimo</groupId>
> <artifactId>geronimo-deployment</artifactId>
> <version>1.0.1-SNAPSHOT</version>
> <include/>
> </dependency>
For those that are not aware, include means to literally include the
contents of the dependency jar into the car created by the
configuration. This makes it easy to create stand alone self
executing configurations. I suggest we move this feature to the
deploy tool using an optional flag and leave it out of this xml file.
On Feb 15, 2006, at 12:51 PM, Matt Hogstrom wrote:
> I'd prefer to make the version and type as optional. Version would
> default to some server default. Also, type can default to *car*.
I think type "jar" will be the most common. My guess is a component
will have 0-2 parents most of the time, but lots of jars.
>>>> <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>
Since "include" has an existing meaning in Geronimo service plans, I
suggest that we name this element "import" to avoid any possible
confusion.
> or the ever popular
>
> <include>*</include>
We are only talking about 2 items which isn't a big deal. Also David
mentioned somewhere that the default in the absence to any
"load" (name David is using) tags it to do both classes and services.
-dain
Re: Sample plan bits for configId branch, please review!
Posted by David Jencks <da...@yahoo.com>.
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 <da...@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
Re: Sample plan bits for configId branch, please review!
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
On 2/15/06, Dain Sundstrom <da...@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
Re: Sample plan bits for configId branch, please review!
Posted by Dain Sundstrom <da...@iq80.com>.
On Feb 14, 2006, at 8:32 PM, Bruce Snyder wrote:
> 1) It seems like the name-key elements should be wrapped in another
> element. Perhaps an element named name-pattern or something similar.
Maybe we just make these generic properties:
<properties>
<property>
<name>domain</name>
<value>geronimo.maven</value>
</property>
<property>
<name>J2EEServer</name>
<value>geronimo</value>
</property>
</properties>
On Feb 15, 2006, at 5:13 AM, Aaron Mulder wrote:
> The biggest change I'd request is to take the Id of the end of group
> and artifact. I don't think it adds anything, and it makes it harder
> to read and repeat (is that Id or ld, for example). If we really have
> to keep it, I'd prefer artifact-id and group-id, but I really don't
> see why we shouldn't just use group, type, artifact, and version.
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.
-dain
Re: Sample plan bits for configId branch, please review!
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
Bruce,
I'm pretty sure the ObjectName isn't sensitive to ordering, but in any
case the domain is always separated from the rest of the name=value
components, so all together I don't think any ordering is necessary
for the name keys.
David,
I could go either way on the syntax. I think overall I prefer
distinct elements for things with separate meanings, but it wouldn't
break my heart to do it the other way. The best I can come up with
for "scope" is "behavior" or "load". Maybe load is better --
load="classes" or load="gbeans" or load="both"....
The biggest change I'd request is to take the Id of the end of group
and artifact. I don't think it adds anything, and it makes it harder
to read and repeat (is that Id or ld, for example). If we really have
to keep it, I'd prefer artifact-id and group-id, but I really don't
see why we shouldn't just use group, type, artifact, and version.
Thanks,
Aaron
On 2/14/06, Bruce Snyder <br...@gmail.com> wrote:
> On 2/14/06, David Jencks <da...@yahoo.com> wrote:
> > We need some widespread thought about the new xml schema we're
> > getting in 1.1. Dain and I are not particularly thrilled with the
> > element names but haven't thought of improvements. We also thought
> > of an alternate way of presenting the info and would like opinions on
> > which is better.
> >
> > The schema currently in svn in the configid branch results in plans
> > that start like this:
> >
> > <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>
> > <!-- name-key elements are very unlikely to be used by anything
> > except "root" system plans
> > such as j2ee-system. Included here only to show what they look like -->
> > <name-key>
> > <key>domain</key>
> > <value>geronimo.maven</value>
> > </name-key>
> > <name-key>
> > <key>J2EEServer</key>
> > <value>geronimo</value>
> > </name-key>
> > <classloader>
> > <import>
> > <groupId>geronimo</groupId>
> > <type>car</type>
> > <artifactId>geronimo-system</artifactId>
> > <version>1.0.1-SNAPSHOT</version>
> > </import>
> > <dependency>
> > <groupId>geronimo</groupId>
> > <artifactId>geronimo-common</artifactId>
> > <version>1.0.1-SNAPSHOT</version>
> > </dependency>
> > <include>
> > <groupId>geronimo</groupId>
> > <artifactId>geronimo-deployment</artifactId>
> > <version>1.0.1-SNAPSHOT</version>
> > </include>
> > </classloader>
> > <!--reference is a new element, the meaning is that the configuration
> > must be loaded and started before this one, but the classloader of
> > the config is not a parent -->
> > <reference>
> > <groupId>geronimo</groupId>
> > <type>car</type>
> > <artifactId>geronimo-j2ee</artifactId>
> > <version>1.0.1-SNAPSHOT</version>
> > </reference>
> > </environment>
> > <!--Deployer used to process modules and plans-->
> > <gbean name="Deployer"
> > class="org.apache.geronimo.deployment.Deployer">
> >
> >
> > An alternate layout is more similar to m2 with the idea of different
> > functions for a dependency shown by a "scope" element. Scope doesn't
> > seem like the right element name for us. (sorry about the lousy
> > indenting)
> >
> > <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>
> > <!-- name-key elements are very unlikely to be used by anything
> > except "root" system plans
> > such as j2ee-system. Included here only to show what they look like -->
> > <name-key>
> > <key>domain</key>
> > <value>geronimo.maven</value>
> > </name-key>
> > <name-key>
> > <key>J2EEServer</key>
> > <value>geronimo</value>
> > </name-key>
> > < dependency>
> > <groupId>geronimo</groupId>
> > <type>car</type>
> > <artifactId>geronimo-system</artifactId>
> > <version>1.0.1-SNAPSHOT</version>
> > <scope>full</scope>
> > </dependency>
> > <dependency>
> > <groupId>geronimo</groupId>
> > <artifactId>geronimo-common</artifactId>
> > <version>1.0.1-SNAPSHOT</version>
> > <scope>class</scope>
> > </dependency>
> > < dependency>
> > <groupId>geronimo</groupId>
> > <artifactId>geronimo-deployment</artifactId>
> > <version>1.0.1-SNAPSHOT</version>
> > <scope>include</scope>
> > </dependency>
> > < dependency>
> > <groupId>geronimo</groupId>
> > <type>car</type>
> > <artifactId>geronimo-j2ee</artifactId>
> > <version>1.0.1-SNAPSHOT</version>
> > <scope>service</scope>
> > </dependency>
> > </environment>
> > <!--Deployer used to process modules and plans-->
> > <gbean name="Deployer"
> > class="org.apache.geronimo.deployment.Deployer">
> >
> > Here, the scopes have meaning as follows:
> >
> > both -- both classes and services (gbeans), like import
> > classes -- only classes, if a car don't start the gbeans for us, like
> > dependency
> > services -- only gbeans, don't add classes to our classpath, like
> > reference (new element shown in first example)
> > include -- copy the artifact into the current configuration. This
> > seems like a separate dimension not related to the previous scopes.
> >
> > Again, please study these and comment.
>
> Here are my thoughts so far.
>
> I definitely prefer the second example better because it requires
> specifying the scope on a per dependency basis. In fact, I think that
> specifying everything for a given dependency with that dependency is
> far easier to understand. I also think that this is less confusing and
> much more like Maven which many people already understand.
>
> Speaking of dependencies, I'm thinking that an element named
> dependencies should be used as a container element for each dependency
> element. Again, similar to Maven which many people already understand.
>
> I also have some additional suggestions:
>
> 1) It seems like the name-key elements should be wrapped in another
> element. Perhaps an element named name-pattern or something similar.
>
> 2) How is order specified on the name-key elements? It's important to
> assemble these elements in the proper order.
>
> 3) In fact, just allowing a single string pattern would also be a nice
> alternative too.
>
> Here is one example:
>
> <name-pattern>
> <name-key index="0">
> <key>domain</key>
> <value>geronimo.maven</value>
> </name-key>
> <name-key index="1">
> <key>J2EEServer</key>
> <value>geronimo</value>
> </name-key>
> </name-pattern>
>
> Here is another example:
>
> <name-pattern>
> domain=geronimo.maven,J2EEServer=geronmo
> </name-pattern>
>
> I know that this second example needs a bit more parsing, but it
> should be minimal.
>
> Just my $0.02.
>
> Bruce
> --
> perl -e 'print unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
> );'
>
> Apache Geronimo (http://geronimo.apache.org/)
>
> Castor (http://castor.org/)
>
Re: Sample plan bits for configId branch, please review!
Posted by Bruce Snyder <br...@gmail.com>.
On 2/14/06, David Jencks <da...@yahoo.com> wrote:
> We need some widespread thought about the new xml schema we're
> getting in 1.1. Dain and I are not particularly thrilled with the
> element names but haven't thought of improvements. We also thought
> of an alternate way of presenting the info and would like opinions on
> which is better.
>
> The schema currently in svn in the configid branch results in plans
> that start like this:
>
> <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>
> <!-- name-key elements are very unlikely to be used by anything
> except "root" system plans
> such as j2ee-system. Included here only to show what they look like -->
> <name-key>
> <key>domain</key>
> <value>geronimo.maven</value>
> </name-key>
> <name-key>
> <key>J2EEServer</key>
> <value>geronimo</value>
> </name-key>
> <classloader>
> <import>
> <groupId>geronimo</groupId>
> <type>car</type>
> <artifactId>geronimo-system</artifactId>
> <version>1.0.1-SNAPSHOT</version>
> </import>
> <dependency>
> <groupId>geronimo</groupId>
> <artifactId>geronimo-common</artifactId>
> <version>1.0.1-SNAPSHOT</version>
> </dependency>
> <include>
> <groupId>geronimo</groupId>
> <artifactId>geronimo-deployment</artifactId>
> <version>1.0.1-SNAPSHOT</version>
> </include>
> </classloader>
> <!--reference is a new element, the meaning is that the configuration
> must be loaded and started before this one, but the classloader of
> the config is not a parent -->
> <reference>
> <groupId>geronimo</groupId>
> <type>car</type>
> <artifactId>geronimo-j2ee</artifactId>
> <version>1.0.1-SNAPSHOT</version>
> </reference>
> </environment>
> <!--Deployer used to process modules and plans-->
> <gbean name="Deployer"
> class="org.apache.geronimo.deployment.Deployer">
>
>
> An alternate layout is more similar to m2 with the idea of different
> functions for a dependency shown by a "scope" element. Scope doesn't
> seem like the right element name for us. (sorry about the lousy
> indenting)
>
> <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>
> <!-- name-key elements are very unlikely to be used by anything
> except "root" system plans
> such as j2ee-system. Included here only to show what they look like -->
> <name-key>
> <key>domain</key>
> <value>geronimo.maven</value>
> </name-key>
> <name-key>
> <key>J2EEServer</key>
> <value>geronimo</value>
> </name-key>
> < dependency>
> <groupId>geronimo</groupId>
> <type>car</type>
> <artifactId>geronimo-system</artifactId>
> <version>1.0.1-SNAPSHOT</version>
> <scope>full</scope>
> </dependency>
> <dependency>
> <groupId>geronimo</groupId>
> <artifactId>geronimo-common</artifactId>
> <version>1.0.1-SNAPSHOT</version>
> <scope>class</scope>
> </dependency>
> < dependency>
> <groupId>geronimo</groupId>
> <artifactId>geronimo-deployment</artifactId>
> <version>1.0.1-SNAPSHOT</version>
> <scope>include</scope>
> </dependency>
> < dependency>
> <groupId>geronimo</groupId>
> <type>car</type>
> <artifactId>geronimo-j2ee</artifactId>
> <version>1.0.1-SNAPSHOT</version>
> <scope>service</scope>
> </dependency>
> </environment>
> <!--Deployer used to process modules and plans-->
> <gbean name="Deployer"
> class="org.apache.geronimo.deployment.Deployer">
>
> Here, the scopes have meaning as follows:
>
> both -- both classes and services (gbeans), like import
> classes -- only classes, if a car don't start the gbeans for us, like
> dependency
> services -- only gbeans, don't add classes to our classpath, like
> reference (new element shown in first example)
> include -- copy the artifact into the current configuration. This
> seems like a separate dimension not related to the previous scopes.
>
> Again, please study these and comment.
Here are my thoughts so far.
I definitely prefer the second example better because it requires
specifying the scope on a per dependency basis. In fact, I think that
specifying everything for a given dependency with that dependency is
far easier to understand. I also think that this is less confusing and
much more like Maven which many people already understand.
Speaking of dependencies, I'm thinking that an element named
dependencies should be used as a container element for each dependency
element. Again, similar to Maven which many people already understand.
I also have some additional suggestions:
1) It seems like the name-key elements should be wrapped in another
element. Perhaps an element named name-pattern or something similar.
2) How is order specified on the name-key elements? It's important to
assemble these elements in the proper order.
3) In fact, just allowing a single string pattern would also be a nice
alternative too.
Here is one example:
<name-pattern>
<name-key index="0">
<key>domain</key>
<value>geronimo.maven</value>
</name-key>
<name-key index="1">
<key>J2EEServer</key>
<value>geronimo</value>
</name-key>
</name-pattern>
Here is another example:
<name-pattern>
domain=geronimo.maven,J2EEServer=geronmo
</name-pattern>
I know that this second example needs a bit more parsing, but it
should be minimal.
Just my $0.02.
Bruce
--
perl -e 'print unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
);'
Apache Geronimo (http://geronimo.apache.org/)
Castor (http://castor.org/)
Re: Sample plan bits for configId branch, please review!
Posted by Paul McMahan <pa...@gmail.com>.
Both options seem pretty equal to me in terms of what they can express but I
like the second option better mostly for stylistic reasons. Namely, based
on a hunch that typical deployment plans would be less verbose (and
therefore less error prone) using this option.
A few suggestions for the second option:
- Make the current environment/configId element also be a child of the
dependency element.
This would help make it clear that the "type", "groupId", "version",
etc. elements describe
the target of the dependency and not the dependency itself.
- "scope" seems a bit of a misnomer to me, I think "dependency-type" might
be clearer, or
you may prefer just "type" if you agree with the previous suggestion
- For the value of scope (aka dependency-type) I'm concerned that "both"
could be
misleading since it already has more than two potential values and more
could be added
later. So I would suggest listing each scope individually.
Here's an example of what the dependency element could look like based on
these suggestions:
<dependency>
<configId>
<groupId>geronimo</groupId>
<type>car</type>
<artifactId>geronimo-gbean-deployer</artifactId>
<version>1.0.1-SNAPSHOT</version>
</configId>
<dependency-types>
<dependency-type>service</dependency-type>
<dependency-type>classes</dependency-type>
...
<dependency-types>
</dependency>
Best wishes,
Paul
On 2/14/06, David Jencks <da...@yahoo.com> wrote:
>
> We need some widespread thought about the new xml schema we're
> getting in 1.1. Dain and I are not particularly thrilled with the
> element names but haven't thought of improvements. We also thought
> of an alternate way of presenting the info and would like opinions on
> which is better.
>
> The schema currently in svn in the configid branch results in plans
> that start like this: [snip]
>