Discussions

News: TheServerSide Interviews Aslak Hellesoy on XDoclet

  1. TSS recently interviewed Aslak Hellesoy, project administrator for XDoclet and creator of Middlegen. In this interview Aslak discusses the current challenges the XDoclet project faces and its future goals and looks at using XDoclet for code generation. He talks about how XDoclet is complementary to Model Driven Development but is not appropriate for Aspect Oriented Programmming.

    Read the XDoclet Interview with Aslak Hellesoy

    Threaded Messages (38)

  2. Nice interview. I like Aslak's tone.

    I was alos pleased to hear about the new direction for this great tool.
  3. Some people deserve recognition[ Go to top ]

    Yes, the XDoclet team has done a great job and seems cool about it. It is refreshing to see that work can be done without the usual bosting and bragging that goes along with some projects. I have used XDoclet and I am grateful for the time it saves me.
  4. Good folks,
    Good interview,
    Anxiously waiting for next release of Middlegen (may be before summer).

    Just a reminder, the Struts plugin of Middlegen is somewhat limited.
    It seems not to work for composite PKs (like in the case of; PK of the middle table being made up of a pk and 2 foreign keys, in the case of a many-to-many relationship).

    Just another side note, another pretty good tool is TallSoftware's LowRoad (Jonathan Gibbons') at;
           http://www.tallsoftware.com/lowroad/index.html
    It does code generation with ejb or emulated ejb, coarse granularity, struts generation, merge, ..
  5. Hi Ilker,

    thanks for mentioning the LowRoad!

    http://www.tallsoftware.com/lowroad/index.html

    Even if you don't go with the LowRoad I have had comments about it being a great learning tool for EJB/Struts. So if you want to play with something that may help your understanding please take a look at the LowRoad.

    Made me grin to see someone else mention it for a change!

    Cheers,
    Jonathan
    ps yes I wrote it....
  6. One problem I have with this otherwise great tool is its reliance on Java code for generation. I've been interested in code generation for a while and have written some generators over the years. One thing that I would find extremely useful would be a generator that's designed to work with XMI so that UML models from just about any tool can drive the generation. I think this is a better approach because you can hash out a UML class diagram with business people, then add a bunch of stereotypes and tagged values, and use that as the basis for generation for everything from Java classes to sql to deployment descriptors to anything you might need.

    Another problem with a lot of the tools I've seen is that they usually determine for you the output format. I want complete control over my output files (which I'm pretty sure xdoclet gives you) rather than have someone else tell me what the best way is to do something.

    I've put together some ideas on what I'd like to see in such a tool and am curious about interest in a powerful, XMI-driven code generator that would let users determine their own output formats. I think that such a tool should be in the public domain because its so incredibly useful. Does anyone have any interest in or suggestions on how I might begin an open source project to address this need? If so, feel free to contact me at drew at lowerunit dot com.
  7. Hi. Thanks for all the nice remarks here.

    One problem I have with my refrigerator is that it can't brew beer. I've bought quite a few over the years, but none of them seem to be able to fill the shelves with cold beer. Grr.

    Ok, kidding aside. My point is that one of the most important success criteria for any piece of software (at least according to my taste) is to do one thing well.

    Nevertheless, XDoclet2's new architecture has also abstracted away the metadata. The XDoclet2 core has a reference to a MetadataProvider object, and this object has a public Collection getMetadataCollection() method. (This collection will be fed to the Jelly/Velocity templates, which can do whatever they please with it).

    XDoclet2 provides one implementation of the MetadataProvider interface (XJavaDocMetadataProvider), and the getMetadataCollection() method in this class returns xjavadoc.XClass objects. These objects provide all the information you can dream of from a Java source file.

    The nice thing is that you can write your own MetadataProvider that returns a Collection of other kinds of objects, representing e.g. an XMI model and plug it into XDoclet2 very easily.

    I haven't talked to the AndroMDA folks about this yet, so this is probably the first time they're hearing about that. I'm anxious to see what they think about this approach. It should simplify their codebase significantly, and they would have IDE integration for free, as this is built into XDoclet2's core.

    I suggest you have a look at AndroMDA. If they choose to integrate it with the XDoclet2 core, you'll have exactly what you're asking for. AndroMDA could feed the model to XDoclet, and you can tune the velocity templates to your taste. Even the current AndroMDA should get you quite far I think.

    This abstraction layer for metadata is also one of the things that makes XDoclet2 possible to use as the core of Middlegen. The next Middlegen version will just hook up a MetadataProvider providing objects that represent the structure of a database (these objects will be created with help of JDBC's java.sql.DatabaseMetadata).

    XDoclet2 is open in all ends. Anyone care to write a CSharpMetadataProvider?

    Aslak.
  8. It sounds like the open architecture is heading along a path I'm interested in, but I'm not quite sure yet. If I write an XMI metadata provider, how does that change my interaction with the templates? Is there still some sort of xdoclet-specific intermediary representation? My preference is to work with an XMI-based metadata model object, like the ones used by netbeans; xmi metadata is pretty standard, and the representations I mentioned have been used by a number of os projects. THen, my interaction with the templates would be in terms of those model objects. Is that possible, or do the templates require that the model object be an xdoclet-specific one.
    I've seen the AndroMDA project when it was UML2EJB. My problem was that it required an intermediary xdoclet conversion that I wasn't sure was necessary, though I could be wrong. Here's an example of why I'd like to work with the UML/XMI model object: when creating class diagrams of classes with string fields, I like to throw a UML tagged value on those fields to indicate their length. I periodically use other tagged values for various things that my templates can use to alter how code is generated. It's all very specific to the architecture to which I'm generating (one of the key things for me is that I determine the architecture and generate to that rather than use an architecture predetermined for me by the generator provider). I'm not sure if it would be possible to access those tagged values in my templates unless the model used by the template is an XMI-based object.

    I agree with the idea of do one thing and do it well. My understanding of earlier implementations of xdoclet was that it was designed to make it easy to mark up Java objects so that you could generated J2EE config files. What I'm looking for is a little more generic than that, to provide a way to generate any kind of file using templates and a metadata model based on XMI (since that's the lingua franca for modeling). If xdoclet is now headed in a way that supports that, I'd be thrilled. And sorry to keep pestering you with what I think your tool is not; my goal is to find out if it is what I need, which would be fantastic.

    Thanks,

    Drew
  9. I am one of the developers of the AndroMDA tool (www.andromda.org). The functionality you are describing, relating to XMI, is pretty much what the latest release of AndroMDA provides. It loads XMI into the NetBeans MetaDataRepository and then makes the UML 1.4 object model available to velocity scripts. The loading of the XMI and the control/configuration of the velocity templates is controlled a small set of ANT extensions.

    AndroMDA no longer uses an intermediary file format. It works directly with the UML model. It provides all sorts of ways for you to customize the way you access the model from the velocity scripts. You can access any element of your UML model from the velocity scripts. I've successfully generated code from classes, usecases, ..., state diagrams.

    I have not had a chance to look over XDoclet2 details, but my initial thought is that there should be some good possibility for some synergy between the two tools.

    Aslak describes a MetaDataProvider in XDoclet2. AndroMDA has pretty much this same concept. It comes with one metadataprovider for UML1.4 and the netbeans metadata repository.

    The AndroMDA framework does not care where the metadata comes from. It is very easy to write ones own metadata provider and use it instead of the existing. This has already be done by a few users. For example, one user did this in order to integrate AndroMDA into an UML CASE tool.

    I really can't say what the integration for XDoclet2 and AndroMDA will look like but I can say that I use both tools extensively and so I know that I will be personally motivated to make them work well together.
  10. Q: If I write an XMI metadata provider, how does that change my interaction with the templates?

    A: I'm not sure what you mean by "interaction with the templates". Your plugin code will not "interact" with the templates. You just tell where the template is and (optionally) what metadataprovider you want to use (plus other things like name of output file etc.) Then XDoclet will get the metadata from the provider (a java.util.Collection with arbitrary objects in it - whatever your provider provides) and hook it on the Velocity/Jelly context.

    The Velocity/Jelly templates must be written with knowledge about the metadata it's going to be fed. When you're writing your own metadata provider (returning e.g. NetbeansXMI objects), you'll also write templates that expect to find objects of a certain type on the context, and call appropriate methods on them. In Jelly and Velocity this is done via reflection.

    Q: Is there still some sort of xdoclet-specific intermediary representation?

    A: Nope.

    Q: Then, my interaction with the templates would be in terms of those model objects. Is that possible, or do the templates require that the model object be an xdoclet-specific one.

    A: The object model can be anything. No XDoclet-specific things are needed.

    Q: I'm not sure if it would be possible to access those tagged values in my templates unless the model used by the template is an XMI-based object.

    A: The templates can only access objects that are stored on the context. The metadata from the metadata provider will be available in a variable called ${object} (if the generation mode is one file per object in the collection) or ${classes} (if the generation mode is one file for all the objects in the collection).

    If you write your own Plugin class, you can also attach additional objects on the context, giving you all the flexibility you need.

    If you can navigate via these context objects to your tagged values from your template, you're there (via public accessors in your objects).

    Q: If xdoclet is now headed in a way that supports that, I'd be thrilled.

    A: Well, it's not a question really this one. Anyway, this is exactly where it's headed ;-) Don't be sorry, you're not pestering me (or anyone else) - I know your feeling. I have a good feeling that XDoclet2 is what you need. Check it out from CVS today, it's already somewhat usable. xdoclet2 module.

    Some of you might be thinking: "I can do this with Velocity and Jelly without XDoclet. I'll just write my own little thingy." That's true! What XDoclet2 is all about is to glue things together and provide a reusable framework:

    So if you have some odd input (radio signals from mars) and want to produce some really odd output from it (svg image of the signals) you could still use XDoclet2. And you'd get this for free:

    -No need to deal with the Velocity or Jelly java APIs.
    -Ant integration.
    -IDE integration.
    -A plugin mechanism. (Just drop in your plugin jar and go).

    Cheers,
    Aslak
  11. Q: If I write an XMI metadata provider, how does that change my interaction with the templates?

    A: I'm not sure what you mean by "interaction with the templates". Your plugin code will not "interact" with the templates. You just tell where the template is and (optionally) what metadataprovider you want to use (plus other things like name of output file etc.) Then XDoclet will get the metadata from the provider (a java.util.Collection with arbitrary objects in it - whatever your provider provides) and hook it on the Velocity/Jelly context.

    The Velocity/Jelly templates must be written with knowledge about the metadata it's going to be fed. When you're writing your own metadata provider (returning e.g. NetbeansXMI objects), you'll also write templates that expect to find objects of a certain type on the context, and call appropriate methods on them. In Jelly and Velocity this is done via reflection.

    Q: Is there still some sort of xdoclet-specific intermediary representation?

    A: Nope.

    Q: Then, my interaction with the templates would be in terms of those model objects. Is that possible, or do the templates require that the model object be an xdoclet-specific one.

    A: The object model can be anything. No XDoclet-specific things are needed.

    Q: I'm not sure if it would be possible to access those tagged values in my templates unless the model used by the template is an XMI-based object.

    A: The templates can only access objects that are stored on the context. The metadata from the metadata provider will be available in a variable called ${object} (if the generation mode is one file per object in the collection) or ${classes} (if the generation mode is one file for all the objects in the collection).

    If you write your own Plugin class, you can also attach additional objects on the context, giving you all the flexibility you need.

    If you can navigate via these context objects to your tagged values from your template, you're there (via public accessors in your objects).

    Q: If xdoclet is now headed in a way that supports that, I'd be thrilled.

    A: Well, it's not a question really this one. Anyway, this is exactly where it's headed ;-) Don't be sorry, you're not pestering me (or anyone else) - I know your feeling. I have a good feeling that XDoclet2 is what you need. Check it out from CVS today, it's already somewhat usable. xdoclet2 module.

    Some of you might be thinking: "I can do this with Velocity and Jelly without XDoclet. I'll just write my own little thingy." That's true! What XDoclet2 is all about is to glue things together and provide a reusable framework:

    So if you have some odd input (radio signals from mars) and want to produce some really odd output from it (svg image of the signals) you could still use XDoclet2. And you'd get this for free:

    -No need to deal with the Velocity or Jelly java APIs.
    -Ant integration.
    -IDE integration.
    -A plugin mechanism. (Just drop in your plugin jar and go).

    Cheers,
    Aslak
  12. One small correction: ${classes} and ${collection} are synonymous variable names in XDoclet2. Likewise ${class} and ${object}. ${classes} and ${class} were introduced to have a more intuitive variable names when working with metadata provided by XJavaDoc.

    Or actually, ${collection} and ${object} were introduced when we realised that metadata could be abstracted to be anything, not only xjavadoc.XClass objects.

    It feels funny to write code here on TSS. I haven't seen that in ages. More code and less bla bla and ranting please!

    Aslak
  13. Thank you both for your info on xdoclet2 and androMDA. I'm going to take a closer look at both. It sounds like I don't have to go and start coding this from scratch myself, and for that I'm grateful. I think guys like you who make tools like this are just great and the development community could use a lot more efforts like this instead of buzzwords and territorialism.

    Funny that Gavin King from Hibernate chimed in as Hibernate is my current favorite OS project (I can't tell you the amount of effort it has saved me and how well designed a toolset it is). Sorry to say, Gavin, that if this MDA thing works out, Hibernate may be supplanted as my favorite OS project....
  14. Matthias and Aslak,

    To my mind AndroMDA and XDoclet2 appear to have a large overlap in some core functionality. I am intrigued by the idea of prototyping a tighter XDoclet2 and AndroMDA integration, but I am not so sure where to start.

    I'd be interested in reading what you guys imagine to be the integration points for the two tools and the specialities for each individual tool. Where would the role of one tool start and the other end? What would you like to see the integration look like?

    It seems reasonable to expect that the same XDoclet templates could do generation from xdoclet tags embedded in source code as well as directly from a UML model.

    thanks
    amowers
  15. I think the best approach would be to identify where the overlap is in the code. I haven't looked at AndroMDA's source code in a while, but I think the only overlap is that they both use Velocity to render templates.

    If AndroMDA were to integrate with XDoclet2, I think the best approach would be to make AndroMDA a plugin for XDoclet2. Middlegen should also be an XDoclet plugin.

    1) Write AndroMDAMetadataProvider implements xdoclet.MetadataProvider
    2) Write AndroMDAPlugin extends xoclet.Plugin. This class can override the getMetaDataProvider() method and return a AndroMDAMetadataProvider.
    3) Follow the other XDoclet conventions for XDoclet plugin development.

    That's all there is to it really.

    About your last comment: "It seems reasonable to expect that the same XDoclet templates could do generation from xdoclet tags embedded in source code as well as directly from a UML model."

    This is a bit tricky, and I don't think it's a good idea. The "classic" XDoclet plugins' Velocity/Jelly scripts will expect to find XJavaDoc objects on the context. -And call methods on them (using the template engine's introspection mechanism).

    If you want the same templates to be able to deal with objects of a different type (say, NetBeans XMI objects) we'd have to invent some common denominator proxy API for XJavaDox and XMI. I think that would be a huge mistake. Like java.awt.

    The XJavaDoc and XMI metamodels are two very different beasts, and we should allow them to be that.

    I think the best approach is still what I'm saying in the interview. Let AndroMDA (or Middlegen) generate Java sources with @tags. -And then run "classic" XDoclet again to generate a complete component.

    I realise that this might seem a bit clunky (two step generation), but I fail to see a better way to do it. Of course, AndroMDA and Middlegen could be smarter and generate all the artifacts directly (XML descriptors etc) without relying on "classic" XDoclet plugins to do that.

    -But this would defeat the reusability and duplicate efforts. Let's encourage reuse and discourage duplicate efforts.

    Aslak
  16. yes please...[ Go to top ]

    If AndroMDA were to integrate with XDoclet2, I think the best approach would be to make AndroMDA a plugin for XDoclet2. Middlegen should also be an XDoclet plugin. <


    Aslak, if Middlegen were an XDoclet2 plugin, that would simplify our (Hibernate project) lives considerably. As you know the current situation is that, for people starting withy Java code, we use XDoclet to generate .hbm.xml mappings from @tags. Or, for people starting with a database schema we use Middlegen to generate .hbm.xml tags from JDBC metadata (then we can use the Hibernate hbm2java tool to generate code from the .hbm.xml). Unfortunately, with the current architecture, we need two different velocity templates that both generate .hbm.xml from the two different "models".

    If middlegen became an XDoclet metadata provider, we would only need one set of templates. Then, of AndroMDA did the same, we would get AndroMDA support for free!


    For people reading who are not familiar with this stuff, the proposed Hibernate full roundtripping toolset looks like this:


        >>>>>>>>>>>>> XDoclet >>>>>>>>>> >>>>>>>>> hbm2ddl tool >>>>>
    .java + XDoclet tags .hbm.xml mappings DDL Schema
        <

    (some parts of this are more fully implemented than others)

    Imagine if you could also have AndroMDA as an entry point to mapping file creation.

    Perhaps I'm just dreaming, but it sounds really nice.....
  17. yuck[ Go to top ]

    oh yuck my beautiful asci art got screwed up. doh!
  18. yes please...[ Go to top ]

    Are you saying that we could have one template for hbm.xml and feed it with metdata consisting of either xjavadoc objects or middlegen objects?

    These are completely different APIs, so both of them would have to be adapted through a "hibernate" metadata API. Then the hbm.xml template could deal with that API.

    This should be doable, but sounds a little complicated too.

    Is this what you mean Gavin? Any thoughts on how it could be implemented?

    (By the way, I recommend Jelly for generation of XML (in stead of Velocity). It has automatic formatting of the output and will capture typos like missing quotes and such.)
  19. speculation[ Go to top ]

    Are you saying that we could have one template for hbm.xml and feed it with metdata consisting of either xjavadoc objects or middlegen objects? <

    Yes, exactly. Granted, I hadn't thought this through ;)

    >> This should be doable, but sounds a little complicated too. <
    Probably.

    >> Is this what you mean Gavin? Any thoughts on how it could be implemented? <
    Yes, and no, not really!

    But the fact that I have two templates that generate exactly the same "stuff" from two different models made me feel as if there is some potential for some kind of intermediate representation of the input models as a "common" model. However, I think you are right and that the work involved in getting to that common model would be more work than goes into the templates.

    And now I'm seeing why that is: A .hbm.xml is already a "simplest possible" model of the entities and attributes. Its not as if I'm generating HTML with the templates!

    And for the other Middlegen plugins that generate java + @tags, I suppose that representation is also close to a minimal model (not quite as minimal as .hbm.xml, but close).

    So I conclude I'm wrong, its not useful :) I'll try not to indulge in such speculation at 1 am in the morning next time....
  20. Hi Aslak,

    first of all, thanks for the interview and XDoclet itself!

    <intro>
    Let me introduce myself to the audience here: I'm the lead architect and project admin behind AndroMDA and also the guy who wrote the first versions of UML2EJB, AndroMDA's predecessor. In my daily work as an independent software architect and consultant, I wanted to show my customers the power of model driven architecture.
    </intro>

    OK, now for the subject itself. Tony already asked "where is the overlap between the two tools?"

    The biggest similarity:
      Both tools are code generators. AndroMDA is driven by UML models, encoded in XMI files. XDoclet is currently driven by @tags in Java source code, however (as I have learnt today from the interview) will be driven by arbitrary metadata providers. The latter makes them very similar. At the conceptual level, a code generator is trivial: Read some metamodel, build an in-memory object graph, let a template engine process these objects and generate text from them. At this level, both tools are very similar.

    The biggest conceptual difference:
      AndroMDA and XDoclet generate code on different levels of abstraction. AndroMDA reads a model that is very conceptual in nature, at a high level of abstraction. It uses stereotypes and tagged values to map these conceptual classes to an underlying implementation technology. A "Person" class becomes an EJB (PersonBean) or a Hibernate POJO or an arbitrary piece of text, by changing configuration information, not by changing the class in the model. The user would tell AndroMDA to use the Hibernate cartride for this class instead of the EJB cartridge ("cartridge" is the name for the AndroMDA plug-in concept).
      XDoclet on the other hand (at least the classic version) operates on a much more detailed level, generating all this nasty stuff that nobody wants to write by hand (xml-ish deployment descriptors). It takes the implementation technology already as a given thing, the class does not try to be something else "after the fact". For example, the EJB bean class with the @tags is really the same bean class that will be deployed later (a thing that would completely violate AndroMDA's principle of a "platform independent model"). Similarly, a Hibernate object tagged with XDoclet tags would always remain a Hibernate object and not try to be something else.

    The synergy:
    Aslak, you have already said it:
    <quote>
      The XJavaDoc and XMI metamodels are two very different beasts, and we should allow them to be that.
      I think the best approach is still what I'm saying in the interview. Let AndroMDA (or Middlegen) generate Java sources with @tags. -And then run "classic" XDoclet again to generate a complete component.
    </quote>

    I agree with this completely. From the beginning, I have used XDoclet as a highly efficient afterburner that happily cares for every little detail that I don't want to care about. I have loaded AndroMDA with interesting features like automatic translation of 1:1, 1:n, n:m (unidirectional or bidirectional) relationships to @tags that describe these relationships in the necessary detail so that XDoclet can make an O/R mapper or an EJB container understand them. This is where the synergy between both tools is immediately apparent: Let the user draw one arrow with multiplicities at the ends and let AndroMDA spill out the necessary @tags for EJB/CMP, JDO or Hibernate relationship mapping.

    Now for the anti-synergy (antinergy?): :-)

    <quote>
      If AndroMDA were to integrate with XDoclet2, I think the best approach would be to make AndroMDA a plugin for XDoclet2. Middlegen should also be an XDoclet plugin. Write AndroMDAMetadataProvider implements xdoclet.MetadataProvider
    </quote>

    No. Please don't. AndroMDA is not a metadata provider but a code generator (plus runtime framework, in the future). What you could do is: Throw away the template engine used in AndroMDA and let the metadata flow directly through to XDoclet. Then, XDoclet can generate code, using the AndroMDA templates. However, XDoclet would have to generate one more class than before (the class that hosted the @tags before!). However, I suspect that this would mean squeezing two puzzle pieces together that have different shapes (as you also said above when comparing the UML and the XJavadoc metamodels).

    OK, it's very late, more about this another day...
    Matthias
  21. Mathias, Aslak,

    Imho we need a XMI->xjavadoc pipe. XDoclet templates use xjavadoc, so convert xmi to xjavadoc and let a single template handle the rest for you. The XMI->xjavadoc pipe can be implemented in a very granular way: create small reusable converter command objects, XmiClassToXjavadocXClassConverter and so on. In most cases there is a one to one mapping from the uml model to the code. So just specify which converter for which piece should be used (in an xml file) and reuse all these little command object. A conversion with a velocity template is not the way to go, it's not reusable in small pieces as reusable commands are.

    With this approach:
    - you have a single template, a single metadata behind the template (xjavadoc).
    - a conversion is needed from xmi/dbschema/whatever to the xjavadoc metadata model, and some small reusable converter objects can make the conversion effort as minimal as possible.

    Ara.
  22. This is a very interesting approach. I don't know if you have talked to James Strachan (of Jelly, Dom4J and others fame), but he has been talking to me about the exact same thing.

    This is definitely an interesting approach we should investigate more, as it could be the holy grail for tighter interop between XDoclet, AndroMDA, Middlegen, Hibernate and anyone who wants to join the club.

    You should also read Ara's interview on CGN. Lots of goodies here.

    Aslak
  23. No, Ara, not again![ Go to top ]

    Ara,

    we have already been discussing this in various emails. Last time, you even promised to mention the word one-to-one never again! Why are you doing this to me? :-(

    So, I try it once again:

      No, there is no one-to-one correspondence between UML model and code. In MDA, we start with a model that is independent of the implementation technology and far away from the code. One UML class tends to produce a whole bunch of implementation classes (Java, C# or whatever), calling underlying frameworks whenever they need.

    So, please go ahead, RTFM about MDA and come back.

    Puzzled...
    Matthias
  24. RE: No, Ara, not again![ Go to top ]

    Mathias,

    Yeah I remember those emails :-) But anyway *in most cases* there's a one to one mapping. At least in humaine technologies like Hibernate for example. In most cases a class in the model maps to a class in the code, a method maps to a method in the code and so on. In some inhumane cases such as EJB it's not that much the case, but still there's some kind of 1-n mapping that can be made convertable by some little reusable converter objects.

    Ara.
  25. I disagree very much with the idea of using UML to model one-to-one with the implementation. I think that would be a very bad direction to head.

    One of the things that is most useful about a model is that it is something less detailed than the actual implementation. The model captures the important concepts and brings them to the attention of anyone wanting to learn the system. This is try of all systems, not just software.

    If a model had all the same detail as the implementation it would no longer be a model. It would be the actual 'thing'. I know this sounds like a true-ism, but it seems to be something that has to be said again and again.

    IMHO the UML tools that try to generate java exactly from the UML on a one-to-one basis are promoting a bad paradigm. I think the more powerful approach is to build the model and then build up the implementation for the model.
  26. Other considerations[ Go to top ]

    Also keep in mind that models are used by more people on a development team than the developers themselves. Our DBAs use them to start doing their data models, our GUI team uses them to begin designing the interface. If appropriate, we also review them with the users themselves to validate requirements. For me, I wouldn't review a code-specific model with the business, ever.
  27. Hi Ara,

    you did not RTFMs on the MDA website, did you?

    With AndroMDA, we generate mainly architectures, not classes. Take the following example:

    You have a conceptual UML class called Contract (perhaps from the insurance domain). A contract has several architectural aspects which are very common in your application:

    * Conversion to a document
    * Printing
    * Keeping historical versions of the contract
    * Archiving on optical media
    * etc.

    Each of these aspects will be implemented by one or more classes which help Contract to be convertable, printable, historically manageable, etc. Because these classes are very common, you don't want to write them by hand but generate them automatically. This would perhaps cause the following classes to be generated:

    * ContractToPdfConverter
    * ContractPrintStrategy
    * ContractVersion
    * ContractArchiveSupport
    * ContractSomethingElse...

    You get the point? From one UML class (called Contract), we generate several classes to support different recurring aspects of the underlying architecture, technical as well as business-oriented and therefore project-specific.

    The architect of the target project has great resposibility: She has to identify the recurring aspects and write smart templates for the generator that make it really easy for the developer to switch on or off the aspects he needs to get business value out of his conceptual classes.

    So, one-to-one is only for the simplest projects for which you would probably not use Model Driven Architecture at all.

    Hope this could clarify the issue.

    Good night...
    Matthias
  28. code regeneration[ Go to top ]

    One of the most important features I want to see is code regeneration, i.e. regeneration of code while preserving user modifications. This is probably not a big deal with XDoclet since it is geared more towards generating deployment descriptors, required implementation interfaces/classes etc., but it is a big problem for Middlegen. As it stands now, and from the look of it, the next release too, Middlegen only generates "dumb" data access objects with no behavior attached, which really goes against the true essence of object-orientation -- behavioural completeness.

    In an ideal world, we would point our tool to a database to generate the data access objects (EJB, JDO, Hibernate etc.), and add behaviors to them. Periodically we would rerun the tool to synchronize between the database schema and Java code, while preserving the added behaviors.

    Does any one know how to do this? :)

    Rong
  29. code regeneration[ Go to top ]

    This feature has been debated a lot on XDoclet's mailing lists, and we still don't quite know how to do it. Merge points kind of solves the problems, but it's awful to keep source code snippets in separate files.

    We have talked about using some ultra sophisticated AST based merge mechanism (using Eclipse's JDT parser). But the more I think about it, the more sceptical I get. It's so darn complicated.

    So what I'm thinking of is to incorporate a simple line based diff/patch engine in XDoclet instead. DTSTTCPW.

    XDoclet would then try to merge the file on disk and the file-to-be-generated. Just like CVS does when you update over something you have changed locally.

    I'm curious what you think about this simplistic approach. Does anyone know about a Java implementation of diff and patch?

    Aslak
  30. code regeneration[ Go to top ]

    There's a codegen tool out there called iqgen that so far doesn't have a price. I've been playing around with it a bit. It's based around JSP, which has both pluses and minuses. They use a jsp tag that indicates that a section of code is user-custom code so that it shouldn't be overwritten on a subsequent generation. Not sure what they use to do the diff but it might be a starting place for your answer. I haven't played with that feature yet.
  31. Reverse engineering[ Go to top ]

    <quote>
     One of the most important features I want to see is code regeneration, i.e. regeneration of code while preserving user modifications.
    </quote>

    FYI, Reverse EJBGen solves this problem by generating base classes. Since EJBGen supports inheritance of tags, users can then simply extend the classes generated by Reverse EJBGen and add the logic in their own classes and future generations will not overwrite their changes.

    I can't think of a good reason why Middlegen couldn't do the same. What do you think, Aslak?

    --
    Cedric
    http://beust.com/weblog
  32. Reverse engineering[ Go to top ]

    Interesting approach. I haven't tried it, and I'll try it out in Middlegen's next version.

    Aslak
  33. Hi All,

    there are 3 types of generation concepts:

    Type 1: forward engineering: one-way generation. This is really
    an old concept, see "compiler", which generating sourcecode into
    maschine code. You should never change the "maschine code" manually.
    If you want to change something just change the "sourcecode".

    Type 2: reverse engineering. Example: decompiler. Just the same
    as forward engineering. Nothing special.

    Type 3: round-trip engineering (forward and reverse). This
    concept is also already old. We have two categories here:
    - Protection concept: every case tools try to archive
    this by adding "protection part" of the generated code.
    So, if a new generation should be done, it won't rewrite the
    changes already done at generated code. Many UML case tools use
    this technique.
    - Syncronization concept: using "synchronization" directly between
    your source and other "should be generated" parts. TogetherCC uses
    this concept instead using protection tags. It always synchronize
    all stuffs.

    IMO, MDA (Model Driven Architecture) tries to be the type 1,
    because theoritically, you only need to describe your software
    based on UML, OCL, etc. This means that MDA is becoming a new
    "programming" language just like Java. Until now, it is not
    possible to use UML to describe your whole software, that's why
    you always need the type 3 case tool (protection or syncronization).

    IMHO, only the 1. and 2. type are usable. The round-trip
    engineering especially the "protection concept" is *always*
    horrible.

    Some good examples:
    - Use JavaCompiler. This is great. You write your Java code
       compile them. I never need to touch the generated byte code.
    - Use XMLC (XML Compiler - Enhydra project). You write your
       *ML files and you compile them into Java codes. You just
       use the codes and never need to change the generated Java codes.
       If you need to change something, you just do it in your *ML files.
    - JavaDoc. Very good approach. You never edit the HTML files
       by yourself, right?
    - "One time generation" for preparing something. You will NEVER
       use the generator for the second time for the same stuffs.
       This is sometimes very useful but not as useful as other
       examples above. Example: how ArgoUML generates the Java code
       at the moment.
    - Generating EJBHome, EJBObject with XDoclet directly from your
       EJBean and never touch the EJBHome, EJBObject files manually is
       nice.

    Some bad examples:
    - Generating deployment descriptors with XDoclet. This is
       *NOT* a good concept, because you *have* to edit the DDs, at
       least at the deployment process. Surely this makes you faster
       creating the EJB at the development time, but whether you
       edit this in your codes or in your XML files, it does not
       make any difference. And because you need to edit those DDs
       at the deployment time the risk to overwrite them is high.
       In this case is just enough to have a good tool to edit
       those DDs.
    - Generating Value Object with XDoclet is *NOT* a good idea.
       Sometimes you need to implement validations within your VOs,
       so you have to edit the VOs by hand. And VOs don't always
       correspond to you EJB.
    - Generating Java classes from UML diagramms. If this is just
       "one time" generation, it will help just in the beginning.
       But if this becomes a round-trip engineering with "protection"
       tags, IMO, this is horrible. "Syncronization" is a better concept
       in this case.

    IMHO, all generators (EJBGen, etc.) should never support
    round-trip (especially with the protection tags). They should only
    support forward engineering. If this is not the case, there must be
    something wrong in that concept.

    Now to MDA, I don't know how far AndroMDA is. Whether it already
    supports, let's say, a new "programming language" or not. If so,
    we never need to write a single line of codes in Java anymore.
    We just "compile" the UML diagram and get a running system.
    Or do we need to add some codes in the generated codes? As long
    as we need to add some codes in the generated codes, it's not
    a real programming language, and we are just in the same situation
    as 5 or 6 years ago (case tools) ;-)

    What I see now, there are 2 approaches:

    - OMG with UML, MDA, OCL, etc. makes an "top down" approach:
    all that stuffs should become a new high level programming. You can
    describe your software just using them and compile them to have a
    running system. No need to implement in Java or C#. This means that
    UML is becoming very detail and complex, because they need to be a full
    blown programming language.
    - Java makes "bottom up" approach: with meta data, AttOP
    (Attribute Oriented Programming) they try to extend Java into a very
    high level programming language. XDoclet helps a lot in this area.

    One thing will stay: the view of your software system always takes
    these shapes:
    - Domain view (Analysis)
    - Infrastructure view (Specification)
    - Implementation view (Implementation)
    - Test view (Test)
    - Deployment view (Deployment)

    OMG with UML, MDA, etc. tries to handle all views (top down)
    and Java the same (but bottom up). So, who will win?

    I personally like Java as the language. TogetherCC has shown,
    that it is possible to use Java for all parts and extend
    Java with some visualization techniques (UML in this case).

    Best regards,
    --
    ---------------------------------------------------
    Blasius Lofi Dewanto
    ---------------------------------------------------
    OpenUSS - Open University Support System
    http://openuss.sourceforge.net
    ---------------------------------------------------
  34. <lofi>
    - Generating deployment descriptors with XDoclet. This is
       *NOT* a good concept, because you *have* to edit the DDs, at
       least at the deployment process. Surely this makes you faster
       creating the EJB at the development time, but whether you
       edit this in your codes or in your XML files, it does not
       make any difference. And because you need to edit those DDs
       at the deployment time the risk to overwrite them is high.
       In this case is just enough to have a good tool to edit
       those DDs.
    </lofi>

    I couldn't disagree more with you, and you forgot to explain why you *have* to edit the DDs after they're generated. I never do that. If I have environment specific things I want in the DDs, I do it like this:

    /**
     * @ejb.bean jndi-name="${mybean.jndi-name}"
     */
    public class MyBean implements SessionBean { ... }

    Then I provide different properties files for different environments and load the one I want into Ant before I build. This is also explained in the interview.

    Generating deployment descriptors is one of the biggest advantages of XDoclet. Are you sure you know how to use it?

    <lofi>
    - Generating Value Object with XDoclet is *NOT* a good idea.
       Sometimes you need to implement validations within your VOs,
       so you have to edit the VOs by hand. And VOs don't always
       correspond to you EJB.
    </lofi>

    I'd even argue that value objects per se is a bad idea ;-) But if you have chosen to use them, I think it's nice to have them generated. The generated value objects might not currently be optimal, but that doesn't mean the idea is bad.

    You can for example subclass the generated value objects and implement the validation there.

    If this doesn't work for you, we can fix XDoclet so it does.
  35. Inheritance, UML, XDoclet[ Go to top ]

    You all right,

    I forgot to mention "inheritance" for the round-trip ;-)

    <aslak>
    I couldn't disagree more with you, and you forgot to explain why you
    *have* to edit the DDs after they're generated. I never do that. If I
    have environment specific things I want in the DDs, I do it like this:
    Then I provide different properties files for different environments and
    load the one I want into Ant before I build. This is also explained in
    the interview.
    </aslak>

    Let's say I have 2 environments: "development" and "test deployment".
    In my dev-env surely I can generate all those DDs. In my test-env
    (deployment) sometimes I need to customize/edit those DDs
    (both vendor's independent and dependent DDs). In this case
    I just directly edit the DDs and I don't need to touch my
    sourcecode. It's just too costly if you have to change
    the properties files (like you told me) and compile those
    stuffs with XDoclet to get the DDs. I think, DD is
    "Deployment Descriptor" and not "Development Descriptor" ;-).
    Again, XDoclet for DDs helps you for your dev-env but I
    don't see any value added on it. A good DD editor would
    do the job better.

    <cedric>
    For what it's worth, EJBGen and Reverse EJBGen accomplish just that. If
    you decide at some point to edit the generated descriptors manually or
    with a tool (e.g. WebLogic Builder :-)), all you need to do if one day
    you decide to return to the EJBGen programming model is to run Reverse
    EJBGen on your jar file.
    </cedric>

    This could be the solution of the problem above ;-) This is nice
    to have, but do I get a value added for doing XDoclet for my DDs?

    <aslak>
    I'd even argue that value objects per se is a bad idea ;-) But if you
    have chosen to use them, I think it's nice to have them generated.
    </aslak>

    Maybe this is just the wrong term ;-) I meant the objects, you
    have to send back and forth for your Session Facade. In Floyd's
    book, he called this DTO (Data Transfer Object), if I'm not
    wrong. Sometimes people use "Value Object" for the same term
    as well, don't they?

    <aslak>
    You can for example subclass the generated value objects and
    implement the validation there.
    </aslak>

    The problem with inheritance in general is that you need to
    change the method name, return value, parameter of your class
    as well if those stuffs on your super class has changed.
    And inheritance is always "white-box" reuse.

    The question here is, is it worth it to let those DTAs/VOs
    generated for you, if you have to make many changes after
    that because the DTOs is not always correspond to the Bean
    (see Floyd's book)?

    We can surely generate everything, but the question is
    always, do I get a "value added" for that generation?
    For the *good* examples in my last thread is for sure,
    but not for the *bad* examples.

    <matthias>
    AndroMDA can't make UML better than it is. UML is a
    modeling language, not a programming language. Sometimes
    it cannot express something that a simple line of code can.
    </matthias>

    It's just a matter of time, that UML 2.0, OCL
    (Object Constraint Language), MDA, ... from OMG will
    become a full blown programming language.
    The specification of UML 2.0 shows this... ;-)

    Best regards,
    Lofi.
  36. Reverse engineering[ Go to top ]

    IMHO, all generators (EJBGen, etc.) should never support

    > round-trip (especially with the protection tags). T

    I think you are mixing up issues here. Right now, the science of reverse-engineering is complicated and not very well implemented in tools in general, so you decide that the idea is bad.

    I disagree.

    When/if the technical problems surrounding reverse-engineering are resolved, it will be much easier for developers to get their job done. You can choose any generator you want, use it for a while, then decide to use a different generator (or hand-edit the generated code). Then later, you decide that generators are not that bad after all and you can safely return to their world, using reverse-engineering to keep all the code you added manually.

    For what it's worth, EJBGen and Reverse EJBGen accomplish just that. If you decide at some point to edit the generated descriptors manually or with a tool (e.g. WebLogic Builder :-)), all you need to do if one day you decide to return to the EJBGen programming model is to run Reverse EJBGen on your jar file.

    Reverse EJBGen will generate base classes for all your EJB's with the correct EJBGen annotations. At this point, it's up to you to extend these classes in your beans, or if it's not an option, copy the said annotations directly inside your EJB (an admittedly weak point of the model, due partly to Java's single inheritance of implementation).

    Other than that, you make good points, especially the shapes of software systems.

    --
    Cedric
    http://beust.com/weblog
  37. <quote>
    Now to MDA, I don't know how far AndroMDA is. Whether it already
    supports, let's say, a new "programming language" or not. If so,
    we never need to write a single line of codes in Java anymore.
    We just "compile" the UML diagram and get a running system.
    </quote>

    Hi Lofi,

    AndroMDA can't make UML better than it is. UML is a modeling language, not a programming language. Sometimes it cannot express something that a simple line of code can.

    So, this is the way we go with AndroMDA:
    * Model your classes etc. in UML.
    * Generate the code.
    * Write classes by hand that extend the generated ones.
      Put your business logic there.

    That way, we do not need protected sections nor synchronization. Simple and straight forward.

    By the way, I still like to write code in Java to express myself but I let generators support me with the tedious stuff. See my interview with Code Generation Network for a detailed explanation.

    Cheers...
    Matthias
  38. Xdoclet and Middlegen life savers![ Go to top ]

    Both xdoclet and middlegen are free, they are small tools and require little CPU usage.Without them i would have never been able to understand EJB and struts . They were a definite life saver for my final year university project. I say good work to Aslak and the xdoclet and middlegen team. There software has done well beyond what JBuilder , Jdeveloper and all the other EJB crap tools on the market have to offer.
  39. "Where the Round trip??"[ Go to top ]

    ok, ive been using xdoclet/middlegen/hibernate for a good while now.. here is my procedure.

    i only use middlegen in the earlier stage from a legacy database. it generates the .hbm WITH THE XDoclet tags, which i like...then i use java2hbm that generates the nice java files WITH THE Xdoclet tags.. NOW this is where round trip stopps and i havnt foudn a solution. i change an Xdoclet tag, in the java class then run java2hbm(using xdoclet hibernate tool), and it DOES NOT include the xdoclet metadata tags in the .hbm files! When i run hbm2java again on the second generated hbm files , they create the java files WITHOUT the metadata tags ... is there a setting i can tell xdoclet to include the metadata tags when generating the hbm from java??

    middlgen->hbm(with xdoclet tags)->hbmn2java->creates java(with xdoclet tags)

    java2hbm(xdoclet plugin)->hbm(without xdoclet tags)-> :(

    if possible please send me a response..thanks

    Jeryl Cook
    http://pharaohofkush.blogspot.com/