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:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Reply via email to