Gentleware AG has released Apollo for Eclipse 1.1, a modeling tool aimed at agile developers who want to combine the advantages of visual modeling using UML (Unified Modeling Language) with programming in Java. Productivity and usability features along with increases in stability and scalability highlight the newest offering. One of the most compelling additions is the new inline code editor, which integrates designing and coding directly into the diagram editor. A double-click on the graphic representation of a diagram element opens a code editor immediately within the diagram, providing instant access to the relevant code. Additional changes to the user experience have all been designed to further speed up development, with features such as new navigation options between parent and child elements and rapid buttons for even faster diagram creation. Apollo for Eclipse is the first commercial UML 2.1 modeling tool that is based on the open source technology developed by the Eclipse Graphical Modeling Framework (GMF) project. The UML 2.1 profile mechanism and the Eclipse framework allow it to be customized and extended for domain-specific languages (DSLs), thus making it ideal for model-driven software development (MDSD). Message was edited by: joeo@enigmastation.com

Well, of course I know it is different and better and the performance is better and....but the whole press release feels like a Deja Vue from 1999. :-) Peace /Karl

I picked up Apollo because I was looking for a simple class diagram tool. I was surprised to find that even though they're aiming at _just_ class diagrams, even that functionality isn't useable. For instance, their main use case (only? I haven't found another) seems to be right-clicking a package, clicking "open in diagram editor (or view)," and you then see a diagram of all classes in a package. All of them. Want a class from another package on the diagram? It isn't possible. Want to only see some classes from a package in that diagram? Can't; removing something from the model deletes your class. Want to add a note to the diagram? Nope. Does the diagram keep in sync with the code when classes are edited outside of the diagram? Nope. Oh, and hopefully you also don't mind that viewing a package in a diagram also appears to leave behind model.auml files in every package in your source, which quickly get stale. It makes me wonder how other people tend to use tools like this. Do many people want to work exclusively within a diagram rather than a java editor? That seems to be Gentleware's vision, since their major new feature is that a mini java editor pops up when you want to do in-diagram edits. Personally I would never want this. I primarily want to be able to use UML to document code. As a tool for UML documentation, I'd steer clear of Apollo until they round out their tool.

I primarily want to be able to use UML to document code. As a tool for UML documentation, I'd steer clear of Apollo until they round out their tool.

I've previously used Gentleware's Poseidon product for exactly this purpose, and I've found it to be generally quite good. I'm confused as to Gentleware's approach here. With a perfectly good tool like Poseidon, why bring out something like Apollo which seems to be re-inventing the wheel without adding any real value? I'm guessing there is some sort of long-term strategy to rationalise these two products, somehow.

I think you're right about it being a long term thing. Poseidon is built on ArgoUml, a ground-up implementation based, I think, on Swing. Apollo is built using Eclipse's UML2 and RCP infrastructure, which if they're making a play for the Eclipse market, is a better foundation since it'll work well with the many other tools also built on EMF/UML2 (Lots of MDA activity there for instance). Still, I'm surprised at how inept their 1.1 feature set. Incidently, Vineet, Relo looks very interesting. I'll install it later and give it a whirl, but from your flash walkthroughs, it looks like what I'm looking for.

Incidently, Vineet, Relo looks very interesting. I'll install it later and give it a whirl, but from your flash walkthroughs, it looks like what I'm looking for.

When you do try it, please give us feedback on the Relo - site. In particular, it will be helpful if you can tell us what you liked, what you didn't like, and any feature that you wish Relo had. Feedback will help us target parts to improve and will justify putting more resources into developing the tool. {Karl, I have not seen the error before, but if you e-mail me at vineet at csail dot mit dot edu (with you exceptions log and your configuration details) I expect to be able to diagnose it.} Oh yeah, if you have free time to help improve Relo that is appreciated as well. -Vineet

I would be curious as to what most of you think of this tool: Relo - Relationship based Exploration. It is actually based on my PhD thesis here at the MIT CS+AI Lab, and at some level is an attempt at trying to answer why there has been v.little usage of traditional UML tools. -Vineet

I would have given it a try. But nowadays my time is just too limited for archeology....if something fails to run after I install it using Eclipses Find&Install functionality I usually blame it on the tool provider :-) java.lang.ClassNotFoundException: edu.mit.csail.relo.ui.ReloThumbnailView at org.eclipse.osgi.framework.internal.core.BundleLoader.findClass(BundleLoader.java:405)