You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Jakob Praher <jp...@yahoo.de> on 2003/01/07 17:09:55 UTC
custom metatdata attributes
hi all,
as we (Leo and I) have talked about custom metadata attribute support
for java lately, I wanted to know whether this should be done inside
avalon, or should be delegated to another (jakarta) project.
if inside avalon, I was wondering what approach towards implementing
them should be taken. (class augmentation, manifest files, ...)
I am curious about your opinons, and I am interested in helping with the
implementation.
-- Jakob
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: custom metatdata attributes
Posted by Jakob Praher <jp...@yahoo.de>.
Am Die, 2003-01-07 um 17.44 schrieb Leo Simons:
> Jakob Praher wrote:
> > hi all,
> >
> > as we (Leo and I) have talked about custom metadata attribute support
> > for java lately, I wanted to know whether this should be done inside
> > avalon, or should be delegated to another (jakarta) project.
>
btw: just came accross following site: http://attrib4j.sourceforge.net/
they are doing what I proposed using bcel - don't know any details yet.
nanning.sourceforge.net also adds attribute tags (commons-attribute uses
the doclet names of the nanning project)
> according to KISS, it should be a standalone library. There's lots of
> locations where something like that can be done. Sice Jakarta Commons
> already has some stuff regarding this in their sandbox I figured we'd
> start there.
>
agreed - KISS is an important design goal.
> > if inside avalon, I was wondering what approach towards implementing
> > them should be taken. (class augmentation, manifest files, ...)
>
> I'm leaning towards parsing of
>
> /** @attribute SomeClassNameAttribute("blaat") */
> class MyClass
>
> where an ant+qdox solution is run over this at build time. Such an
> AttributeParserTask could generate lots of stuff. The most important
> thing to agree on the syntax of the source files; you can always plug in
> lots of different generators.
nanning and commons-attribute use:
@classAttribute
@methodAttribute
@fieldAttribute
but as you sugested I too would like to use the more generic
@attribute FQCN( ActualPars )
syntax.
according to a paper I found via google, that's what J# is doing to bind
CLR attributes to "Java.NET".
>
> I would probably be most comfortable with this ending up in an xml file
> coupled to the class, ie something like:
>
> MyClass.attributes
> ------------------
> <attributes>
> <attribute
> class="SomeClassName"
> target="class">
> <constructor>
> <string value="blaat"/>
> </constructor>
> </attribute>
> </attributes>
>
I found something similiar with the betwixt project.
I like the idea, but would also like to define a sort of object model to
discover attributes at runtime:
something like:
class AttributedClass {
Attribute[] getClassAttribtues( )
Attribute[] getMethodAttribtues( String methodName );
Attribute[] getFieldAttributes( String fieldName ) ;
}
don't actually know how's .NET Api for discovering attributes.
the only funny thing is that JMX and JMI use the term Attribute to
denote Fields, but I don't know a better name for custom meta data ....
(at least yet).
> or maybe adopt the SOAP serializers from Axis for generation of
> everything inside <attribute/>. Something like that. (I believe .Net
> uses SOAP for serialization by default.) That's mostly because it is
> consistent with the approach avalon currently takes.
>
I only know about the betwixt framework from jakarta-commons. Don't know
that much about the SOAP serializers from Axis but am very curious about
anything like that - will definitely look into it.
> > I am curious about your opinons,
>
> me too :D I am actually waiting for a reply from some of the people
> who've done a lot of the meta/attribute stuff currently in place @
> avalon, in particular Peter Donald (hi pete!). I suspect he's still
> catching up wrt e-mail...holidays y'know.
>
> > and I am interested in helping with the
> > implementation.
> We'll go with the flow from there (I haven't been particularly active in
> commons before, but I believe I have commit rights to commons sandbox,
> so if there's no response it's probably okay for us to work on it there).
jup.
thanks for your reply.
-- Jakob
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: custom metatdata attributes
Posted by Peter Donald <pe...@realityforge.org>.
On Sat, 11 Jan 2003 04:20, Jakob Praher wrote:
> Am Mit, 2003-01-08 um 06.23 schrieb Peter Donald:
> > Hi,
> >
> > On Wed, 8 Jan 2003 03:44, Leo Simons wrote:
> > > /** @attribute SomeClassNameAttribute("blaat") */
> >
> > I actually dislike that approach immensly ;) The way I have been doing it
> > is basically runtime access to javadocs with two different styles.
> >
> > * Tags with parameters. ie
> >
> > @avalon.service type="Foo" optional="true"
> >
> > * Tags with raw text. ie
> >
> > @description Here is a description of the gratest song in the world.
>
> how should this work within a generic implementing of attributes as
> serialized objects ?
It doesn't. Oririginally when I started experimenting with this stuff I used
serialized objects but the problem was that to load the objects the .class
file for the attribute had to be present and resolvable which could be a
problem in some of the more complicated classloader setups.
In the end I decided that implementing of attributes as generic serialized
objects was not worth the hassle. I also find that data-based specs tend to
be more resistent to change.
We could still support serialized objects and just interpret a string
attribute that had something like
org.apache.avalon.MyAttribute( x="value" )
But I am not sure what we would really gain. I would much rather use
data-based attributes and have a schema to validate them against.
> > This is the same approach xdoclet uses and it seems to work well!
>
> I have used xdoclet only in the context of castor once - so I don't know
> enough about it.
> But I was reading they are doing a complete rewrite for version 2.0 ...
Yep. They have been going to do the rewrite for a year or more ;) It looks
like they will use qdox which rocks. It also looks like they will be using a
model like I described above.
They had plans for a XRAI (Runtime attribute retrieval) but I don't know if
they ever got started. I also don't know if they have any plans for schema
language.
--
Cheers,
Peter Donald
*----------------------------------------------------*
| "the mother of idiots is always pregnant." |
*----------------------------------------------------*
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: custom metatdata attributes
Posted by Jakob Praher <jp...@yahoo.de>.
Am Mit, 2003-01-08 um 06.23 schrieb Peter Donald:
> Hi,
>
> On Wed, 8 Jan 2003 03:44, Leo Simons wrote:
> > /** @attribute SomeClassNameAttribute("blaat") */
>
> I actually dislike that approach immensly ;) The way I have been doing it is
> basically runtime access to javadocs with two different styles.
>
> * Tags with parameters. ie
>
> @avalon.service type="Foo" optional="true"
>
> * Tags with raw text. ie
>
> @description Here is a description of the gratest song in the world.
how should this work within a generic implementing of attributes as
serialized objects ?
one thing i could imagine is:
@attribute fqcn field1=value field2=value, .. for initialization
like this
@attribute org.apache.avalon.MyAttribute x="value"
but the same thing could be achieved using the Constructor method:
@attribute org.apache.avalon.MyAttribute( x="value" )
> This is the same approach xdoclet uses and it seems to work well!
I have used xdoclet only in the context of castor once - so I don't know
enough about it.
But I was reading they are doing a complete rewrite for version 2.0 ...
-- Jakob
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: custom metatdata attributes
Posted by Peter Donald <pe...@realityforge.org>.
Hi,
On Wed, 8 Jan 2003 03:44, Leo Simons wrote:
> /** @attribute SomeClassNameAttribute("blaat") */
I actually dislike that approach immensly ;) The way I have been doing it is
basically runtime access to javadocs with two different styles.
* Tags with parameters. ie
@avalon.service type="Foo" optional="true"
* Tags with raw text. ie
@description Here is a description of the gratest song in the world.
This is the same approach xdoclet uses and it seems to work well!
--
Cheers,
Peter Donald
-----------------------------------------------
| If you turn on the light quickly enough, |
| you can see what the dark looks like. |
-----------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: custom metatdata attributes
Posted by Jon Tirsén <jo...@yahoo.com>.
The stuff in the sandbox is donated from Nanning (http://nanning.sf.net)
and somewhat extended to support pluggability. It has currently stopped
a bit in development but I'd love to have it start again.
Currently only a raw string is supported as an attribute value, but this
could probably be processed in a zillion different ways. It is stored
into a simple properties-file. Currently only one value per attribute is
supported which would probably be the first thing to fix.
Some of the guys from Xdoclet was involved too so they are probably very
interested. XDoclet has a bit different syntax from .NET, namely:
/**
* @attribute property1=value1
* property2=value2
* property3=value3
*/
Where (I'm speculating a bit) the name of the attribute is mapped into a
class-name via some external configuration and properties are mapped
into JavaBean-properties. If you're looking at for example all the
attributes for EJB a name-value-syntax is much easier to use than an
argument list to a constructor.
Sorry for me cross-posting here but Leo started it. :-) (But I guess
that not all att avalon-dev subscribe to commons-dev, please feel free
to flame me if you like.)
> -----Original Message-----
> From: news [mailto:news@main.gmane.org] On Behalf Of Leo Simons
> Sent: Tuesday, January 07, 2003 5:45 PM
> To: commons-dev@jakarta.apache.org
> Cc: avalon-dev@jakarta.apache.org
> Subject: Re: custom metatdata attributes
>
>
> Jakob Praher wrote:
> > hi all,
> >
> > as we (Leo and I) have talked about custom metadata
> attribute support
> > for java lately, I wanted to know whether this should be
> done inside
> > avalon, or should be delegated to another (jakarta) project.
>
> according to KISS, it should be a standalone library. There's lots of
> locations where something like that can be done. Sice Jakarta Commons
> already has some stuff regarding this in their sandbox I figured we'd
> start there.
>
> > if inside avalon, I was wondering what approach towards
> implementing
> > them should be taken. (class augmentation, manifest files, ...)
>
> I'm leaning towards parsing of
>
> /** @attribute SomeClassNameAttribute("blaat") */
> class MyClass
>
> where an ant+qdox solution is run over this at build time. Such an
> AttributeParserTask could generate lots of stuff. The most important
> thing to agree on the syntax of the source files; you can
> always plug in
> lots of different generators.
>
> I would probably be most comfortable with this ending up in
> an xml file
> coupled to the class, ie something like:
>
> MyClass.attributes
> ------------------
> <attributes>
> <attribute
> class="SomeClassName"
> target="class">
> <constructor>
> <string value="blaat"/>
> </constructor>
> </attribute>
> </attributes>
>
> or maybe adopt the SOAP serializers from Axis for generation of
> everything inside <attribute/>. Something like that. (I believe .Net
> uses SOAP for serialization by default.) That's mostly because it is
> consistent with the approach avalon currently takes.
>
> > I am curious about your opinons,
>
> me too :D I am actually waiting for a reply from some of the people
> who've done a lot of the meta/attribute stuff currently in place @
> avalon, in particular Peter Donald (hi pete!). I suspect he's still
> catching up wrt e-mail...holidays y'know.
>
> > and I am interested in helping with the
> > implementation.
>
> That'd be neat! If you feel like getting started, the easiest
> thing to
> do is to probably check out jakarta-commons-sandbox, take the
> attribute
> code in there and run with it, then send patches to the commons list.
> I'm still orienting myself (still need to take a look at qdox/xdoclet
> first).
>
> The alternative is to try and drag requirements out of a
> broad group of
> people (I suspect potential interest is big :), but I'm
> guessing that's
> going to be difficult given the rather 'distributed' nature
> of that group.
>
> We'll go with the flow from there (I haven't been
> particularly active in
> commons before, but I believe I have commit rights to commons
> sandbox,
> so if there's no response it's probably okay for us to work
> on it there).
>
> cheers,
>
> - Leo
>
>
>
> --
> To unsubscribe, e-mail:
> <mailto:commons-dev-> unsubscribe@jakarta.apache.org>
> For
> additional commands,
> e-mail: <ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: custom metatdata attributes
Posted by Jon Tirsén <jo...@yahoo.com>.
The stuff in the sandbox is donated from Nanning (http://nanning.sf.net)
and somewhat extended to support pluggability. It has currently stopped
a bit in development but I'd love to have it start again.
Currently only a raw string is supported as an attribute value, but this
could probably be processed in a zillion different ways. It is stored
into a simple properties-file. Currently only one value per attribute is
supported which would probably be the first thing to fix.
Some of the guys from Xdoclet was involved too so they are probably very
interested. XDoclet has a bit different syntax from .NET, namely:
/**
* @attribute property1=value1
* property2=value2
* property3=value3
*/
Where (I'm speculating a bit) the name of the attribute is mapped into a
class-name via some external configuration and properties are mapped
into JavaBean-properties. If you're looking at for example all the
attributes for EJB a name-value-syntax is much easier to use than an
argument list to a constructor.
Sorry for me cross-posting here but Leo started it. :-) (But I guess
that not all att avalon-dev subscribe to commons-dev, please feel free
to flame me if you like.)
> -----Original Message-----
> From: news [mailto:news@main.gmane.org] On Behalf Of Leo Simons
> Sent: Tuesday, January 07, 2003 5:45 PM
> To: commons-dev@jakarta.apache.org
> Cc: avalon-dev@jakarta.apache.org
> Subject: Re: custom metatdata attributes
>
>
> Jakob Praher wrote:
> > hi all,
> >
> > as we (Leo and I) have talked about custom metadata
> attribute support
> > for java lately, I wanted to know whether this should be
> done inside
> > avalon, or should be delegated to another (jakarta) project.
>
> according to KISS, it should be a standalone library. There's lots of
> locations where something like that can be done. Sice Jakarta Commons
> already has some stuff regarding this in their sandbox I figured we'd
> start there.
>
> > if inside avalon, I was wondering what approach towards
> implementing
> > them should be taken. (class augmentation, manifest files, ...)
>
> I'm leaning towards parsing of
>
> /** @attribute SomeClassNameAttribute("blaat") */
> class MyClass
>
> where an ant+qdox solution is run over this at build time. Such an
> AttributeParserTask could generate lots of stuff. The most important
> thing to agree on the syntax of the source files; you can
> always plug in
> lots of different generators.
>
> I would probably be most comfortable with this ending up in
> an xml file
> coupled to the class, ie something like:
>
> MyClass.attributes
> ------------------
> <attributes>
> <attribute
> class="SomeClassName"
> target="class">
> <constructor>
> <string value="blaat"/>
> </constructor>
> </attribute>
> </attributes>
>
> or maybe adopt the SOAP serializers from Axis for generation of
> everything inside <attribute/>. Something like that. (I believe .Net
> uses SOAP for serialization by default.) That's mostly because it is
> consistent with the approach avalon currently takes.
>
> > I am curious about your opinons,
>
> me too :D I am actually waiting for a reply from some of the people
> who've done a lot of the meta/attribute stuff currently in place @
> avalon, in particular Peter Donald (hi pete!). I suspect he's still
> catching up wrt e-mail...holidays y'know.
>
> > and I am interested in helping with the
> > implementation.
>
> That'd be neat! If you feel like getting started, the easiest
> thing to
> do is to probably check out jakarta-commons-sandbox, take the
> attribute
> code in there and run with it, then send patches to the commons list.
> I'm still orienting myself (still need to take a look at qdox/xdoclet
> first).
>
> The alternative is to try and drag requirements out of a
> broad group of
> people (I suspect potential interest is big :), but I'm
> guessing that's
> going to be difficult given the rather 'distributed' nature
> of that group.
>
> We'll go with the flow from there (I haven't been
> particularly active in
> commons before, but I believe I have commit rights to commons
> sandbox,
> so if there's no response it's probably okay for us to work
> on it there).
>
> cheers,
>
> - Leo
>
>
>
> --
> To unsubscribe, e-mail:
> <mailto:commons-dev-> unsubscribe@jakarta.apache.org>
> For
> additional commands,
> e-mail: <ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: custom metatdata attributes
Posted by Leo Simons <le...@apache.org>.
Jakob Praher wrote:
> hi all,
>
> as we (Leo and I) have talked about custom metadata attribute support
> for java lately, I wanted to know whether this should be done inside
> avalon, or should be delegated to another (jakarta) project.
according to KISS, it should be a standalone library. There's lots of
locations where something like that can be done. Sice Jakarta Commons
already has some stuff regarding this in their sandbox I figured we'd
start there.
> if inside avalon, I was wondering what approach towards implementing
> them should be taken. (class augmentation, manifest files, ...)
I'm leaning towards parsing of
/** @attribute SomeClassNameAttribute("blaat") */
class MyClass
where an ant+qdox solution is run over this at build time. Such an
AttributeParserTask could generate lots of stuff. The most important
thing to agree on the syntax of the source files; you can always plug in
lots of different generators.
I would probably be most comfortable with this ending up in an xml file
coupled to the class, ie something like:
MyClass.attributes
------------------
<attributes>
<attribute
class="SomeClassName"
target="class">
<constructor>
<string value="blaat"/>
</constructor>
</attribute>
</attributes>
or maybe adopt the SOAP serializers from Axis for generation of
everything inside <attribute/>. Something like that. (I believe .Net
uses SOAP for serialization by default.) That's mostly because it is
consistent with the approach avalon currently takes.
> I am curious about your opinons,
me too :D I am actually waiting for a reply from some of the people
who've done a lot of the meta/attribute stuff currently in place @
avalon, in particular Peter Donald (hi pete!). I suspect he's still
catching up wrt e-mail...holidays y'know.
> and I am interested in helping with the
> implementation.
That'd be neat! If you feel like getting started, the easiest thing to
do is to probably check out jakarta-commons-sandbox, take the attribute
code in there and run with it, then send patches to the commons list.
I'm still orienting myself (still need to take a look at qdox/xdoclet
first).
The alternative is to try and drag requirements out of a broad group of
people (I suspect potential interest is big :), but I'm guessing that's
going to be difficult given the rather 'distributed' nature of that group.
We'll go with the flow from there (I haven't been particularly active in
commons before, but I believe I have commit rights to commons sandbox,
so if there's no response it's probably okay for us to work on it there).
cheers,
- Leo
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: custom metatdata attributes
Posted by Leo Simons <le...@apache.org>.
Jakob Praher wrote:
> hi all,
>
> as we (Leo and I) have talked about custom metadata attribute support
> for java lately, I wanted to know whether this should be done inside
> avalon, or should be delegated to another (jakarta) project.
according to KISS, it should be a standalone library. There's lots of
locations where something like that can be done. Sice Jakarta Commons
already has some stuff regarding this in their sandbox I figured we'd
start there.
> if inside avalon, I was wondering what approach towards implementing
> them should be taken. (class augmentation, manifest files, ...)
I'm leaning towards parsing of
/** @attribute SomeClassNameAttribute("blaat") */
class MyClass
where an ant+qdox solution is run over this at build time. Such an
AttributeParserTask could generate lots of stuff. The most important
thing to agree on the syntax of the source files; you can always plug in
lots of different generators.
I would probably be most comfortable with this ending up in an xml file
coupled to the class, ie something like:
MyClass.attributes
------------------
<attributes>
<attribute
class="SomeClassName"
target="class">
<constructor>
<string value="blaat"/>
</constructor>
</attribute>
</attributes>
or maybe adopt the SOAP serializers from Axis for generation of
everything inside <attribute/>. Something like that. (I believe .Net
uses SOAP for serialization by default.) That's mostly because it is
consistent with the approach avalon currently takes.
> I am curious about your opinons,
me too :D I am actually waiting for a reply from some of the people
who've done a lot of the meta/attribute stuff currently in place @
avalon, in particular Peter Donald (hi pete!). I suspect he's still
catching up wrt e-mail...holidays y'know.
> and I am interested in helping with the
> implementation.
That'd be neat! If you feel like getting started, the easiest thing to
do is to probably check out jakarta-commons-sandbox, take the attribute
code in there and run with it, then send patches to the commons list.
I'm still orienting myself (still need to take a look at qdox/xdoclet
first).
The alternative is to try and drag requirements out of a broad group of
people (I suspect potential interest is big :), but I'm guessing that's
going to be difficult given the rather 'distributed' nature of that group.
We'll go with the flow from there (I haven't been particularly active in
commons before, but I believe I have commit rights to commons sandbox,
so if there's no response it's probably okay for us to work on it there).
cheers,
- Leo
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: custom metatdata attributes
Posted by Peter Donald <pe...@realityforge.org>.
oh and there is also a facade being developed in commons-attributes that I
believe the qdox/xdoclet peeps were working on. But I think it lost its
luster as it started to loose simplicity and added deps so not sure if it
still is alive ;)
On Wed, 8 Jan 2003 16:18, Peter Donald wrote:
> Hi,
>
> On Wed, 8 Jan 2003 03:09, Jakob Praher wrote:
> > as we (Leo and I) have talked about custom metadata attribute support
> > for java lately, I wanted to know whether this should be done inside
> > avalon, or should be delegated to another (jakarta) project.
>
> Depends on where you want to do it ;)
>
> However if I was you I would wait till the end of January before you start
> on it. Rickard Oberg is planning to release his version of runtime
> attributes + aspects sometime mid-january. Hes one of the initial
> contributors to XDoclet IIRC and thus it is possible that it will become a
> defacto-standard overnight. Then again it may not ... and the release has
> yet to be done ;)
>
> I believe the XDoclet people were also creating XRAI product that did the
> same thing for XDoclet2 - not sure on it's status.
>
> > if inside avalon, I was wondering what approach towards implementing
> > them should be taken. (class augmentation, manifest files, ...)
>
> There is a few ways of doing it. The best/easiest I have found so far is a
> binary file that sits next to .class file and contains the attributes. So
> if you have a
>
> com/biz/Foo.class
>
> you end up with a
>
> com/biz/Foo.meta or com/biz/Foo.atr or com/biz/Foo.tags or whatever
>
> > I am curious about your opinons, and I am interested in helping with the
> > implementation.
>
> If you can hold off then I would recomend you do that. However if you want
> to have a bash at it imediately then there was previously a project called
> metaclass in jakarta-avalon-excalibur. However it ended up moving out and
> is still undergoing devellopment. If you are interested in that contact me
> and I will send you the details.
--
Cheers,
Peter Donald
------------------------------------------------
"No. Try not. Do. Or do not. There is no try."
-- Yoda
------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: custom metatdata attributes
Posted by Peter Donald <pe...@realityforge.org>.
Hi,
On Wed, 8 Jan 2003 03:09, Jakob Praher wrote:
> as we (Leo and I) have talked about custom metadata attribute support
> for java lately, I wanted to know whether this should be done inside
> avalon, or should be delegated to another (jakarta) project.
Depends on where you want to do it ;)
However if I was you I would wait till the end of January before you start on
it. Rickard Oberg is planning to release his version of runtime attributes +
aspects sometime mid-january. Hes one of the initial contributors to XDoclet
IIRC and thus it is possible that it will become a defacto-standard
overnight. Then again it may not ... and the release has yet to be done ;)
I believe the XDoclet people were also creating XRAI product that did the same
thing for XDoclet2 - not sure on it's status.
> if inside avalon, I was wondering what approach towards implementing
> them should be taken. (class augmentation, manifest files, ...)
There is a few ways of doing it. The best/easiest I have found so far is a
binary file that sits next to .class file and contains the attributes. So if
you have a
com/biz/Foo.class
you end up with a
com/biz/Foo.meta or com/biz/Foo.atr or com/biz/Foo.tags or whatever
> I am curious about your opinons, and I am interested in helping with the
> implementation.
If you can hold off then I would recomend you do that. However if you want to
have a bash at it imediately then there was previously a project called
metaclass in jakarta-avalon-excalibur. However it ended up moving out and is
still undergoing devellopment. If you are interested in that contact me and I
will send you the details.
--
Cheers,
Peter Donald
--------------------------------------------------
The fact that nobody understands you doesn't
mean you're an artist.
--------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>