March 04, 2004

SGen clarifications

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 “very soon”.  My impression is that development of XDoclet modules has slowed down quite a bit because of this.

This realization and the fact that the SGen framework was reaching a decent shape led me to the thought that either SGen would pick up where XDoclet left, or that it would create an electroshock in the XDoclet 2 community, thus reviving it.

Either way, it seemed like a good thing.

SGen and XDoclet

The comparison between SGen and XDoclet is inevitable, and it’s quite justified since SGen is in some way trying to pick up where XDoclet left off.

First of all, I’d like to emphasize that SGen is such a lightweight framework that it could actually be used as a foundation for XDoclet.  All SGen does (besides the JAM part) is to define a formal SPI that modules need to respect when they contribute generators and configuration parameters.  That’s all.

SGen only has one plug-in right now, but it’s a sizable one (EJBGen) and I believe it’s complex enough to serve as a proof of concept.  I don’t think it’s fair to judge the potential of SGen on the number of modules it supports today, since SGen is hardly an alpha release right now. Besides, I don't recall XDoclet 1 or Hibernate getting immediate traction on the day they were announced :-)

I received an interesting comment mentioning two features of XDoclet 2 : “pluggable input source” and “pluggable metadata processor”.

First of all, these ideas look interesting, but I couldn’t find any documentation about them.  Call me picky, but mapping a CVS depot and reading code to understand concepts is not my idea of fun, so if somebody has a URL or a white paper to give me, I would love to take a look.

Nevertheless, the comment is justified.  That’s what SGen and JAM offer, except that we don’t make it possible to plug a metadata processor, we give you one (well, two:  a Javadoc and a JSR 175 processor).  I am not quite sure that a “pluggable input source” is, though, but it sounds cool, so we’ll provide it too :-)

Finally, Merrick made some very interesting comments about JAM, which I will address in a separate post.  I can already give you a hint, though:  I was having this very discussion with the author of JAM just yesterday, so stay tuned, there is more to come in this area as well.

 Present and Future

The SGen release is a bit messy right now.  The source is included, but mostly to satisfy users’ curiosity.  I really don’t think there is much value in the implementation itself, so I am surprised to hear that some people actually tried to build it.  But fair enough, I’ll make that possible.  In the meantime, please focus on sgen.jar and the examples.

My goal by releasing SGen at this early stage is to get the API “out there”.  EJBGen has proved that SGen is already useful in its current form, but I’d like to hear from developers who wrote generators recently -- either XDoclet or others --  to take a look at this API and let me know if it would fit their need.

 

 

Posted by cedric at March 4, 2004 08:12 AM
Comments

^Hibernate-based^Velocity-based

Posted by: at March 4, 2004 10:10 AM

>I received an interesting comment mentioning two features of XDoclet 2 : “pluggable input source”
>and “pluggable metadata processor”.
>
>First of all, these ideas look interesting, but I couldn’t find any documentation about them. Call
>me picky, but mapping a CVS depot and reading code to understand concepts is not my idea of fun,
> so if somebody has a URL or a white paper to give me, I would love to take a look.

http://xdoclet.sourceforge.net/wiki/wakka.php?wakka=XDoclet2Architecture

>Nevertheless, the comment is justified. That’s what SGen and JAM offer, except that we don’t make
> it possible to plug a metadata processor, we give you one (well, two: a Javadoc and a JSR 175
>processor). I am not quite sure that a “pluggable input source” is, though, but it sounds
> cool, so we’ll provide it too :-)

Actually, you've already got one. JAM is your input source, not your metadata processor. The processor is your EJBGen module.

This is equivalent to what XDoclet 2 does; that adds a QDox metadata provider (input source) to Generama (generic "glue" framework) and gives an interface for plugin modules which do the generation based on that metadata.

From what you've said so far, it sounds like the main difference is that you couldn't, for example, write a SGen module which read in database metadata obtained via JDBC and generated Entity EJBs for each table. With the framework used by XDoclet 2, you could; it wouldn't necessarily be an "XDoclet module" per se, just another application based on the framework. I don't know what state Aslak's Middlegen is currently in, but that was certainly where he was planning to go with it.

>First of all, I’d like to emphasize that SGen is such a lightweight framework that it could
>actually be used as a foundation for XDoclet.

Conversely, Generama/XDoclet2 is such a lightweight framework (the wiki page above mentions a 16k jar, though that may have changed since then) that it could actually be used as a foundation for SGen :-) Just create a JAMMetadataProvider and write some plugins...

Posted by: Andrew Stevens at March 4, 2004 12:20 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?

Posted by: Hani Suleiman at March 4, 2004 01:48 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? ;-)

Posted by: Jon Tirsen at March 4, 2004 02:35 PM

Btw, Hani, will we *ever* see a Pico-bile? ;-)

Posted by: Jon Tirsen at March 4, 2004 02:36 PM

Jon, I'll do a pico bile whenever I actually have time to look at it in detail!

Posted by: Hani Suleiman at March 4, 2004 04:48 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.

Posted by: Slava Imeshev at March 10, 2004 03:36 PM

Just reading up on some of this lately, was interesting.

Posted by: popupblocker at June 25, 2004 12:14 AM

Was browsing through blogspot when I stumbled here

Posted by: Tracy at August 8, 2004 03:48 PM
Post a comment






Remember personal info?