RE: [argouml-dev] argouml-emf

Markus said:

> just wanted to let you know that I will very slowly, time permitting,
> start developing the argouml-emf plugin. 

The last time this discussion came up I was too busy to write up a detailed
response to your questions, but since I've got a little more time now, let
me try to address the issue from a couple of points of view.

First, from a terminology point of view, since "EMF" addresses such a wide
range of functionality, I think it's more useful to talk about specific
components within the framework.  Ecore is the core metamodel which lines up
at more or less the same level as OMG's MOF.  There already exists
argo2ecore, but I think that basically converts a M1 UML model into an M2
(or M1.5) Ecore model.  A better target would be a version of the Eclipse
UML2 plugin which implements UML 2.1.1 (now that UML 2.1 is no longer going
to be released).

I can see three broad implementation strategies for targetting the Eclipse
UML2 plugin:

1. Create a new ArgoUML Model subsystem implementation based on the Eclipse
EMF/UML2 code and continue to use the existing ArgoUML application
framework.

2. Break ArgoUML into a set of Eclipse plugins and make use of the Eclipse
UML2 plugin in the context of the Eclipse application framework.  (This is
the approach that we've started with ArgoEclipse).

3. Start from scratch to implement UML 2.x support in Eclipse based on the
Graphical Modeling Framework (GMF) and incorporate any unique ArgoUML
value-added components which aren't already available in the Eclipse
environment.  This is the approach being taken by "the long-term driving
strength behind the open source project ArgoUML," Markus Boger.
http://business.newsforge.com/newsvac/06/10/20/1256216.shtml

As I've stated several times, I think maintaining the existing ArgoUML
application framework is a waste of time, so I'm really only interested in
Eclipse based solutions (#2 or #3).  I think the main questions really come
down to how much unique value there is in ArgoUML that we would want to
preserve and whether it would be easier to use higher level building blocks
like GMF or to gradually refactor the existing code.

One general long term concern that I have about depending EMF for
implementations of OMG standards is that IBM/Rational/Eclipse tightly
controls EMF and has indicated that they have absolutely *no* interest in
implementing support for MOF 2.x or JMI 2.  They are going to continue to
push Ecore instead of OMG standards.  For UML 2.1.1 there is a solution,
but, the last time I checked, it depended on an IBM engineer taking the OMG
UML metamodel into a locked lab, running it through some proprietary IBM
tools and then committing the resultant source modules.  Clearly this
process can't be reproduced by anyone else, so support of other MOF 2.x
based standards (SysML?) would depend entirely on IBM's goodwill and desire
to let this happen.  

I talked to OMG at EclipseWorld and they don't see the lack of an API (a la
JMI) as a problem that they need to address and, as has been discussed in
the past, Sun has shown no interest in updating JMI, so it may be that
EMF/Ecore is the only game in town, but we should choose it with open eyes
about the consequences.  The Rational business represents billions of
dollars a year to IBM and they will make it as difficult as possible for
others to play in this space.  IBM employees control all the key pieces of
EMF.

BTW, I wasn't aware of the whole UML 2.1.1 fiasco until I went back to
update myself on the current state of affairs.  You can find pointers to the
changes incorporated in UML 2.1.1 in this Eclipse UML2 issue
https://bugs.eclipse.org/bugs/show_bug.cgi?id=161119  I'm not sure this has
yet been fully resolved by the OMG since they seem to have been stilling
dealing with it over the last couple of weeks.

> ... after that I will probably need to fork
> argouml, or we need to have another strategy how we can work with the 
> UML 2.0 metamodel which emf/uml2 require and the UML 1.4 that 
> netbeans/mdr requires.

I think it should be possible to make things conditional on the metamodel if
it ends up being useful.  We did this to a limited degree for the UML 1.3 to
UML 1.4 migration without too much problem.

One thing we probably need to make a decision on is how long we want to
support UML 1.4.  I think most of the interesting stuff is going to be
happening with UML 2.x, but I saw a request recently from someone who wanted
us to support writing UML 1.3 for interchange with older tools, so clearly
some people are slower to upgrade than others.

Tom