Re: [PROPOSAL] lifecycle release

Peter Donald wrote:
> On Fri, 14 Mar 2003 22:52, Stefano Mazzocchi wrote:
> 
>>Peter Donald wrote:
>>
>>>The last six months I have been developing a container that extracts all
>>>metadata from attributes/javadoc tags (similar to commons-attributes,
>>>dot.net attributes or the various interceptor frameworks). So it would
>>>end up being specified by something like
>>>
>>>/**
>>> * @fortress.lifecycle name="ThreadSafe"
>>> */
>>>public class MyComponent {}
>>
>>Sounds cool.
>>
>>What about specifying a different comment namespace rather than the
>>javadoc one and use an xml syntax instead of the
>>soon-to-be-too-simple-for-the-purpose javadoc one?
> 
> 
> The main call against that is that it is not what everyone else uses or 
> supports. 

Are you getting shy at forking projects for elegance's sake, I can't 
believe it :)

> XDoclet (xdoclet.sf.net) is fairly pervasive through most enterprise 
> developers and if they had ever managed to get stable would have dominated 
> the whole landscape.  They didn't and a whole crop of other toolkits cropped 
> up such as qdox.sf.net (which we already use) or vdoclet, or ejbdoclet etc

It doesn't surprise me at all.

> People have already developed parsers, validators, editors and heaps of other 
> tools to work with these formats which is not something we can even get close 
> to getting as comprehensive support for a custom format.

Oh, please, that's not an argument. I'm talking about XML inside some 
special comment tags. I can write a parser for that in half an hour and 
tools, well, tools emerge after technology is used, only microsoft does 
the other way around.

> Add in the fact that JSR175 will probably use javadoc based metadata and I 
> don't think there is support for a custom format. 

This is a totally different argument. Can you outline here how the 
metadata concept is going to work for JSR 175? would that require a JVM 
change?

> Though it would make documentation of all that easier :)

And not only that.

> However I have never come across a case where the metadata was incapable of 
> representing what I wanted

This is another good argument.

> it may be clumsy at times but still useful. 
> Check out MSDN docs on dot.net attributes or the xdoclet website. 

I will.