commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jon Tirsén <jon_tir...@yahoo.com>
Subject RE: custom metatdata attributes
Date Tue, 07 Jan 2003 18:18:19 GMT
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: <mailto:commons-dev-help@jakarta.apache.org>
> 


--
To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>


Mime
View raw message