New generation framework announced: SGen

Discussions

News: New generation framework announced: SGen

  1. New generation framework announced: SGen (29 messages)

    Cedric has announced a new framework named SGen, which is "a framework that makes it easy to create tools that parse annotations and generate files". It uses JAM under the covers, which allows it to support both Javadoc style, and the new JSR 175 style annotations.

    SGen goals

    - Modules can be developed separately and shipped in individual jar files. All they need to do is contain at least one SGen module (which is achieved by implementing a certain interface). For example, you can download ejbgen.jar, drop it in your "modules" directory, point SGenRunner to it and voila, you have added a new generator to your arsenal.

    - SGen is annotation-neutral. It supports both Javadoc and JSR 175 style annotations. The way the annotations are collected is made transparent to your module through an open-source abstraction layer called JAM.

    - SGen doesn't mandate any template technology. You are free to use Velocity or println if that's what you want.

    - SGen is XML-free. That's right, baby, you won't have to write a single line of XML to use it.

    There is even mention of XDoclet:

    "Since the question is most likely going to come up, I don't see SGen as a direct competitor to XDoclet, although they achieve similar goals. The idea is that if you wrote an XDoclet module, you should be able to factor out all the "business logic" of your generators and make an SGen module out of it. Then your module can be downloaded by your users and mixed with the other SGen modules they use."

    Read Cedric in SGen: an XDoclet killer, and his updated clarifications.

    View the SGen home page

    Threaded Messages (29)

  2. I would say that goals of the project are very similar to the goals of XDoclet version 2: http://xdoclet.sourceforge.net/wiki/wakka.php?wakka=XDoclet2Architecture

    So, please provide reasons for not participating in the development of XDoclet V2.

    API: ISingleFileGenerator or IMutipleFileGenerator names are misleading.

    Since we can generate multiple files in IsingleFileGenerator and almost certainly will generate one file out of IMutipleFileGenerator.

    According to signatures and ideology I would suggest names like:
    IMultipleFileBasedGenerator and ISingleFileBasedGenerator
  3. Why not xdoclet2[ Go to top ]

    Gosh, where to start? Here are some reasons off the top of my head, some of none which might be relevant.

    1) xdoclet2 has been in development for over a year now with next to nothing approaching xdoclet's functionality available.

    2) The geniuses who gave us xdoclet1 never even bothered finishing it before moving on to the next cool thing

    3) It has a million dependencies. SGen is one jar.

    4) For those millions of dependencies, half are other half-baked ideas that are just as untested/proven as xdoclet2 itself

    5) It uses maven

    Now, given that after all this time xdoclet2 is STILL nowhere (read, without any useful plugins), a new solution that maybe is a little bit less smelly might actually have a chance.
  4. Why not xdoclet2[ Go to top ]

    Gosh, where to start?


    From telling us if there was a discussion with XDoclet authors about revitalizing of XDoclet2 development.

    >1)xdoclet2 has been in development for over a year now
    Share your frustration, because I dream of Velocity based templates. Than that pseudo-xml language is not very convenient.

    >>with next to nothing approaching xdoclet's functionality available.
    At least V1 works fine. Would you name SGen plugins please?

    >2) The geniuses who gave us xdoclet1 never even bothered finishing it before moving on to the next cool thing

    I would not call V1 unfinished. It has many ready to use modules and templates. I use it on daily basis and with modified and completely new templates. It certainly much more functional than SGen.
     
    >3) It has a million dependencies. SGen is one jar.
    I am sure that when/if SGen will do something real it will tons of dependencies too.

    >4) For those millions of dependencies, half are other half-baked ideas that are just as untested/proven as xdoclet2 itself
    I would not consider SGen to be proven and it is full of “half-backed” ideas too.
     

    >5)It uses maven
    For building project itself. Even I do not like Maven I would not consider it to be a valid reason to start a new project. Do not like Maven: just create ant script.
  5. Why not xdoclet2[ Go to top ]

    Gosh, where to start?

    >
    >From telling us if there was a discussion with XDoclet authors about revitalizing
    >of XDoclet2 development.

    Absolutely nothing on the xdoclet-devel mailing list...
  6. Why not xdoclet2[ Go to top ]

    Konstantin did a pretty good job of covering Hani's issues with XDoclet 2, but let me chime in with my thoughts...

    > 1) xdoclet2 has been in development for over a year now with next to nothing approaching xdoclet's functionality available.

    The core of XDoclet 2 is fairly stable and usable. The only frustrating thing I face on occasion is that some of the dependencies of XDoclet 2 (Generama, QDox, and many times PicoContainer) change their interfaces and the XDoclet 2 code gets out of sync. While annoying, this is rare. I don't know what Aslak's plans are, but from what I see, it looks like the CORE of XDoclet 2 is just about ready to be released as a beta release. As for the lack of plugins...there are many plugins for XDoclet 2, some mature, some not...but they're getting there. Tell me...what plugins does SGen come with?

    > 2) The geniuses who gave us xdoclet1 never even bothered finishing it before moving on to the next cool thing

    This is only a half-truth. Much of XDoclet 1.2 works like a champ. I regularly use it for generating artifacts for Hibernate, portlets, EJBs, web.xml, mockobjects and TLD files and have no problems. Some of the fringe and proprietary modules are less mature, but that's usually an indication that nobody is using them. Documentation-wise, XDoclet 1.2 is better than most open-source software, but I agree is not ideal.

    > 3) It has a million dependencies. SGen is one jar.

    See Konstantin's comment here.

    > 4) For those millions of dependencies, half are other half-baked ideas that are just as untested/proven as xdoclet2 itself

    Yep. One problem with XDoclet 1.2's structure is that the core and the modules are all one big project. Anytime somebody had a brain-fart one day and decided to write a module, it got stuck into the main project--whether the module made sense or not or whether it was really needed or not. XDoclet 2 takes a different approach by keeping the core as one project and the plugins as one or more projects. Ideally, vendors would be responsible for the plugins that drive their products (IBM would be responsible for the WebSphere plugin, for example). Realistically, that's probably not going to happen, so the XDoclet user community is invited to either start their own project for their plugin or, in the case of the basic plugins (servlets, EJBs, etc) contribute the plugin to a separate "XDoclet Plugins" project. This way, half-baked ideas end up separate from the core project.

    As for untested...that's simply not true with XDoclet 2. XDoclet 2 and all of the existing plugins come with a suite of unit-tests.

    > 5) It uses maven

    As Konstantin said, it uses Maven to build itself. It's very possible to use XDoclet 2 with Ant (although I find that it's actually easier to use with Maven).

    > Now, given that after all this time xdoclet2 is STILL nowhere (read, without any useful plugins), a new solution that maybe is a little bit less smelly might actually have a chance.

    "Nowhere" is not true. The EJB plugin only does the interfaces and deployment descriptor right now, but that's a good start. The web plugin does a fine job with web.xml (for servlets, filters, and listeners) and TLD files and is mostly complete as far as I can tell. The Hibernate module is usable for *most* Hibernate projects...the missing parts are fringe pieces not used in most projects. The portlet plugin is fully usable and functionally equivalent to it's 1.2 counterpart, sans merge points.

    The biggest problem with XDoclet 2 is that it's not available as a download. You have to build it yourself and that can be a pain for those who just want to use it. Hopefully it will be released as at least a beta in the near future.
  7. Why not xdoclet2[ Go to top ]

    Guys, thanks for the various comments. I will soon be posting a statement defining more precisely SGen's goals and my plans for the future, but give me some time, SGen is a project I try to squeeze in-between deliverables and my days only have 24 hours.

    I'll address one question very quickly, though: SGen only has one plug-in today (EJBGen, which I believe is a decent proof of concept) but I don't think it's a fair way to measure its usefulness. I don't think any initial release (XDoclet 1, Hibernate even) got any traction in their early days.

    Right now, my goal is just to put the API out there (ISGenModule, ISingleFileGenerator, etc...) and plant it in people's minds. If you have ever written a generator and/or contributed one to XDoclet, please think about this API and let me know if it would be sufficient for you.

    Stay tuned.

    --
    Cedric
  8. Have we really come that far, that one has to justify himself _not_ contributing to an open source project?

    Regards,
        Dirk
  9. Have we really come that far, that one has to justify himself _not_ contributing to an open source project?


    Yes.

    The long answer: 1. Since everybody uses open source projects in one way or another it is absolutely necessary to contribute.
    2. Not that I am against new projects and progress. I am against new projects, which do not do anything significantly different or better, because they deny spirit of collaboration and usage of previous experience.
    3. I believe that there might be valid reasons for not participating and starting fresh. But I like to know them to make a decision it the new project is better suitable for me. Let me repeat my documentation pattern proposal for authors: (http://www.kgionline.com/annoying/openSrc.jsp )

    1. I(we) had a need to do: <Two phrases to describe>
    2. I(we) have tried the following frameworks: <insert names> before starting to develop my own
    3. They are supposed to address my needs but I was not happy with them because: <reasons why those frameworks are not satisfactory>
    4. I(we) decided not to contribute to any of the existing open source frameworks because: <describe why>

    If those 4 items are not documented and explained by authors I try to do it myself and from this perspective I do not see much reasons to pay attention/contribute/etc. SGen, and feel sad that smart guys will waste valuable time on reinventing and reimplementing same things all over again.
  10. So by your own definition, XDoclet2 should never have been started. It shares nothing with the previous version, is completely incompatible (all plugins have to be rewritten) and throws away all of the testing that went into the previous plugin sets. Furthermore, there is little public documentation, no mailing lists, no plan, all save for a plugin project on SourceForge that may or may not compile on the day you try to download it. Hooray for collaboration.

    Given that Cedric is building on EJBGen, which already has a substantial base of WebLogic users, I'd say he's at least hit the gound running with this tool. Besides, a little competition never hurt anyone. Instead of whining in his blog about how it looks like XDoclet2, maybe people should be urging the XDoclet2 team to actually release something people can use.

    Merrick
  11. So by your own definition, XDoclet2 should never have been started.

    Do not see how I have defined that.
    Let me clarify:
    >> It shares nothing with the previous version, is completely incompatible (all plugins >>have to be rewritten) and throws away all of the testing that went into the previous
    >>plugin sets. Furthermore, there is little public documentation, no mailing lists, no plan,
    Thank you for contributing in the bullet #3 of my template.

    So, what I try to say: When I am busy enough working on some projects I simply do not have time to investigate every new project out there especially if it looks a lot like some another. And any desire to look at the project diminishes if I do use that another project daily with great pleasure.

    >>all save for a plugin project on SourceForge that may or may not compile on the day you try to download it.

    Annoying but normal for a project under development. I prefer to keep code in repository at least compillable.

    Have you tried to submit patches?
    Unwillingness authors to collaborate might be a pretty valid reason for not contributing. Or suggestion was less than perfect, or may not be compatible with general design of the project.



    >>Given that Cedric is building on EJBGen, which already has a substantial base of WebLogic users…
    That might be a key: WL specific stuff.

    >> maybe people should be urging the XDoclet2 team to actually release something people can use

    Might be. But I do have XDoclet V1 and use it for:
    - EJB session bean generation ( customized templates );
    - Hibernate 2 mapping files generation ( customized templates);
    - Struts config file generation;

    So I personally do not have urgent need for XDoclet2 or SGen.

    From another post:
    >> I'll be giving EJBGen a try for one simple reason. xdoclet blows! The docs are horrible

    Doc is not bad IMO and it never hurts to look into actual templates.
    In very rare occasions I had to look at XDoclet source for more details.

    >> The docs are horrible, especially for m:n relationships, AND it DID NOT generate my jbosscmp-jdbc.xml m:n descriptors correctly.

    This is very true. Probably not many people use EntityBeans CMP it is up to them to contribute and fix it. Again: do not see how it justifies whole new project.

    >>>>Hooray for collaboration.
    Hooraah!

    Taking longer life of XDoclet and its broader scope I have more confidence in its authors mainly because they have real experience in dealing all that mess. So I am more inclined to look at XDoclet 2.

    Again: I might be plain wrong, I just looking for reasons to reconsider my preconceptions.
    Please provide them. As many as possible.
  12. Open source projects attract users and committers based on what problem they are attacking, how good a solution, and how well the project is run.

    I for one, LOVE XDoclet-1.2. It is more complicated than necessary to write a plugin, but once you are done, it save a lot of time. Unfortunately, never in the dozen or so times over the past 4 months, have I been able to build the xdoclet-plugins/XDoclet2. I have dabbled in Maven, but do not know it well enough to try and fix it, and personally it is a major turn off to have a software package not build. I can accept not passing a few unit tests, but broken builds are unacceptable. And I know it is mostly due to using the SNAPSHOT Maven functionality, but I do not care. It still does not build. The XDoclet2 project is using up any carry-over momentum it might have had in using the same project name by not providing a release or a build-able codebase.

    Merrick makes good points. XDoclet2 is different regardless of name and Merrick has already added Ant and Velocity support to sgen. That is why I am exploring and writing templates in sgen. It is going to help me get my project done faster.
  13. Ugh![ Go to top ]

    Well, I beg to disagree.

    > The long answer: 1. Since everybody uses open source projects in one
    > way or another it is absolutely necessary to contribute.

    Why would that be? Software is written by developers to understand and develop certain concepts. Merely contributing would not do. Also, some very prominent open source projects and standard defintion boards that I (less happily) use will never see me contributing for a very simple reason: I don't like the concept. My prime example is Struts that is nice but uses a fundamentally flawed concept of the model 2 "architecture". Or I have a feeling, I don't like the people (or have a feeling I would not), so I would probably not contribute at JBoss.

    > 2. Not that I am against new projects and progress. I am against new
    > projects, which do not do anything significantly different or better,
    > because they deny spirit of collaboration and usage of previous experience.

    I am all for competition. If there had been two official servlet container reference implementations, the crap that was tomcat 3.2 would never have happened.

    >
    > 1. I(we) had a need to do: <Two phrases to describe>
    > 2. I(we) have tried the following frameworks: <insert names> before starting > to develop my own
    > 3. They are supposed to address my needs but I was not happy with them
    > because: <reasons why those frameworks are not satisfactory>
    > 4. I(we) decided not to contribute to any of the existing open source
    > frameworks because: <describe why>

    This is like saying, I would not start to play football (soccer to you Americans and Australians), because Pele and Beckenbauer were so much better than me. It is a fair argument for making an investment as a company not as an individual.

    And to take the moral argument a bit further: Isn't is despicable to contribute towards an inferior tool like Eclipse, if there is a more powerful, better and reasonably priced tool available (Idea). Maybe open source is nothing but a covert operation from some industry giants to crush the competition? Also worth a thought.....

    Anyway, open source software is mainly created out of vain and evangelism - and personally I do not see anything wrong with it.
  14. Ugh![ Go to top ]

    Well, I beg to disagree.

    You are more than welcome to.

    >> way or another it is absolutely necessary to contribute.
    >Why would that be?
    It is simple: if you use a product, then it delivers a value to you - Give back something.

    >>This is like saying, I would not start to play football (soccer to you Americans and >>Australians), because Pele and Beckenbauer were so much better than me. It is a fair >>argument for making an investment as a company not as an individual.

    Strange conclusion, especially after complaining openly about concepts and telling about incompatibility on personal level. That king of things I like to see under #3,4 of my template.
    It looks like you reading template as a case against new project. Nope. It is a case for a project. The template begs developers making loud and clear why they do this or that.

    Do not like concept of a successful project: fine, do not feel guilty, just explain why and I might be first in the line to help. Or I can decide otherwise.

    Yes, my arguments sound like targeted against SGen, but they are in fact more a reflection of my desire to make XDoclet better, so it will continue to be even more valuable tool for me and others.

    About #2: I absolutely convinced that majority of developers start new projects without real understanding of problem area complexity. They just see that things seem complex and inconvenient. There is a law: things are not as simple as they appear at first and even third glance.
    Make it simple, but not simpler then necessary. That is the key!

    Keeping this law in mind I want to be sure that I am dealing with an intelligent person(s) and not a greenhorn (btw Cedric is certainly not a novice and SGen has a different agenda IMO).


    >And to take the moral argument a bit further: Isn't is despicable to contribute towards >an inferior tool like Eclipse, if there is a more powerful, better and reasonably priced >tool available (Idea).
    I use IDEA and do not like Eclipse. My decision: I would contribute to whatever I use and consider reasonable no matter if it is an OpenSource or Commertial product.


    >Maybe open source is nothing but a covert operation from some
     >industry giants to crush the competition? Also worth a thought.....

    Personally: OpenSource != free
    Availability of source code is a must for productive work and confidence in product’s quality. I do not use OpenSource on sole basis of it being free. In fact we recently bought a product after looking at poor code quality of its OpenSource competitors.
    Let me confess :), I _happily_ use commercial products. It is all about convenience. However, if I have access to source and allowed (even supposed) to do modifications there, it is a very solid argument in favor of a product.
  15. Ugh! x2[ Go to top ]

    Konstantin: It is simple: if you use a product, then it delivers a value to you - Give back something.

    That's why vendors charge money for their products, because they'd like to be sure that they get something back.

    When you give something away with no strings attached, how can you be so arrogant as to assert that people should give something back?

    I happen to think that it's great that some people do give something back, but if you really feel so strongly that they have that responsibility, then you should choose a different model of licensing -- one that would require their recompense.

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Clustered JCache for Grid Computing!
  16. Ugh! x3[ Go to top ]

    Give back something.

    Money counts as something :).

    >you really feel so strongly that they have that responsibility
    IMO: it is up to individual to decide if it is his/her responsibility to make something better, I would not suggest forcing it, rewarding – yes.
    >you should choose a different model of licensing
    I happen to like Jahia’s licensing model: http://www.jahia.org/

    How about starting another discussion about OpenSource, Free Source, Available Source and stop hijacking SGen discussion?
  17. Dirk: Have we really come that far, that one has to justify himself _not_ contributing to an open source project?

    Like any topic, the 1% that are extremists generate 99% of the noise.

    (In other words, yes.)

    It's a sad day when open source goes from being a choice to being a religion.

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Clustered JCache for Grid Computing!

  18. > It's a sad day when open source goes from being a choice to being a religion.
    >

    not a problem when you have enough followers, say Linux, Eclipse and others
  19. Sounds more like an xjavadoc killer or a qdox killer. How do you compare the performance of the metadata parsing say to qdox? What's the licensing since there does not appear to be anything in the download. I see the namespace is com.bea for SGen and JAM so I suppose SGen will be a great addition to BEA's Workshop. Should we expect an eclipse plugin to complement this? And should we expect anyone to write plugins other that BEA. What is the size of your commiter community?

    What I have found most valuable in XDoclet and what I think will be a value going forward is the maturity of the tag annotations. It will be an easy transition to JSR-175. They (XDoclet team) thought about portability by vendor, by specification, and by implmentation version. EJBGen works great for BEA but that's just one implementation and narrowly focused on EJB.

    You can't hate maven and lots of dependencies since maven handles dependencies nicely.

    I hope SGen will be a great value-add for EJBGen and Workshop.

    cheers
  20. 2 cents - xoclet[ Go to top ]

    I'll be giving EJBGen a try for one simple reason. xdoclet blows! The docs are horrible, especially for m:n relationships, AND it DID NOT generate my jbosscmp-jdbc.xml m:n descriptors correctly.

    Both the xdoclet and middlegen teams have a thing or two to learn regarding "easy to use, productive" frameworks. They were almost as bad as EJBs in terms of learning curves.
  21. 2 cents - xoclet[ Go to top ]

    I'll be giving EJBGen a try for one simple reason. xdoclet blows! The docs are

    >horrible, especially for m:n relationships, AND it DID NOT generate my
    >jbosscmp-jdbc.xml m:n descriptors correctly.

    And you think EJBGen is going to generate *any* JBoss descriptors? Not unless Marc plans to use his VC millions to buy Weblogic from BEA :-)
  22. Ranting about xdoclet & EJBGen[ Go to top ]

    To both of you guys... is the open source community afraid of swing apps? Damn people... I don't see me having to put meta-tags in the javadoc as being a better or time saving solution.

    You both blow chunks, congrats! Maybe I'll just build an EJB visual design tool... geeze.
  23. I don't see me having to put meta-tags in the javadoc as being a better or time saving solution.


    Well, if quite number of people see how metainformation in javadoc helps, then may be it really just you :)

    >> is the open source community afraid of swing apps?
    Looks like that, by some reasons people like SWT. I don’t.

    There are tasks, which might be done better with GUI and problems, which might be better addressed from code...
  24. Ranting about xdoclet & EJBGen[ Go to top ]

    Well if you want there's an EJB visual designer in Workshop 8.1 that
    puts the tags in the javadoc for you :-)
  25. I just posted a few clarifications. I hope they address the various issues mentioned here.

    --
    Cedric
  26. insertion into bytecode[ Go to top ]

    JAM questions:

    Any thought about using Javassist or BCEL to embed the annotations directly into a class file with JAM? Javassist at least has the api to embed attributes, but code would need to be implemented so that the embeded annotations would work with JDK 1.5. Javassist is shipped with an ASL friendly license, so there shouldn't be an issue there.

    Can annotations be represented in an XML format? Does JAM do any autogeneration around that?

    I guess what I'm saying is, that I dont want to have to require shipping with Javasource to get annotations and so that real, non-codegenerator applications can make use of annotations at runtime.

    Thanks,

    Bill
  27. insertion into bytecode[ Go to top ]

    JAM questions:

    >
    > Any thought about using Javassist or BCEL to embed the annotations directly into a class file with JAM? Javassist at least has the api to embed attributes, but code would need to be implemented so that the embeded annotations would work with JDK 1.5. Javassist is shipped with an ASL friendly license, so there shouldn't be an issue there.
    >
    > Can annotations be represented in an XML format? Does JAM do any autogeneration around that?
    >
    > I guess what I'm saying is, that I dont want to have to require shipping with Javasource to get annotations and so that real, non-codegenerator applications can make use of annotations at runtime.
    >
    > Thanks,
    >
    > Bill

    Shit, I just may do this myself, as I need the functionality.

    You guys should really think about separating JAM from XMLBeans. Would be a great project for JDK 1.4 users. Seems more complete than some of the other annotation projects.

    Bill
  28. insertion into bytecode[ Go to top ]

    Bill:
    You guys should really think about separating JAM from XMLBeans. Would be a great project for JDK 1.4 users. Seems more complete than some of the other annotation projects.

    We are doing that as we speak, stay tuned. And JAM already works on 1.4, by the way, that was the whole point (more about this on my next response to your other post).

    --
    Cedric
  29. insertion into bytecode[ Go to top ]

    Bill:
    JAM questions:

    Any thought about using Javassist or BCEL to embed the annotations directly into a class file with JAM? Javassist at least has the api to embed attributes, but code would need to be implemented so that the embeded annotations would work with JDK 1.5. Javassist is shipped with an ASL friendly license, so there shouldn't be an issue there.

    I think there is some misunderstanding about JAM, which is entirely our fault for not publishing more documentation (will be soon addressed).

    In its current form, JAM is simply an abstraction on top of Java's type system (1.4 and 1.5). It doesn't generate .class files nor does it need to insert bytecodes, it just insulates users from the way annotations were collected.

    That being said, we are working on expanding the scope in ways similar to what you are proposing, but we haven't finalized what we want to do yet.


    Can annotations be represented in an XML format?

    No, since XML is not part of the Java type system. We are thinking about allowing other providers (non-Java annotation based) to provide annotations, though.


    Does JAM do any autogeneration around that?

    JAM doesn't do any generation, per my previous point. This would be more SGen or XDoclet's job (or did I misunderstand your question?).


    I guess what I'm saying is, that I dont want to have to require shipping with Javasource to get annotations and so that real, non-codegenerator applications can make use of annotations at runtime.

    JAM will support .class files very soon but for now, you are right, it only supports source-based annotations (Javadoc and JSR 175).

    --
    Cedric
  30. few additions, comments[ Go to top ]

    Hello all, just tuning in here. I'm the mystery co-worker of Cedric's who put JAM together as part of my work on xml-beans at Apache. Cedric's done a great job fielding all the questions here. A few additions/clarifications:

    - I actually have already written the code to exppose 175 annotations using 1.5 reflection/classfiles, but I need to write some better tests before I'm confident that it is working correctly.

    - On the question of representing Annotations as XML: I'm not sure that I understand the original question, exactly, but the answer may actually be yes. JAM allows you to plug in and modify it's view of the type system as it is built, and that includes the view of metadata. So, it would be entirely conceivable to write something that parses an XML file containing metadata which you want to have 'inserted' into your view of a Java type.

    This actually was one of the big early motivating factors for writing JAM. I think JSR175 is basically fine, but I still worry that there are going to be cases where the 'baked in' approach to metadata is not going to work. JAM keeps the door open to other possibilities such as storing the metadata in some external repository (XML), or even for generating it programmatically on the fly (something I actually already have had to do with xml-beans).

    As Cedric mentions, I'm working now to get JAM cleaned up, documented better, and packaged distinctly from xml-beans. With a little luck, this will happen sometime in the next few days.