TextUML Toolkit 1.0 has been released!

I am proud to announce that the TextUML Toolkit reached version 1.0!

TextUML Toolkit 1.0 splash screen

It is basically the same as the RC3 build, made available earlier this week, with version numbers updated to reflect the status of release. You can download the TextUML Toolkit 1.0 from here.

Even if it still preserves the same humble look & feel, the TextUML Toolkit has come a long way since the first public milestone was announced here more than a year ago:

  • M1 – May 2007
    • website went live
    • first public milestone
  • M2 – September 2007
    • graphical class diagram visualization for Windows only (spawned as a brand new open-source project, EclipseGraphviz)
    • support for enumerations
  • M3 – March 2008
    • reverse engineering of UML2 models as TextUML source (aka textual browsing)
    • diagram rendering also on Linux and Mac OS/X
    • click-through license
    • better stability and performance
    • website improvements: added user forum (SMF)
  • M4 – May 2008
    • duplicate symbols properly reported as compilation errors
    • TextUML source renderer showing nested packages
    • evaluated a few code generators (Acceleo, oAW xPand, EMF JET), chose Acceleo
    • first milestone available via update site
  • M5 – June 2008
    • fixed a serious memory leak caused by UML2 caching
    • several bug fixes
    • decoupled the TextUML Toolkit from EclipseGraphviz (EG becoming just a possible integration)
    • website improvements: wiki-based (MediaWiki) documentation area
  • 1.0 – July 2008

On the outreach front: in December, I did a quick presentation of the TextUML Toolkit during the Eclipse DemoCamp in Vancouver, and had the opportunity of doing a longer, more detailed presentation at the VIJUG’s meeting in April. At both opportunities, receptivity to the project was quite good. People seemed very keen on the idea of UML models as text, and I got lots of interesting questions.

In early June, I joined many other fellow mISVers in the 30-day product challenge. Even though I didn’t achieve everything I had set out to do, I am quite happy for having been part of it, as it provided me with the strength and courage to finally ship the first release.

Overall, I am quite happy with the current state of the TextUML Toolkit (or else I would not have declared a release). On the other hand, I confess I am disappointed that interest has not picked up yet, considering it is a free tool that provides real value. Now that there is an example describing how to use the TextUML Toolkit and Acceleo for generating code from UML models (which is the main application of the tool), I hope the value of the tool will become more apparent. And I guess more attention to the marketing side of things won’t hurt.

For the next few months, I will be focusing on a more ambitious project I have hinted at here a couple of times before. During this time, I will be promoting the TextUML Toolkit, writing more documentation and examples, and fixing any bugs users might report, but I do not plan to develop any new features unless there is user demand.

Well, it has been a fun ride, and I appreciate the interest of those of you who have followed at least some part of the journey. Your comments on the blog have been very helpful and encouraging. Thanks a lot!

Cheers,

Rafael

EmailFacebookLinkedInGoogle+Twitter

Sample application, TextUML Toolkit RC3 are now available

The Pet Store-like model-driven sample application is now available. This initial version contains UML models for a few of the key entities, and generates the domain model classes and their corresponding Hibernate mapping files. I noticed the generated mapping files (or maybe the models) have a few issues and/or missing elements, but as a first stab I am quite happy. Please give it a try. It is a great way example of how the TextUML Toolkit can be used in the context of code generation, in this case, with the awesome Acceleo tool (open-source). Note this is just an example – you should be able to use any UML2-based Acceleo modules (like those available from Acceleo’s module repository) and generate code from any UML models you create using the TextUML Toolkit.

In addition to the sample application, the latest TextUML Toolkit release candidate (RC3) is also now available, both as a standalone download and as an update site, as usual. Work items delivered in this build:

  • ticket #182 – associations end up with one single member end
  • ticket #183 – cannot define stereotypes on stereotypes
  • ticket #167 – provide sample application

To my fellow 30-dayers – yes, its 8 days past the 30 day deadline, but unless I get a serious bug reported during this week, this is it, I am about to achieve my modest goals (yay!) of shipping 1.0 and a sample application (remember, I started working on the TextUML Toolkit quite while ago). The only planned change for 1.0 is basically updating the splash screen to sport the elusive 1.0 version number.

Feedback on RC3 or the sample application is most welcome. As usual, feel free to comment here or on the forums.

Cheers,

Rafael

EmailFacebookLinkedInGoogle+Twitter

Time is up

Even after cutting scope to close to half of what I was planning, I failed to accomplish what I set off to do in the 30-day challenge. I basically have the code and the example in a releasable state, but I have no means to publish a tutorial with images due to some unexpected web site issues. Even without this issue, I might not have made it, given how much work I left to the last day. Anyway… after spending quite some time trying to get MediaWiki to behave (with no success), now I don’t have time or energy for packaging and pushing the bits of the TextUML Toolkit RC3 (hopefully 1.0?) to the FTP server. Should do that at some point this week, and also hopefully get the wiki back online.

