commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Adam Murdoch" <adammurd...@apache.org>
Subject RE: [clazz] Doclet for metadata? (was: Type-based or instance-based metadata?)
Date Sun, 27 Oct 2002 00:31:53 GMT

Doclets wouldn't be the implementation per se.  Doclets are really just a
convenience for generating whatever needs to end up in the jar (or classpath
or whatever), whether that's a BeanInfo class, or an XML descriptor, or
whatever.  That same info could also be added manually to the jar without
needing to use the doclet or having access to the source.

You could have a single implementation, that has a doclet frontend, or
multiple implementations, each with their own doclet frontend.  Or no
doclet, or multiple frontends.  You get the idea.

Regardless, +1 for pluggable implementations.

> -----Original Message-----
> From: Dmitri Plotnikov [mailto:dmitri@apache.org]
> Sent: Sunday, 27 October 2002 7:55 AM
> To: Jakarta Commons Developers List
> Subject: Re: [clazz] Doclet for metadata? (was: Type-based or
> instance-based metadata?)
>
>
> I appreciate the power of attributes and I think we should consider
> supporting them very seriously.  But before we do that, we need to figure
> out the hourse-cart relationship between [clazz] and doclet-based
> metadata.
>
> Will doclets be *the* design for [clazz] or *a* pluggable implementation?
>
> If we choose to commit [clazz] to the doclet approach,
>
> 1. We have to have source code processing as a mandated part of the build
> process.
> 2. We cannot add or modify metadata for pre-existing or code-generated
> classes.
> 3. We still haven't answered the requirements for DynaBeans, Maps where
> there is no source code to augment with doclets.
>
> IMO, we should allow a doclet-based plug-in, but it should be a
> specialization of a more generic mechanism.
>
> - Dmitri
>
>
> ----- Original Message -----
> From: "Berin Loritsch" <bloritsch@apache.org>
> To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
> Sent: Saturday, October 26, 2002 4:33 PM
> Subject: Re: [clazz] Type-based or instance-based metadata?
>
>
> > Dmitri Plotnikov wrote:
> > > Berin,
> > >
> > > ----- Original Message -----
> > > From: "Berin Loritsch" <bloritsch@apache.org>
> > > To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
> > > Sent: Friday, October 25, 2002 11:57 PM
> > > Subject: Re: [clazz] Type-based or instance-based metadata?
> > >
> > >
> > >
> > >>Dmitri Plotnikov wrote:
> > >>
> > >>>Another dilemma we'll have to resolve is whether metadata will be
> > >>>type-based, instance-based or both.
> > >>>
> >
> > <skip/>
> >
> > >>Most meta info that is useful is type based, not instance based.
> > >
> > > I guess my examples are not very convincing.  What I am
> trying to say is
> > > that type-based metadata is only as detailed as the type.
> For example,
> if
> > > you declare a property as "int" you have said quite a bit about the
> > > property, however if you declare it as "Object" you have said almost
> > > nothing.  Better yet, all DynaBeans are of the same type - DynaBean.
> > > Looking at the type says nothing at all.  Same with Map.
> > >
> > >
> > >>What you are looking at is instance based reflection info.  Not a more
> > >>generic meta info.
> > >
> > > First, we do want to have more metadata than mere reflection. We would
> like
> > > to capture information on how to store XML with Betwixt or
> JAXB, how to
> > > access objects with JXPath etc.
> > >
> > > Second,  we are looking to support a wider variety of object
> models than
> can
> > > be supported via Java reflection alone (DynaBeans, Maps etc)
> >
> > Then focus on an "extension" of the Class object (I know it is declared
> final,
> > so inheritance is out of the question), that has a set of "attributes".
> These
> > attributes mean different things to different people/contexts.  Also,
> don't think
> > of attributes as a simple name=value pair.  C# attributes have
> the concept
> of
> > parameters as well as the attribute itself.  For example:
> >
> > /**
> >   * @avalon:component
> >   * @avalon:role=org.apache.excalibur.DataSourceComponent
> >   * @avalon:creation-policy=singleton
> >   * @test:multi-value=value1,value2,value3
> >   */
> >
> > This would declare a class to have the "avalon:component" attribute, the
> > "avalon:role" attribute with the value set to
> "org.apache.excalibur.DataSourceComponent",
> > etc.
> >
> > These attributes can be read from the IClass (BTW, I hate prefixed
> interfaces/etc.--
> > interfaces should be your primary type, so if we have any
> idioms put it on
> the
> > implementing class).  Attributes that are method specific would
> be put in
> the
> > javadoc for your method.  In your case you want to know the
> type info for
> a DynaBean
> > return value:
> >
> > /**
> >   * @dynabean:return=java.util.Date
> >   */
> > Object getDate();
> >
> > You would want the "dynabean:return" attribute for the "getDate()"
> IMethod, or whatever
> > you call it.
> >
> > The Attribute approach is very simple, and is easy to use.  Its meaning
> only gives
> > purpose based on the context.  The "test:multi-value" attribute in the
> first example
> > would be used in a testing framework so that you can apply the same unit
> test for a
> > suite of methods/classes--and they don't even have to set up the same
> interface (the
> > Delegate stuff can take care of it).  In fact using attributes
> is a great
> way to
> > *generate* JUnit tests automagically!
> >
> >
> >
> > >>Meta info that is useful to me is things like this:
> > >>
> > >>* Creation policy (pooled components, thread local
> components, singleton
> > >>    components, etc.)
> > >
> > > Agreed.
> > >
> > >
> > >>* Required components (i.e. when one component requires a component of
> > >>    another type)
> > >
> > > Could you provide more details on this one?
> >
> > In Avalon components can require other components to function.
> An example
> > would be the DatabaseReader from Cocoon.  It reads information from a
> database,
> > but uses the org.apache.avalon.excalibur.DataSourceComponent to get the
> connection
> > from a pool.  By declaring this dependency up front, the attributes for
> the class
> > would enable a container to ensure that an implementation of
> the required
> component
> > existed.  If it did not, the container can post a failure notice
> immediately that
> > makes sense.
> >
> >
> > --
> >
> > "They that give up essential liberty to obtain a little temporary safety
> >   deserve neither liberty nor safety."
> >                  - Benjamin Franklin
> >
> >
> > --
> > 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>


--
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