has caused

quite a stir
, so I thought a few clarifications were in order.


There is quite a bit of interest about JAM, and rightfully so, so I’ll start
with this.

JAM is shipped with

, 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.


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. 


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