Well, enough ranting, need some sleep now. Thanks to the other 30-dayers for being part of this, and hope you guys had better luck. Cheers,

Rafael

P.S.: I considered not writing in my current mood, but I thought in the end it would be more honest doing so, so there you go

EmailFacebookLinkedInGoogle+Twitter

Scope cutting season

Well, things are not going so smoothly in TextUML Toolkit land. Hope the others are doing better.

  • a user reported that the embedded Graphviz install was not working for him on Windows XP (I expected it to work on all Windows versions, but really tested only on Vista). After some investigation, I realized that a minimal Graphviz install will look very different depending on the Windows version. Result: I decided to quit bundling Graphviz for Windows. Now, the TextUML Toolkit users on Windows have to manually install Graphviz on their own, and configure the location of an external Graphviz manually, just as Linux and Mac OS X users had to do since day 0. The latest build RC2 (just published) already reflects that change.
  • a simple WordPress migration using GoDaddy’s Hosting Connection became a big hassle (their rollback feature did not work either). Result: had to delete my existing install, and install the latest version from scratch (thankfully, WordPress export/import features worked like a charm). Lesson learned: avoid doing any infrastructure changes that are not critical in the weeks preceding a release (even if they seem harmless).

I finally woke up to the fact I am really late with most of the deliverables I planned for June 30th and we are already a week from the deadline. I decided thus to postpone all non-product related items. Other than any critical bug that might be found this week, I will be focusing on publishing the sample application on the wiki. Nothing else.

Well, maybe some blogging.

EmailFacebookLinkedInGoogle+Twitter

Moving forward again

I finally figured out what was preventing me from exporting the product from Eclipse and worked around the problem. So the TextUML Toolkit RC1 is finally available for download, 4 days after planned.

It turned out the issue that was blocking me was not specific to Eclipse 3.4 RC3. Still, I decided that, until the end of the 30-day challenge, I will continue to use 3.3 to avoid any further surprises. I intend to go back to 3.4 shortly after that.

Another important task that was planned for the first phase (first two weeks) and I have yet to address is the sample application (models + templates). That means some of the less critical work items planned for the second phase will have to be postponed (probably the artwork item).

Even though I am behind schedule, I am really happy to be moving forward again…

EmailFacebookLinkedInGoogle+Twitter

The bleeding edge: not for the faint of heart

(To my fellow 30-dayers: It has been a while since my last post in the 30-day challenge category – at least if you think of how brief it is. But worse, I am also behind the schedule. My goal was to have the first release candidate on the 15th. It is the 17th and I am not quite there yet. Read on for details)

Every now and then, the Eclipse Project goes through quite significant changes (OSGi and RCP in 3.0, P2 now in 3.4). And when the platform moves this fast, everybody living above feels it. New features are not well documented or are not very stable. Tooling for plug-in developers lags behind. Things that used to work before, are now broken.

That is really hard to avoid, even though backward compatibility with the previous release is a hard requirement for the Eclipse Project. I was part of the Eclipse Platform Core team in 3.0 (shipped in 2004) and even though we were having lots of fun with the move to OSGi and the birth of Equinox, it was a lot of work having to implement the new functionality and at the same time make sure all the existing use cases continued to work. And, as usual, some corner cases we missed were only discovered close to the release date, or even right after, when most people will finally migrate from the previous release. Many of the OSGi-aware features were only exposed by the plug-in development tooling in the subsequent releases. And even though we felt like all that backward compatibility effort was draining a lot of our time and energy, users would still get mad at us for introducing regressions, when they didn’t really give a damn about OSGi or RCP.

In hindsight, it is clear that all that work paid off when you look at the impact that OSGi and RCP had in the growth of Eclipse way beyond the realm of IDE frameworks. People are using Eclipse as a platform for embedded and server-side applications, or rich client applications you could swear were native. OSGi itself had a boom in adoption (and features) since when it was adopted in Eclipse and moved from niche technology into the mainstream.

I am sure the same is going to happen with P2, probably in smaller proportions (given its scope). We will be taking its features for granted two years from now, and the pain of change will have been long forgotten. And the good people developing P2 know that. But, this time around I am…

…on the other side of the fence

The plan of shipping TextUML Toolkit 1.0 (scheduled for June 30th) on top of Eclipse 3.4 (scheduled for late June – yes, that should have raised a flag) proved to be quite a challenge. I have had minor problems with the latest Eclipse SDK milestones, which I could work around, but more recently I have faced more serious, blocking issues. And even the non-blocking problems and difficulties, which are just time wasters, grow in importance when you are in a tight schedule.

So I stepped back and decided to and develop and ship the TextUML Toolkit 1.0 on Eclipse 3.3, which was last year’s release. It was not an easy decision, as I will be missing many improvements and fixes (some of them to pretty significant issues) made in the UML2 and EMF components, which are the main requirements. But at least I should be able to move forward in a more predictable pace, and be more confident I have a chance of meeting the June 30th deadline, even if quality might suffer. On the bright side, thanks to backward compatibility, the same update site should still work with 3.4, so users using the Update Manager/P2 in Eclipse 3.4 should be able to install the TextUML Toolkit features, and get better performance and stability.

