You are viewing a plain text version of this content. The canonical link for it is here.
Posted to cvs@avalon.apache.org by do...@apache.org on 2002/08/28 13:50:59 UTC
cvs commit: jakarta-avalon-excalibur/containerkit/src/java/org/apache/excalibur/containerkit/demo/components Component1-info.xml
donaldp 2002/08/28 04:50:59
Modified: containerkit/src/java/org/apache/excalibur/containerkit/tools/infobuilder
componentinfo.dtd XMLInfoCreator.java
containerkit/src/java/org/apache/excalibur/containerkit/demo/components
Component1-info.xml
Log:
Allow attributes to have their data specified as content rather than as value of an attribute.
Revision Changes Path
1.2 +2 -2 jakarta-avalon-excalibur/containerkit/src/java/org/apache/excalibur/containerkit/tools/infobuilder/componentinfo.dtd
Index: componentinfo.dtd
===================================================================
RCS file: /home/cvs/jakarta-avalon-excalibur/containerkit/src/java/org/apache/excalibur/containerkit/tools/infobuilder/componentinfo.dtd,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- componentinfo.dtd 18 Aug 2002 06:39:00 -0000 1.1
+++ componentinfo.dtd 28 Aug 2002 11:50:58 -0000 1.2
@@ -133,10 +133,10 @@
key the key for attribute.
value the value of attribute.
-->
-<!ELEMENT attribute EMPTY >
+<!ELEMENT attribute (#PCDATA) >
<!ATTLIST attribute
key CDATA #REQUIRED
- value CDATA #REQUIRED
+ value CDATA #IMPLIED
>
<!--
1.2 +6 -2 jakarta-avalon-excalibur/containerkit/src/java/org/apache/excalibur/containerkit/tools/infobuilder/XMLInfoCreator.java
Index: XMLInfoCreator.java
===================================================================
RCS file: /home/cvs/jakarta-avalon-excalibur/containerkit/src/java/org/apache/excalibur/containerkit/tools/infobuilder/XMLInfoCreator.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- XMLInfoCreator.java 18 Aug 2002 06:39:00 -0000 1.1
+++ XMLInfoCreator.java 28 Aug 2002 11:50:58 -0000 1.2
@@ -371,7 +371,11 @@
{
Configuration child = children[ i ];
final String key = child.getAttribute( "key" );
- final String value = child.getAttribute( "value" );
+ String value = child.getAttribute( "value", null );
+ if( null == value )
+ {
+ value = child.getValue();
+ }
attributes.setProperty( key, value );
}
return attributes;
1.2 +6 -0 jakarta-avalon-excalibur/containerkit/src/java/org/apache/excalibur/containerkit/demo/components/Component1-info.xml
Index: Component1-info.xml
===================================================================
RCS file: /home/cvs/jakarta-avalon-excalibur/containerkit/src/java/org/apache/excalibur/containerkit/demo/components/Component1-info.xml,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- Component1-info.xml 23 Aug 2002 08:51:15 -0000 1.1
+++ Component1-info.xml 28 Aug 2002 11:50:59 -0000 1.2
@@ -18,6 +18,12 @@
<services>
<service>
<service-ref type="org.apache.excalibur.containerkit.demo.components.Service1"/>
+ <attributes>
+ <attribute key="foo" value="bar"/>
+ <attribute key="foo2">
+ blah blah blah
+ </attribute>
+ </attributes>
</service>
</services>
</component-info>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: cvs commit: jakarta-avalon-excalibur/containerkit/src/java/org/apache/excalibur/containerkit/demo/components Component1-info.xml
Posted by Peter Donald <pe...@apache.org>.
On Fri, 30 Aug 2002 01:30, Nicola Ken Barozzi wrote:
> Hmmm... I'd just keep the description in one language with descriptions
> via a key in a bundle...
How do you define key? Would it be with attributes?
How about when you start breaking up description into multiple parts. For
example heres the things that I can think of off the top of my head that may
be needed long term;
* display name (how displayed on screen)
* Short description (basically a one liner ala the javadocs first line)
* Description (2-3 paragraphs)
* Long Description (potentially this would be needed if there were lots of
detail)
Though "Long Description" may not be needed and Short Description could be
derived from Description via same way javadocs derives one liners (ie take
first sentence).
> >>We could just use a standard name for the bundle, keep english stuff in
> >>the descriptor and a key for external translations.
> >
> > WHich is precisely the reasoning that lead me to use attributes ;)
>
> What about this then.
> I changed the example componentinfo dtd to make it more consistent,
> extensible and near to literate programming, which has struck a cord in
> me lately.
Maybe - thats kinda like we originally had ir. We went from avalons to flat,
then back to whate we have now which is essentially
-info
-group
-entry
-attribute
Though entry may be complex (for usability purposes).
I still think that
<attribute name="doc:display-name" value="Mr Fancy Pants Component"/>
<attribute name="doc:description" value="Fantastic and great component!!!"/>
is simpler. Or if we want i18n then we go with
<attribute name="doc:display-name-key" value="display.name"/>
<attribute name="doc:description-key" value="description"/>
<attribute name="doc:i18n-bundle" value="MyBundle"/>
I guess having content in an attribute is kinda ugly. So maybe we just state
that if a component has a long description it has to be in resource file.
This has two advantages
* descriptions wont be loaded unless the user explicitly asks
* attributes no longer need content
--
Cheers,
Peter Donald
--------------------------------------------------
Logic: The art of being wrong with confidence...
--------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: cvs commit: jakarta-avalon-excalibur/containerkit/src/java/org/apache/excalibur/containerkit/demo/components
Component1-info.xml
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Peter Donald wrote:
> On Thu, 29 Aug 2002 17:23, Nicola Ken Barozzi wrote:
>
>>Peter Donald wrote:
>>
>>>On Wed, 28 Aug 2002 22:53, Nicola Ken Barozzi wrote:
>>>
>>>>Ok, I understand the need, but then, why under the attributes?
>>>>Why not a <description> taga ala Ant, it doesn't seem like a generic
>>>>attribut to me...
>>>
>>>The problem is when you want to do i18n of the description. Currently it
>>>is done via
>>>
>>><!-- use the following if you dont care about i18n -->
>>><attribute name="doc:description" value="Some description" />
>>>
>>><!-- use the following if you do care about i18n. -->
>>><attribute name="doc:description-key" value="my.key" />
>>>
>>><!--
>>> Note that you would have to include a resources
>>> file side-by-side the info file with the name
>>> MyClassNameInfo.*. However you could overide
>>> the location of the Info file via
>>>-->
>>><attribute name="doc:i18n-bundle" value="MyClassNameInfo2" />
>>>
>>>I think I would prefer a description element, but how would you deal with
>>>the above?
>>
>>There are various options, here are the most relevant:
>>
>>XML language identification
>>-----------------------------
>>http://www.w3.org/TR/REC-xml#sec-lang-tag
>>
>><description>
>> <p xml:lang="en">The quick brown fox jumps over the lazy dog.</p>
>> <p xml:lang="en-GB">What colour is it?</p>
>> <p xml:lang="en-US">What color is it?</p>
>> <sp who="Faust" desc='leise' xml:lang="de">
>> <l>Habe nun, ach! Philosophie,</l>
>> <l>Juristerei, und Medizin</l>
>> <l>und leider auch Theologie</l>
>> <l>durchaus studiert mit heißem Bemüh'n.</l>
>> </sp>
>></description>
>>
>>Comment: standard, but not flexible enough.
>>
>>Cocoon i18n tags:
>>------------------
>>http://xml.apache.org/cocoon/userdocs/transformers/i18n-transformer.html
>>
>><description>
>> <para title="first" name="article" i18n:attr="title name">
>> <i18n:text>This text will be translated.</i18n:text>
>> </para>
>> <i18n:text i18n:key="key_text">Default value</i18n:text>
>> <i18n:translate>
>> <i18n:text>Some {0} was inserted {1}.</i18n:text>
>> <i18n:param>text</i18n:param>
>> <i18n:param>here</i18n:param>
>> </i18n:translate>
>></description>
>>
>>Comment:
>>important features are:
>>- Attribute translation
>>- Param substitution
>>It's more flexible and already has a Transformer to do the work, also
>>from an i18n file
>>Since Morphos can easily be made to use Cocoon Components, it can easily
>>be used as a MorpherAntTask to do the transformations.
>
>
> Both solutions all seem a bit complex. Descriptions are essentially blobs of
> text and thus don't need substitution or anything like that. All they need is
> to say blob A is in language X while blob B is in language Y.
Hmmm... I'd just keep the description in one language with descriptions
via a key in a bundle...
>>We could just use a standard name for the bundle, keep english stuff in
>>the descriptor and a key for external translations.
>
> WHich is precisely the reasoning that lead me to use attributes ;)
What about this then.
I changed the example componentinfo dtd to make it more consistent,
extensible and near to literate programming, which has struck a cord in
me lately.
We have
-[1]component-info
-[1]component-entry
-[1..n]attribute
-[1]context-entry
-[1..n]attribute
-[1..n]service-entry
-[1..n]attribute
-[1..n]dependency-entry
-[1..n]attribute
Each entry has these:
- entry - id
- version
- optional y/n
Each attribute has these:
- attribute - key
- value
- optional y/n
- included text is the description
In this way extending this is just a matter of defining new entries, and
new keys for attributes.
Entries and avalon: attributes must be in the Avalon contract, the rest
are defined by the developer, or using other internal standard.
Each xinfo file can have an xbundle file too, that maps paths to
language and translation (see below), or it can be embedded directly in
the xinfo file in a i18n entry.
<component-info>
<component id="my-component"
version="1.2.1"
optional="FALSE">
<attribute key="avalon:version"
value="1.2.1"
>This is a cool Service :-)</attribute>
<attribute key="avalon:lifestyle"
value="THREAD_SAFE"
>It must be threadsafe, or else....</attribute>
</component>
<context id = "my-context"
version = "1.1.0"
optional= "FALSE">
<attribute key="local:base"
value="java.io.File"
>The base from where all starts.</attribute>
<attribute key="local:mode"
value="java.lang.Object"
optional="TRUE"
>Keeps the mode Object, used by my system.</attribute>
</context>
<service id="my-service"
version="1.1.0"
optional="FALSE">
<attribute key="avalon:reference"
value="SimpleService"
optional="FALSE"
>This can be used to ...</attribute>
</service>
<dependency id="my-component"
version="1.2.1">
<attribute key="avalon:reference"
value="org.apache.cocoon.api.Transformer#1.1"
optional="FALSE"
>It depends on the transformer because...</attribute>
</dependency>
</component-info>
<bundle>
<item id="my-component">
<attribute="avalon:reference">
<text lang="IT">Ciao</text>
<text lang="D">Hallo</text>
</attribute>
</item>
...
</bundle>
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: cvs commit: jakarta-avalon-excalibur/containerkit/src/java/org/apache/excalibur/containerkit/demo/components Component1-info.xml
Posted by Peter Donald <pe...@apache.org>.
On Thu, 29 Aug 2002 17:23, Nicola Ken Barozzi wrote:
> Peter Donald wrote:
> > On Wed, 28 Aug 2002 22:53, Nicola Ken Barozzi wrote:
> >>Ok, I understand the need, but then, why under the attributes?
> >>Why not a <description> taga ala Ant, it doesn't seem like a generic
> >>attribut to me...
> >
> > The problem is when you want to do i18n of the description. Currently it
> > is done via
> >
> > <!-- use the following if you dont care about i18n -->
> > <attribute name="doc:description" value="Some description" />
> >
> > <!-- use the following if you do care about i18n. -->
> > <attribute name="doc:description-key" value="my.key" />
> >
> > <!--
> > Note that you would have to include a resources
> > file side-by-side the info file with the name
> > MyClassNameInfo.*. However you could overide
> > the location of the Info file via
> > -->
> > <attribute name="doc:i18n-bundle" value="MyClassNameInfo2" />
> >
> > I think I would prefer a description element, but how would you deal with
> > the above?
>
> There are various options, here are the most relevant:
>
> XML language identification
> -----------------------------
> http://www.w3.org/TR/REC-xml#sec-lang-tag
>
> <description>
> <p xml:lang="en">The quick brown fox jumps over the lazy dog.</p>
> <p xml:lang="en-GB">What colour is it?</p>
> <p xml:lang="en-US">What color is it?</p>
> <sp who="Faust" desc='leise' xml:lang="de">
> <l>Habe nun, ach! Philosophie,</l>
> <l>Juristerei, und Medizin</l>
> <l>und leider auch Theologie</l>
> <l>durchaus studiert mit heißem Bemüh'n.</l>
> </sp>
> </description>
>
> Comment: standard, but not flexible enough.
>
> Cocoon i18n tags:
> ------------------
> http://xml.apache.org/cocoon/userdocs/transformers/i18n-transformer.html
>
> <description>
> <para title="first" name="article" i18n:attr="title name">
> <i18n:text>This text will be translated.</i18n:text>
> </para>
> <i18n:text i18n:key="key_text">Default value</i18n:text>
> <i18n:translate>
> <i18n:text>Some {0} was inserted {1}.</i18n:text>
> <i18n:param>text</i18n:param>
> <i18n:param>here</i18n:param>
> </i18n:translate>
> </description>
>
> Comment:
> important features are:
> - Attribute translation
> - Param substitution
> It's more flexible and already has a Transformer to do the work, also
> from an i18n file
> Since Morphos can easily be made to use Cocoon Components, it can easily
> be used as a MorpherAntTask to do the transformations.
Both solutions all seem a bit complex. Descriptions are essentially blobs of
text and thus don't need substitution or anything like that. All they need is
to say blob A is in language X while blob B is in language Y.
> We could just use a standard name for the bundle, keep english stuff in
> the descriptor and a key for external translations.
WHich is precisely the reasoning that lead me to use attributes ;)
--
Cheers,
Peter Donald
--------------------------------------------
Beer is proof that God loves us and wants
us to be happy. -- Benjamin Franklin
--------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
OpenEJB
Posted by Paul Hammant <pa...@yahoo.com>.
http://openejb.sourceforge.net/embedded.html
It seems we could make a Phoenix block that hosts EJBs using the above. If anyone wants to take
on the task, it could be fairly simple to get to a point where you know it will work or not.
- Paul
__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
OpenEJB
Posted by Paul Hammant <pa...@yahoo.com>.
http://openejb.sourceforge.net/embedded.html
It seems we could make a Phoenix block that hosts EJBs using the above. If anyone wants to take
on the task, it could be fairly simple to get to a point where you know it will work or not.
- Paul
__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: cvs commit: jakarta-avalon-excalibur/containerkit/src/java/org/apache/excalibur/containerkit/demo/components
Component1-info.xml
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Peter Donald wrote:
> On Wed, 28 Aug 2002 22:53, Nicola Ken Barozzi wrote:
>
>>Ok, I understand the need, but then, why under the attributes?
>>Why not a <description> taga ala Ant, it doesn't seem like a generic
>>attribut to me...
>
>
> The problem is when you want to do i18n of the description. Currently it is
> done via
>
> <!-- use the following if you dont care about i18n -->
> <attribute name="doc:description" value="Some description" />
>
> <!-- use the following if you do care about i18n. -->
> <attribute name="doc:description-key" value="my.key" />
>
> <!--
> Note that you would have to include a resources
> file side-by-side the info file with the name
> MyClassNameInfo.*. However you could overide
> the location of the Info file via
> -->
> <attribute name="doc:i18n-bundle" value="MyClassNameInfo2" />
>
> I think I would prefer a description element, but how would you deal with the
> above?
There are various options, here are the most relevant:
XML language identification
-----------------------------
http://www.w3.org/TR/REC-xml#sec-lang-tag
<description>
<p xml:lang="en">The quick brown fox jumps over the lazy dog.</p>
<p xml:lang="en-GB">What colour is it?</p>
<p xml:lang="en-US">What color is it?</p>
<sp who="Faust" desc='leise' xml:lang="de">
<l>Habe nun, ach! Philosophie,</l>
<l>Juristerei, und Medizin</l>
<l>und leider auch Theologie</l>
<l>durchaus studiert mit heißem Bemüh'n.</l>
</sp>
</description>
Comment: standard, but not flexible enough.
Cocoon i18n tags:
------------------
http://xml.apache.org/cocoon/userdocs/transformers/i18n-transformer.html
<description>
<para title="first" name="article" i18n:attr="title name">
<i18n:text>This text will be translated.</i18n:text>
</para>
<i18n:text i18n:key="key_text">Default value</i18n:text>
<i18n:translate>
<i18n:text>Some {0} was inserted {1}.</i18n:text>
<i18n:param>text</i18n:param>
<i18n:param>here</i18n:param>
</i18n:translate>
</description>
Comment:
important features are:
- Attribute translation
- Param substitution
It's more flexible and already has a Transformer to do the work, also
from an i18n file
Since Morphos can easily be made to use Cocoon Components, it can easily
be used as a MorpherAntTask to do the transformations.
I would go with the Cocoon stuff, since it can make us comment also with
attributes and translate it, and use an external resource bundle.
We could just use a standard name for the bundle, keep english stuff in
the descriptor and a key for external translations.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: cvs commit: jakarta-avalon-excalibur/containerkit/src/java/org/apache/excalibur/containerkit/demo/components Component1-info.xml
Posted by Peter Donald <pe...@apache.org>.
On Wed, 28 Aug 2002 22:53, Nicola Ken Barozzi wrote:
> Ok, I understand the need, but then, why under the attributes?
> Why not a <description> taga ala Ant, it doesn't seem like a generic
> attribut to me...
The problem is when you want to do i18n of the description. Currently it is
done via
<!-- use the following if you dont care about i18n -->
<attribute name="doc:description" value="Some description" />
<!-- use the following if you do care about i18n. -->
<attribute name="doc:description-key" value="my.key" />
<!--
Note that you would have to include a resources
file side-by-side the info file with the name
MyClassNameInfo.*. However you could overide
the location of the Info file via
-->
<attribute name="doc:i18n-bundle" value="MyClassNameInfo2" />
I think I would prefer a description element, but how would you deal with the
above?
--
Cheers,
Peter Donald
"Artists can color the sky red because they know it's blue. Those of us who
aren't artists must color things the way they really are or people might
think we're stupid." -- Jules Feiffer
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: cvs commit: jakarta-avalon-excalibur/containerkit/src/java/org/apache/excalibur/containerkit/demo/components
Component1-info.xml
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Peter Donald wrote:
> On Wed, 28 Aug 2002 22:23, Nicola Ken Barozzi wrote:
>
>>donaldp@apache.org wrote:
>>
>>>donaldp 2002/08/28 04:50:59
>>>
>>> Modified:
>>>containerkit/src/java/org/apache/excalibur/containerkit/tools/infobuilder
>>>componentinfo.dtd XMLInfoCreator.java
>>>
>>>containerkit/src/java/org/apache/excalibur/containerkit/demo/components
>>>Component1-info.xml
>>> Log:
>>> Allow attributes to have their data specified as content rather than as
>>>value of an attribute.
>>>
>>>
>>> + <attribute key="foo" value="bar"/>
>>> + <attribute key="foo2">
>>> + blah blah blah
>>> + </attribute>
>>
>>Any real need for this?
>>It creates confusion with the handling of newlines, and consistency
>>with usual Configurations that in practice usually never use content.
>
>
> Theres a need. I am generating web pages for each component that describes the
> component and dependencies and so forth. Part of the descriptor is including
> a description string and when you try to put it in an attribute it gets real
> ugly. ie Try putting four paragraphs of escaped html in an attribute and you
> will see what I mean ;)
;-)
Ok, I understand the need, but then, why under the attributes?
Why not a <description> taga ala Ant, it doesn't seem like a generic
attribut to me...
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: cvs commit: jakarta-avalon-excalibur/containerkit/src/java/org/apache/excalibur/containerkit/demo/components Component1-info.xml
Posted by Peter Donald <pe...@apache.org>.
On Wed, 28 Aug 2002 22:23, Nicola Ken Barozzi wrote:
> donaldp@apache.org wrote:
> > donaldp 2002/08/28 04:50:59
> >
> > Modified:
> > containerkit/src/java/org/apache/excalibur/containerkit/tools/infobuilder
> > componentinfo.dtd XMLInfoCreator.java
> >
> > containerkit/src/java/org/apache/excalibur/containerkit/demo/components
> > Component1-info.xml
> > Log:
> > Allow attributes to have their data specified as content rather than as
> > value of an attribute.
> >
> >
> > + <attribute key="foo" value="bar"/>
> > + <attribute key="foo2">
> > + blah blah blah
> > + </attribute>
>
> Any real need for this?
> It creates confusion with the handling of newlines, and consistency
> with usual Configurations that in practice usually never use content.
Theres a need. I am generating web pages for each component that describes the
component and dependencies and so forth. Part of the descriptor is including
a description string and when you try to put it in an attribute it gets real
ugly. ie Try putting four paragraphs of escaped html in an attribute and you
will see what I mean ;)
--
Cheers,
Peter Donald
-----------------------------------------------------------------------
| I thought there was a knob on the TV to turn up the intelligence. |
| There's a knob called "brightness", but it doesn't work. |
-----------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: cvs commit: jakarta-avalon-excalibur/containerkit/src/java/org/apache/excalibur/containerkit/demo/components
Component1-info.xml
Posted by Nicola Ken Barozzi <ni...@apache.org>.
donaldp@apache.org wrote:
> donaldp 2002/08/28 04:50:59
>
> Modified: containerkit/src/java/org/apache/excalibur/containerkit/tools/infobuilder
> componentinfo.dtd XMLInfoCreator.java
> containerkit/src/java/org/apache/excalibur/containerkit/demo/components
> Component1-info.xml
> Log:
> Allow attributes to have their data specified as content rather than as value of an attribute.
> + <attribute key="foo" value="bar"/>
> + <attribute key="foo2">
> + blah blah blah
> + </attribute>
Any real need for this?
It creates confusion with the handling of newlines, and consistency
with usual Configurations that in practice usually never use content.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>