SGen has caused
quite a stir, so I thought a few clarifications were in order.
JAM
There is quite a bit of interest about JAM, and rightfully so, so I’ll start
with this.
JAM is shipped with
XMLBeans, so it’s an Apache product. I didn’t include it in SGen (although
I did include the JAM javadocs), but if you want the whole JAM distribution,
just download XMLBeans. What you won’t find in that distribution is the JSR 175
code, though, which I just recently wrote. I will ship this as part of SGen for
now, though, but eventually, it will make it in XMLBeans as well.
The only reason why the SGen distribution is a bit messy right now is that I
need to figure out a way to package it with two different jar files (1.4 and
1.5), and I just haven’t had the time to do that so far. Please bear with me.
SGen
Over the past months, I have received increasing requests to make EJBGen
extensible. Since EJBGen is not open source, the only way I could do this was
provide an extension API in the same spirit as Eclipse or COM. As I started
factoring this code out of EJBGen, it occurred to me that the framework was
actually turning into something fairly generic. EJBGen was already using JAM
back then and it became quite obvious that SGen could become not only a
generator framework, but that it would be annotation-neutral on top of that.
From this point on, the other ideas fell in place very naturally. The
concept of separate jars for modules became central to the design of SGen.
Ideally, I want people to download a minimal SGen runtime and then
shop around for various jar files (in source form or not) for the various
modules they need. This way, they create their own generator "a la carte" and
one single invocation of the generic SGenRunner is all that’s needed in their build to generate all the
files they need.
XDoclet
Here is my perception of the XDoclet landscape right now. Please note that
as opposed to the other sections, what follows is admittedly very subjective and
I have no doubts that a lot of people will disagree with me.
There is an impressive number of XDoclet plug-ins used in production, and I
think it’s fair to say that 99% of them are based on XDoclet 1 (since XDoclet 2
is not even alpha, as far as I know). Of course, anybody who has written a
module for XDoclet 1 is very interested in porting their code to XDoclet 2,
which offers a very compelling Velocity-based template model, as opposed to the
version 1 and its XML language.
XDoclet 2 has been brewing for quite a while, now, but hasn’t seen much activity
in the CVS depot or the mailing-lists. This standstill has had a disastrous
effect on the landscape: module authors are hesitant starting working on a
pre-alpha version while reluctant to add more code in their v1 plug-in
which is going to be obsoleted
#1 by Anonymous on March 4, 2004 - 10:10 am
^Hibernate-based^Velocity-based
#2 by Andrew Stevens on March 4, 2004 - 12:20 pm
>I received an interesting comment mentioning two features of XDoclet 2 :
#3 by Hani Suleiman on March 4, 2004 - 1:48 pm
Andrew, no offence (especially since you’re the only xdoclet1 guy with any sense of responsibility remaining!) but you’re just….wrong.
The wiki does indeed mention a 16k jar. It doesn’t mention that it needs qdox, generama (which in turn needs pico, which in turn needs…etc etc). it’s lightweight only because for some reason pico guys like to call anything and everything to do with pico ‘lightweight’. Sure, it’s very cleverly designed, but it’s a victim of its own cleverness. The same mentality that produced a horrifically complicated i18n subsystem in xdoclet1 to show build time messages in brazilian portugese is now ensuring that xdoclet2 can ‘read in database metada obtained via jdbc and generally entity ejbs’. As great it is that xdoclet2 is so brilliant designed to do this….isn’t this need already fulfilled fairly comprehensively by middlegen?
#4 by Jon Tirsen on March 4, 2004 - 2:35 pm
Hani, you are right that xdoclet 2 depends on qdox (if you use javadoc-tags) and generama which in turn depends on pico. But pico have been carefully designed to depend on nothing else but jdk 1.3.
Is xdoclet 2 lightweight? Depends on definition but I’d say no, it does have three dependencies. Generama would be the lightweight one with only one (tiny) dependency. Does xdoclet 2 need to be lightweight? Probably not, as long as it works and does it job.
That’s what it comes down to in the end, right, Hani? 😉
#5 by Jon Tirsen on March 4, 2004 - 2:36 pm
Btw, Hani, will we *ever* see a Pico-bile? 😉
#6 by Hani Suleiman on March 4, 2004 - 4:48 pm
Jon, I’ll do a pico bile whenever I actually have time to look at it in detail!
#7 by Slava Imeshev on March 10, 2004 - 3:36 pm
Cedric,
As for XDoclet – with all my respect, measuring quality of a product based on mailing list activity is mmm… not very smart of you. You said yourself that it’s used 99% in production environment – what do you need else? It took me twenty minutes to get XDoclet stuff working, compared to EJBGen which I spent a half of a day on and finally gave up to make its ant task working. To my disappointment, EJBGen usability was poor. If I had not wanted 8.1 tags madly, I would have dropped EJBGen at instant. Very sad. Be careful making anyhing’s killer of it.
#8 by popupblocker on June 25, 2004 - 12:14 am
Just reading up on some of this lately, was interesting.
#9 by Tracy on August 8, 2004 - 3:48 pm
Was browsing through blogspot when I stumbled here