Modelling by diagramming

Whenever i think of modelling, by which today i mean creating a logical model for our business, i always have a diagrams ahead my eyes. Those on sheet of paper or in cool UML editor. After discovering EMF some time ago i was a bit confused that all the tutorials, help and docs gave examples with nice yellow diagrams from Rose, but trying out anything required actually to dig into XML or stack of tree views in the ecore editor. This tools are not bad, specially because of fact that now have choice to use diagram editors. Yes, not editor, but editors - two!

After adding GMF to your Eclipse, new wizard appears in "File -> New..." as well as in .ecore file context menu. It initializes ecore diagram out of normal .ecore and lets you drag classes around, make connections, and all you were always dreaming about. Thanks to that, diagram editor and ecore editor can be used simultaniously, as they work on the same file and changes are immediately visible in both of them.



So that is EMF model diagram editor. Despite the fact, we've got EMF inside, it's still very nice class diagram editor, maybe more conformant with XSD than UML, but enough for most cases.

Another diagramming equipment comes bundled in UML2Tools. This feature grows on UML2 model implemented in EMF, a part of Eclipse Modelling top-project. Besides classes, it supports creating activity, component, profile and state machine diagrams. We're still waiting for first release, but there is already a loot to look at:



What i was most surprised about, is that this diagrams, or rather designed UML model, can be also used to build ecore (see the image below). Unfortunately right now, conversion is one-way only, which finally makes you end up with ecore model, uml model and uml diagram. Good news is that, first UML2Tools release is planned for June.

"Revert to Base" - a few things about

In response to bug 106876 new feature has been introduced to eclipse: in the 7th milestone of 3.3 version an action "Revert to Base" appeared in the context menu Team, as shown below:


For every future commiter it is pretty important action. Why?

Let me remind you common cycle of non-commiter contributor work:
1. Pick up a bug
2. Create a patch
3a. Wait for feedback
3b. Go to 1.

Please notice, that point 3b requires switching to head and abandoning previously made changes - because we are writing new patch for another issue (but due to specialization, it may be the same work area).

And now we have quite simple solution - one click and we can restore last loaded version of our software. Always the newest soft will be loaded. Yes, this is almost the same like Team->Replace With->Another Branch or Version -> BASE, but how much less clicking ;).

A few words about sticky tags for those of you, that do not know them: Sticky tags are some ancient invention, I do not see any usage for them. But they can block CVS operations until you removed them, f.e. you cannot commit a resource marked as sticky until you remove that tag or create another branch. And the worst feature of sticky tags - they are set by server in response to certain operations - like f.e. replace with BASE.

And good news for you: in Eclipse 3.3m7 sticky tags are ignored. Whenever the server tries to set them, we gently write current tag to sync bytes. And no sticky nightmare will meet us :).


Sadly, the Revert to Base action has some limitations due to CVS limitations. Deleted files are not restored when replacing with BASE tag. Therefore it is necessary to have local history enabled, at least for one entry. Then the Revert to Base operation is able to restore deleted file and perform update/replacement on it.

I hope this action will help you all in process of eclipse bugfixing. And not only this.

Regards,
Chris