I had a brief look at the xmlfacade/castor/zeus idea, and I'm going to play the devil's advocate here...
Something inside of me screams out that if you're ending up with 1mb of code just to spit out an ejb-jar.xml, then something is horribly wrong. Especially when you consider the myriad of modules that are available. xdoclet could well end up being 10mb if you want to generate your web.xml, ejbs, and a couple of vendor specific descriptors. Not good!
I think one of the drawbacks (from a part time contributor perspective) of xdoclet as it stands is the huge amount of automation that it tries to do. This principle seems to be carried forward to xdoclet2, with reliance on castor and its ilk. I don't have any answers as to the optimal route, but I think defining what xdoclet does and how it does it is important for future versions. To me, xdoclet can be boiled down to a few simple principles:
- meta information is specified in javadoc tags
- javadoc tags are parsed by a source parser
- templates are able to query javadocs and emit code
- Classes can be plugged in to provide extra functionality for templates
So in terms of end result, something that achieves the 4 goals above with ease and a very low barrier to entry is to be what an ideal xdoclet would look like. The first 2 points are already handled wonderfully by xjavadoc. The nice thing about xjavadoc is that it doesn't require that users know about it. Nobody would need to customise its behaviour or delve into its guts. Thus, due to its modularity and pluggability, it can get away with being ugly, hacky, and very hard to grok.
The same does not apply to the templates and classes. The reason for this is that end users will always find bugs and problems for a specific module, and due to the very nature of the tool, are very likely to delve in and try and figure out what's going wrong and how they can fix it.
The problem with the current system is that it's very awkward. The template language is very verbose and limited, if you get anything wrong you end up with 10 page long stacktraces. Not very friendly.
So what I'm wondering is, why not reuse some other library for the templates that addresses these issues? Something like freemarker or velocity? To me xdoclet2 would be a success if it is a simpler more maintainable version of xdoclet1.2, not something 5 times the size, slower, and with even more complicated automation!
Also (yes, I know I don't get a vote!) but -1 to the idea of automatically downloaded modules. Again an increase in complexity/neatness, but I don't think it really provides a strong end user benefit. I for one will be rather annoyed if when I run ant, suddenly stuff is being downloaded. Not to mention the host of people behind firewalls/proxies, or on planes, etc etc. Less magic, more straightforwardness! xdoclet is already a great success, don't detract from that by limiting your audience to just those who want to live (and get cut) on the cutting edge!
Sorry for the long email, but I hope that at least some of it makes some sort of sense to the dev guys ;)
On Wednesday, January 29, 2003, at 09:48 PM, Aslak Hellesoy wrote:
I totally agree with you on that one. XDoclet is a hairball inside (althoughIMHO (as an end user, and occasional contributor to templates and casual code browser) the xdoclet code seems to be horribly complicated and inelegant. Of course, I could be completely wrong (I hope I am, in fact), but it seems that as things progress, the code gets even more obscure, and the barrier to entry becomes harder and harder.
it works pretty well). (I know of a few other successful projects that are
hairballs too). Learning, maintaining and building XDoclet has become a
(too) difficult task, and that's why we have started a rewrite of XDoclet:
XDoclet2. It will have a more maintainable build system (Maven) (I refuse to
discuss Maven with you Hani :-)), more JUnit tests, better design,
blablabla.
If you (or anybody else!) would take the time to look at the current
XDoclet2 sources, we'd be extremely grateful to get some feedback about the
new proposed architecture.
I recommend you have a look at the xdoclet2/core part:
http://cvs.xdoclet.sourceforge.net/cgi-bin/viewcvs.cgi/xdoclet/ xdoclet2/core
/
The javadocs aren't too bad. You should be able to grasp the idea (even
though English is your and my 2nd language).
More info is here:
http://www.mail-archive.com/xdoclet-devel%40lists.sourceforge.net/ msg10208.h
tml
(this is really where comments are needed)
Aslak
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
_______________________________________________
xdoclet-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/xdoclet-user
------------------------------------------------------- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com _______________________________________________ xdoclet-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xdoclet-user
