Patch for Metadata work

Hi Brian.

I applied your cleanup for JavaClassCache, thanks.

The remainder of your patch modifies DefaultDocletTagFactory to support registration of tag implementation classes. Sorry to say, but I can't see why this needs to be part of QDox.

If you need to do funky stuff with tag-handling, just register a custom implementation of the DocletTagFactory interface, which was introduced specifically for that purpose (by Aslak, for XDoclet2).

In the past, XDoclet2 provided it's own DocletTagFactory implementation, which I believe supported tag-validation, and registration of tag-handler classes. Is this no longer sufficient? If so, why?

cheers, Mike.

Hi Mike,

Thanks for getting started on this.

The DefaultDocletTagFactory stuff isn't in XDoclet any longer, what you are seeing in this patch is that code, refactored out of there. Aslak agreed long ago that this code ought to be in QDox, although I do not have logs or email to show for it any longer.

The basic issue is that clients that want a default implementation need to develop their own in every case. There's really no point in that. Moving this from XDoclet was something Aslak and I agreed was something that should have been done to begin with.

Had I any indication of how difficult this was going to be to work with you guys, I would have submitted this DefaultDocletTag refactoring a long time ago while it was fresh on his mind. I guess I learned a lesson.

Can you better articulate your objections to applying this patch and provide a case where QDox clients are disadvantaged by having this code available to them?

Thanks,

Brian

My objection to this patch is that it is not required to fulfill QDox's purpose, which (as I see it) is to parse Java source-code, build a model representing what it finds, and present that to the client program with a minimum of fuss.

Tag-registration is not a requirement, from that point of view.

There was discussion along these lines back in July '03, and the general consensus was that QDox should provide a simple, bare-bones model, and let client programs layer on their own abstractions as necessary.

http://lists.codehaus.org/pipermail/qdox-user/2003-July/000128.html
http://jira.codehaus.org/browse/QDOX-8
http://jira.codehaus.org/browse/QDOX-9
http://jira.codehaus.org/browse/QDOX-11

It is still very much my preference to keep the QDox model as simple as possible, and resist letting the paradigms of client programs "leak" into it (even when that client program is XDoclet).

Getting back to specifics, I do not understand why you've removed the tag-registration logic from XDoclet, and wish to push it into QDox. What was wrong about where it was? What are these "clients that want a default implementation" that includes tag-registration, and why can't they simply use the XDoclet one?

Mike, why don't you discuss this with Aslak. He appears to be the project lead here, and he already said that this should go in.