What makes me feel good is that backward compatibility continues to be one of the Eclipse key values (e4 rumors aside), so regressions receive high priority and are fixed as quickly as possible. The least we (end-users and product providers) can do is to diligently report them.

EmailFacebookLinkedInGoogle+Twitter

TextUML Toolkit – Layout control for class diagrams

Contrary to my original intention of working this week on code generation and the sample application, I have been doing some improvements in the graphical visualization of UML models in EclipseGraphviz. EclipseGraphviz (a spin-off of the TextUML Toolkit) is an open source component (EPL) that integrates Graphviz into Eclipse, and among other things, can generate UML class diagrams from Eclipse UML2 models on the fly.

After fixing a couple of bugs, I decided to add a preference page to give some level of control over the way the diagrams are laid out. Here is what it looks like:

You can now turn on or off several adornments such as association end names, multiplicities and membership. For example, this diagram was rendered using the options shown above:

Whereas the following one was rendered for the same model while having only the “Create constraints for association navigability” option checked:

As you can see, enabling constraints based on association navigability can significantly alter the diagram layout. One good reason for enabling that option is to avoid diagrams that grow too much horizontally (as Graphviz will put all nodes of the same rank on the same row), but I personally prefer the former layout.

Side note: I considered dropping the graphical visualization feature altogether for 1.0, as I see it as just a nice to have, and am not totally happy with the quality of the diagrams generated by Graphviz. But every bit of feedback I got for the TextUML Toolkit was that the graphical visualization was really nice, so I changed my mind. But unless serious bugs are found in this area, I have no plans of touching the EclipseGraphviz code again until after I complete the 30-day challenge.

Side note #2: I expanded the FAQ to cover the issue of notation choice and the role of EclipseGraphviz in the TextUML Toolkit.

EmailFacebookLinkedInGoogle+Twitter

TextUML Toolkit – Progress on the sample application

Took a first stab at creating the model for the sample application for the TextUML Toolkit. As I wrote here before, the sample application is derived from Sun’s Java Pet Store application. Take a look at the models, and let me know how the textual notation feels.

It is late and I am tired, so it is very likely I have made at least a few mistakes (well, not syntactic ones, as the tool tells me about those). Of course, when I start working towards generating the code from the models, I am sure any mistakes I made will quickly emerge.

Cheers,

Rafael

EmailFacebookLinkedInGoogle+Twitter

TextUML Toolkit – Commitments for the 30 day challenge

As I mentioned before, I joined the 30 day product challenge with the TextUML Toolkit. Of the benefits of being part of the challenge, the ones that most attract me are the sense of being part of something greater, and the motivational power of peer pressure (even if imaginary) and fear of public failure. With that in mind, these are my commitments for the challenge:

Phase 1 – June 1st to June 15th:

Focus on finishing development and examples.

  • publish the milestone 5 of the TextUML Toolkit (M5) (done)
  • making UML graphical visualization an optional component (done)
  • publish an example application
    • model – probably a subset of the Java Pet Store app
    • code generation templates – probably using Acceleo
  • should target Eclipse 3.4 (done – M5 can be installed on Eclipse 3.4 or 3.3, but download will continue to bundle 3.3 due to lack of tool support for product creation in the new software update mechanism available in Eclipse 3.4)
  • bug fixing (continuously)
  • improve documentation (continuously)
  • publish Release Candidate 1 on June 15th
  • development freeze

Phase 2 – June 16th to June 30th:

Focus on polishing and getting it out of the door.

  • major/critical bugs
  • minor bugs/polish items
  • improve documentation (continuously)
  • artwork
    • icons for TextUML source files, new project wizard (outsource)
    • website (images, skins)*
  • legal stuff
    • make sure we comply with all licenses for any bundled open source software
    • legal notices using Eclipse branding
    • beef up license (no redistribution, no reverse engineering)
  • PR (go easy, this is 1.0) – EPIC, announcement-friendly developer forums
  • one active beta-tester
  • one early adopter*
  • screencasts (this is a biggie)
    • creating a UML model using the TextUML Toolkit
    • generating code using Acceleo
  • RC3 on June 29th
  • declare 1.0 on Monday June 30th

* marks nice-to-have items

There you go. You, my readers (yes, both of you), can now hold me accountable if I fail to accomplish any of the work items I committed to do above.

To my fellow 30-dayers: good luck to us all. It will be fun!

EmailFacebookLinkedInGoogle+Twitter

30-day challenge: the road to TextUML Toolkit 1.0

I decided to join a group of fellow mISVers in the 30-day product challenge. Differently from most of the other entries, which will go from product idea to release in 30 days, the TextUML Toolkit has been in development for quite a while now, so my challenge will be to finally ship the first release of the product.

The challenge starts on June 1st. Watch this space for frequent updates as I make progress towards the elusive version 1.0.

Rafael

EmailFacebookLinkedInGoogle+Twitter