commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sandy McArthur" <sandy...@gmail.com>
Subject Re: Commons Metadata?
Date Wed, 08 Mar 2006 21:32:52 GMT
I don't see such a library being useful except to a very small audience.

I'd say keep the code with the project that is using it, solicit other
similar frameworks and see if they'd want to use the same code and
then once you've got a group of customers for the lib find a neutral
place to host it. Jakarata already has more code than people to
maintain that code and realistically it may not make sense for it to
live here.

On 3/8/06, James Carman <james@carmanconsulting.com> wrote:
> If I write it, I can have the Trails project use it probably (I'm a
> committer).  Do we just have to have clients who are interested in the
> project or do we also need more than one developer to work on it?
>
> -----Original Message-----
> From: mfncooper@gmail.com [mailto:mfncooper@gmail.com] On Behalf Of Martin
> Cooper
> Sent: Wednesday, March 08, 2006 12:42 PM
> To: Jakarta Commons Developers List
> Subject: Re: Commons Metadata?
>
> On 3/8/06, James Carman <james@carmanconsulting.com> wrote:
> >
> > So, what's the next step here?  Do I need more votes?  Do I need to have a
> > formal [PROPOSAL] prior to adding the starting the project in the sandbox?
>
>
> Technically, you don't need any votes. What you do need to consider, though,
> is whether or not there is, or will be, enough interest that you'll be able
> to form a community around the code. If that doesn't happen, then the
> component won't get out of the sandbox, and  therefore won't be able to
> release.
>
> So far, I see only one person expressing interest. If it were me, I don't
> think I'd proceed with code at this point. But then it's not me, it's you,
> so it's really your call. ;-)
>
> --
> Martin Cooper
>
>
> -----Original Message-----
> > From: James Carman [mailto:james@carmanconsulting.com]
> > Sent: Tuesday, March 07, 2006 1:02 PM
> > To: 'Jakarta Commons Developers List'
> > Subject: RE: Commons Metadata?
> >
> > Well, that's the thing.  That's up to the "decorator" to decide how it
> > gets
> > the metadata information.  Jakarta Commons Attributes does a
> > pre-compilation
> > step to set up the .class files so that their attributes can be read from
> > them (from what I can glean from the docs).
> >
> >
> > -----Original Message-----
> > From: Thomas Dudziak [mailto:tomdzk@gmail.com]
> > Sent: Tuesday, March 07, 2006 12:57 PM
> > To: Jakarta Commons Developers List
> > Subject: Re: Commons Metadata?
> >
> > On 3/7/06, James Carman <james@carmanconsulting.com> wrote:
> >
> > > I believe I brought this up before, but I really think there's a need
> > for
> > > this.  We need a metadata framework which abstracts away the details of
> > > exactly how the metadata is found/provided.  For example, some
> > applications
> > > use only JDK5 annotations to add metadata to their classes.  Others
> > might
> > > use Jakarta Commons Attributes.  Others might want to use XML files (if
> > they
> > > don't want to have to touch the source).  So, what we could provide is a
> > > MetadataFactory (or whatever you want to call it) which can have
> > "metadata
> > > decorators" added to it.  The decorators are added to a pipeline and are
> > > given a chance to append metadata information to the metadata
> > object.  We
> > > created something like this for the Trails (www.trailsframework.org)
> > project
> > > so that we could use "off-the-shelf" domain models (how many times have
> > you
> > > seen those at Best Buy?) within the framework by providing metadata via
> > XML
> > > files as opposed to using JDK5 annotations.  We could start this off in
> > the
> > > sandbox, of course.  Anyone interested in helping out?  I could start
> > off
> > > developing the core classes (the metatdata "holder" classes).
> >
> > +1
> >
> > That sounds useful, especially if it also can be used at compile time,
> > and if it can work with XDoclet-style Javadoc tags (e.g. using qdox or
> > similar).
> >
> > cheers,
> > Tom
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>


--
Sandy McArthur

"He who dares not offend cannot be honest."
- Thomas Paine

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


Mime
View raw message