XDoclet 1.0, successor to EJBDoclet is released!

Discussions

News: XDoclet 1.0, successor to EJBDoclet is released!

  1. XDoclet is the successor to EJBDoclet. An EJB code generation tool, XDoclet allows you to embed javadoc tags in your EJB Bean class from which you can generate the Remote, Local, PK, Home, Data object, CMP classes and the deployment descriptors. Unlike the original EJBDoclet, XDoclet is more genericized - any type of files can be generated from a javadoc encoded source files.

    XDoclet is wholly restructured,with lots of changes and new features that it's almost impossible to list them all even briefly here!

    Features:
     Full EJB 2.0 support. All EJB @tags now consolidated.
     Supports for CMP
     EJB: support for Websphere 4, Weblogic 6.x, Orion, JBoss
     Support for Struts, JSP Taglibs, WebWork, Apache-SOAP, JMX
     Support for business interface pattern, data object pattern.

    Templates:
    New parsing engine, lots of new tags, existing tags more generalized.

    Get it at http://sourceforge.net/projects/xdoclet
  2. For anyone who hasn't used EJBDoclet, I strongly recommend it. The system allows you to concentrate on the business logic and entity code without having to worry about all of the plumbing necessitated by EJB. Generating remote and home (and local) interfaces and ejb xml descriptors becomes a compile-time process of integration.

    Coupled with the build features of ant and you have an incredibly powerful and flexible system - it increases the value proposition of EJB significantly.
  3. <<
    Coupled with the build features of ant and you have an incredibly powerful and flexible system - it increases the value proposition of EJB significantly.
    >>

    Of course, so does EJBGen :-)

    http://beust.com/cedric/ejbgen
    http://www.yahoogroups.com/group/ejbgen

    --
    Cedric
    (Floyd, where is my ObPlug?)
  4. An important difference is that XDoclet is open sourced and extensible. On the other hand, Cedric does a fantastic job - bugs get fixed and requested features get implemented (almost) in real time.

    --
    Dimitri
    (Cedric, what is ObPlug?)
  5. <(Cedric, what is ObPlug?)
    >>

    Ah, I guess my age shows :-)

    Back in the days, there was a newsgroup call "alt.hackers". This newsgroup was special in two ways:

    - you couldn't readily post there, you had to find a way to hack your article inside the newsgroup

    - you were not allowed to post an article unless it contained at least one hack. Therefore, people would typically post an article commenting on somebody else's and they would conclude their post with an "ObHack" (obligatory hack)

    My "ObPlug" stuff came from the observation that Floyd (or yourself :-)) usually plugs EJBGen before I have the time to do it myself, hence my disappointment. I'm telling you, since www.theserverside.com got the front page on Javasoft's Web site, Floyd is in over his head. He can no longer be trusted.

    --
    Cedric
    ObHack: writing code while drinking sake

  6. My "ObPlug" stuff came from the observation that Floyd (or

    >yourself :-)) usually plugs EJBGen before I have the time
    >to do it myself, hence my disappointment. I'm telling you,
    >since www.theserverside.com got the front page on
    >Javasoft's Web site, Floyd is in over his head. He can no
    >longer be trusted.

       Hehehe, yes life is good since the java.sun.com feature. Cedric, yes I have lapsed in my job as promoter of all cool EJB projects in the world. :) I think you will have to start pulling your weight and plugging your own product more often. :)

    Floyd
  7. <quote>
    Of course, so does EJBGen :-)
    </quote>

    True. I will admit I dont know a lot about ejbgen, apart from the fact that both projects share a concept. The real difference though, is that XDoclet is no longer EJBDoclet. The "X" is there (IMHO) for eXtensible. XDoclet already has tasks for:
      - web.xml and jboss-web.xml
      - struts-config.xml, struts form classes
      - webwork
      - jmx mbean interfaces
    and so on. The important thing is that XDoclet is a framework for templates. We provide a number of prebuilt templates for the most common uses so far, but the framework allows you to define your own templates and ant tasks with minimal coding.

    One of the ideas on the cards at the moment is a @todo style tag, which can then provide reports on the status of your project. I'm sure that we all know what its like providing reports to management - wouldn't you prefer to just say "read the code"... with XDoclet 1.1, you'll be able to!

    cheers
    dim
  8. I took a look at XDoclet and I have to say it looks very cool, you guys did a very good job at building on and expanding Rickard's original design. Congratulations.

    I will make just one remark:

    <wouldn't you prefer to just say "read the code"... with XDoclet 1.1, you'll be able to!
    >>

    <soapbox>

    A lot of "real world developers" don't have the time (nor the will) to "read the code". That's not what they are paid for. They want tools that work right out of the box. If they find a tool that doesn't quite fit the bill, the biggest effort they might make will be to email the author and if they plan to support the feature. That's all.

    That's the philosophy I have been trying to stick to while developing EJBGen.

    </soapbox>

    --
    Cedric

  9. Cedric,

    I've just re-read your post after wondering what you were saying for a while (o: I see what I've said now... I'd better clarify (o:

    When I say

    "just read the code"

    I done mean that as a user of XDoclet you are expected to read the code to make it work.

    What I mean is that with something that Aslak has just put in, we now have support for @todo style tags... meaning that a status report can be generated every build. The reason I am so excited about this is that the week before he checked it in I found myself doing a grep -i todo `find . -name *java` so that I could report to maangement how many TODOs we had in our code. Had we been using a tagged todo, we could have generated this information in a much more useful format without doing any more work.

    So when I said 'wouldn't you prefer to say "read the code" ...' what I meant was that you could use this @todo tag to generate a report that you'd automatcially mail to interested parties as part of the nightly build.

    I hope that clarifies it (o: I certainly wasn't meaning that XDoclet developers have to open up the code, although I can see how it came across that way.

    cheers
    dim
  10. geez.. I've rushed it again... I meant XDoclet users - not XDoclet developers...

  11. <quote>
    I hope that clarifies it (o: I certainly wasn't meaning that XDoclet developers have to open up the code, although I can see how it came across that way.
    </quote>

    Understood, thanks for the clarification.

    As an aside, note that Visual Studio and other IDE's have supported TODO tags in comments for a while. The added bonus is that the IDE tracks those automatically, making it easy to pop up the TODO window and see what's still left to do. Very neat.

    --
    Cedric
  12. The todo functionality is in the latest CVS now. It generates a browsable report that looks a bit like javadoc, or Ant's JUnitReport. My project manager loves it.

    Aslak.