On Sat, 15 Mar 2003 05:51, Stefano Mazzocchi wrote:
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 :)
Of course not :)
Damn, I thought you learned something during all these phases.
It is just way too massive an undertaking. XDoclet / qdox / vdoclet have already put many man years into development so I want to reuse their stuff.
But probably you did, you just don't want to admit it :)
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.
sure its is ... or to put it another way - Are you volunteering? :)
Don't get me wrong, I see your point, but I think that writing a parser/validator for that stuff is *really* piece of cake. As for editors and IDE support, they will follow what the market will follow, see Ant.
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?
The JSR has not been made public but from the grapevine heres the scoop. The metadata will be store in .class file as "class attributes". So it will not require a JVM change but the utility files to load the metadata will be in the next JVM. However that does not stop us developing our own loader that parses the the .class files using BCEL.
I see.
But once you have that metadata inside your class, how are you going to find out something about it? introspection or direct bytecode manipulation?
Those sounds much less elegant than any instanceof() calls. What am I missing?
However from what I understand that the metadata will be extracted from javadocs. A few different proposals have been made but I am not sure what they will pick. Some proposals IIRC are
@meta Fortress{lifecycle="ThreadSafe"} @fortress lifecycle="ThreadSafe" @meta org.apache.avalon.fortress.FortressMetaData("ThreadSafe")
Ok, makes sense.
do you think this is going to be enough for the metadata needs you foresee? just curious.
Stefano.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
