For follow-ups, please reply to [EMAIL PROTECTED] > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Hani > Suleiman > Sent: 4. februar 2003 07:46 > To: [EMAIL PROTECTED] > Subject: Re: Localisation (was RE: [xdoclet-user] Problem with Ant > Integration) > > > Hmmmm. > > 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.
I totally understand your sceptisism, and I'll try to describe what you'll get for the size-price. Keep in mind that I'm only suggesting this approach for generation of huge and complex XMLs. XDoclet2's core is small and neat, and nobody stops you from writing your plugins with Velocity (or something else). Here are the benefits with xmlfacade: 1) Ultra-easy plugin development. With the current xmlfacade mini-framework (it's a separate XDoclet plugin used only for plugin development), plugin developers (that's the XDoclet team + all the thousands of users) only need to drop in the dtd(s) and/or xsd(s), and Maven + XDoclet will build all the scaffolding code that can generate compliant XML. The developer only needs to code the "glue" that copies data from the sources (using the xjavadoc API) and "stuff" it into the XML via the (castor/zeus/xmlfacade)-generated API. Everyting is done in java, and there are no templates. If we were to use Velocity instead, we'd quickly end up with huge templates (as today) that are hard to maintain. One of the main drawbacks with the template approach is that you don't get any compile-time checking. The xmlfacade approach gives you compile-time checking. 2) Everything in the DTDs/XSDs is covered. Not covering all dark corners of various DTDs has been one of the biggest hurdles in XDoclet 1.x so far. Most of XDoclet 1.x's templates are only "nearly" complete. The templates are hard to read. Having the templates as Velocity would help a bit (more mainstream, nicer syntax), but for big DTDs/XSDs and several versions it quickly becomes a real maintenance nightmare. The castor/zeus/xmlfacade approach reduces these maintenance headaches (at the cost of size). > 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! > Not good, but not so bad either I think. It's something you download once. > 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 XDoclet2 will indeed look that way. The core lets you use any generation mechanism you want. Velocity, Jelly, Castor, Zeus, Freemarker or even JSP if someone is crazy enough to write a JSPGenerator. > 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 XDoclet2 has already got Velocity support. > 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 We'd make sure to give the user full control over when/what is downloaded if we were to add it. I didn't mean we should have the download mechanism as part of the core, but rather as part of the installation process. > 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 ;) > Very good remarks. Before I end, I'd just like to point out once and for all that the XDoclet2 core is very simple. You can use Velocity to build very simple plugins. -And if you're facing a big beast of an XML described by several versions of DTD and XSD, you'll have a special plugin that can help you build big parts of it. If you do that, you'll end up with a big plugin that's easy to code. -But you can always code the whole thing by hand and get something smaller. -But it will be a lot harder. Aslak > On Wednesday, January 29, 2003, at 09:48 PM, Aslak Hellesoy wrote: > > >> IMHO (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. > >> > > > > I totally agree with you on that one. XDoclet is a hairball inside > > (although > > 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 ------------------------------------------------------- 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
