Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » UML2 » [Announce] OMG's UML 2.2 is ready - UML2 3.0.0 API has been updated.
[Announce] OMG's UML 2.2 is ready - UML2 3.0.0 API has been updated. [message #477788] Mon, 06 October 2008 20:54 Go to next message
james bruck is currently offline james bruckFriend
Messages: 1724
Registered: July 2009
Senior Member
Hi All,

The latest version of the UML superstructure specification is ready and in
keeping in lock step with the changes at the OMG, a new UML2 API is ready.

* The version of UML as defined by the OMG is UML 2.2.
* The latest version of the UML2 API is 3.0.0.

The next UML2 build will have updated API's and code that will handle
migration (similar to migration in the past).

Please have a look at :
http://www.eclipse.org/modeling/mdt/uml2/docs/guides/UML2_3. 0_Migration_Guide/guide.html
for more details.

As always, please post questions or concerns to this newsgroup.

Cheers,
- James.
Re: [Announce] OMG's UML 2.2 is ready - UML2 3.0.0 API has been updated. [message #477789 is a reply to message #477788] Tue, 07 October 2008 01:20 Go to previous messageGo to next message
Rafael Chaves is currently offline Rafael ChavesFriend
Messages: 362
Registered: July 2009
Senior Member
Great news, James. I really didn't see this coming. It is amazing how
tools adopting UML2 can always be so close to the spec (both in
conformance and timeliness). The migration guide is awesome, too,
excelent work!

Cheers,

Rafael

James Bruck wrote:
> Hi All,
>
> The latest version of the UML superstructure specification is ready and in
> keeping in lock step with the changes at the OMG, a new UML2 API is ready.
>
> * The version of UML as defined by the OMG is UML 2.2.
> * The latest version of the UML2 API is 3.0.0.
>
> The next UML2 build will have updated API's and code that will handle
> migration (similar to migration in the past).
>
> Please have a look at :
> http://www.eclipse.org/modeling/mdt/uml2/docs/guides/UML2_3. 0_Migration_Guide/guide.html
> for more details.
>
> As always, please post questions or concerns to this newsgroup.
>
> Cheers,
> - James.
>
>
Re: [Announce] OMG's UML 2.2 is ready - UML2 3.0.0 API has been updated. [message #477790 is a reply to message #477789] Tue, 07 October 2008 10:32 Go to previous messageGo to next message
Vlad Varnica is currently offline Vlad VarnicaFriend
Messages: 546
Registered: July 2009
Location: Milton Keynes - UK
Senior Member
James,

Will this next UML2 build be Ganymede compliant ?
Thanks for your migration guide documentation which will certainly be very
useful to our team :-)

Vlad,
Omondo
Re: [Announce] OMG's UML 2.2 is ready - UML2 3.0.0 API has been updated. [message #477791 is a reply to message #477790] Tue, 07 October 2008 18:29 Go to previous messageGo to next message
james bruck is currently offline james bruckFriend
Messages: 1724
Registered: July 2009
Senior Member
Hi Vlad,

There are no guarantees about Ganymede compliance with this latest build.
This version of UML2 also depends on the latest EMF and I cannot guarantee
EMF's compatibility.
However, it may very well be compliant since there are no special depdencies
on functionality not available in Ganymede (to my knowledge).

I believe that OCL and UML2Tools will be aligning to the latest UML during
the M3 milestone so you would have to consider if you use those components
and whether they would be Ganymede compatible.

The compliance with UML 2.2 is really intended as a Galileo feature.

By the way, if you are not interested in adopting the changes and updated
API, you could stick with the UML2 maintenance branch. I intend on
pushing other defect fixes to the maintenance branch as well as [head].


Cheers,
- James.


"Vlad Varnica" <varnica@omondo.com> wrote in message
news:54bfd2b6af8618766a12b4b6914775e5$1@www.eclipse.org...
> James,
>
> Will this next UML2 build be Ganymede compliant ?
> Thanks for your migration guide documentation which will certainly be very
> useful to our team :-)
>
> Vlad,
> Omondo
>
>
>
Re: [Announce] OMG's UML 2.2 is ready - UML2 3.0.0 API has been updated. [message #477793 is a reply to message #477788] Tue, 07 October 2008 21:49 Go to previous messageGo to next message
james bruck is currently offline james bruckFriend
Messages: 1724
Registered: July 2009
Senior Member
Hi All,

Some minor updates to the article have been made including links to the
individual OMG issues for easy access.

Cheers,
- James.


"James Bruck" <jbruck@ca.ibm.com> wrote in message
news:gcdtro$89l$1@build.eclipse.org...
> Hi All,
>
> The latest version of the UML superstructure specification is ready and in
> keeping in lock step with the changes at the OMG, a new UML2 API is ready.
>
> * The version of UML as defined by the OMG is UML 2.2.
> * The latest version of the UML2 API is 3.0.0.
>
> The next UML2 build will have updated API's and code that will handle
> migration (similar to migration in the past).
>
> Please have a look at :
> http://www.eclipse.org/modeling/mdt/uml2/docs/guides/UML2_3. 0_Migration_Guide/guide.html
> for more details.
>
> As always, please post questions or concerns to this newsgroup.
>
> Cheers,
> - James.
>
Re: [Announce] OMG's UML 2.2 is ready - UML2 3.0.0 API has been updated. [message #477895 is a reply to message #477788] Tue, 28 October 2008 17:57 Go to previous messageGo to next message
Tom Morris is currently offline Tom MorrisFriend
Messages: 89
Registered: July 2009
Member
It's great to have a detailed changes document like the Migration Guide.
Thanks for taking the time to produce it.

It's unfortunate that the OMG is continuing their tradition of
incompatible versions. Since they don't care about compatibility, it
makes the job of the Eclipse team extra difficult. The UML2 migration
document covers the details of migrating forward to the new API version,
but additional information on the general compatibility strategy for
the UML2 plugin would be really useful. Since UML/XMI is intended to
(eventually) be an interchange format, it exists, not in isolation, but
as part of an interdependent ecosystem of frameworks, components, and tools.

What assumptions/recommendations is the UML2 team making to applications
concerning backward compatibility? Is there a way for applications to
manage which models get upgraded other than by selecting which UML2
version they use? Can both versions coexist in a single application so
that users can be given the choice of writing UML 2.1.2 or UML 2.2? Do
users of applications built on the older API get a reasonable error
message if they try to open a file written by apps using the new API?
Are there other aspects of compatibility than API and UML/XMI format to
be concerned about (e.g. in-memory objects)?

Tom
Re: [Announce] OMG's UML 2.2 is ready - UML2 3.0.0 API has been updated. [message #477897 is a reply to message #477895] Wed, 29 October 2008 08:46 Go to previous messageGo to next message
Vlad Varnica is currently offline Vlad VarnicaFriend
Messages: 546
Registered: July 2009
Location: Milton Keynes - UK
Senior Member
Tom,

I would say that the problem is more related to Eclipse backward
compatibility and not really to EclipseUML2 model which provides a
solution.

I mean that why Eclipse 3.5 will not be backward compatible with Eclipse
3.4. Why Eclipse 3.4 is not backward compatible with Eclipse 3.3 etc...
Why EMF, GMF except migration guides are never backward compatible ?

Building an application on the top of GMF is more dangerous if you want to
upgrade from Eclipse 3.2 to the latest Eclipse than being in a minefield
:-)
Could you imagine that JDK 6 would not be backward compatible with JDK 5 ?
In the last 7 years Eclipse has changed from 2.0, to 2.1, 2.2, 3.0, 3.1,
3.2,3.3, 3.4 and soon 3.5 and never any backward compatibility ?
This is a non sense and thanks to the EclipseUML2 plugin for giving a
solution to this problem.
I don't see any reason why should I use Eclipse 3.5 in order to be
compatible with UML 2.2 ?
It should be backward compatible with any previous Eclipse build !!
I think that the Eclipse foundation should stop this non backward
compatibility because this is today the major Eclipse problem.
Omondo doesn't need new features, we just need that our users could
invest on the same Eclipse platform for many years but today this is not
possible !!

Vlad
Omondo
Re: [Announce] OMG's UML 2.2 is ready - UML2 3.0.0 API has been updated. [message #477901 is a reply to message #477897] Wed, 29 October 2008 10:54 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 31035
Registered: July 2009
Senior Member
Vlad,

Comments below.

Vlad Varnica wrote:
> Tom,
>
> I would say that the problem is more related to Eclipse backward
> compatibility and not really to EclipseUML2 model which provides a
> solution.
Personally I think you're confusing some topics here. Binary backward
compatible is when an application written against an older version of
Java, Eclipse, EMF, or UML2 also works without change or even
recompilation on a newer one.
>
> I mean that why Eclipse 3.5 will not be backward compatible with
> Eclipse 3.4.
It will be, but of course new things are added and applications that use
then new or changed things, will depend on that new version. I.e., Java
5.0 is backward compatible with Java 1.4, but that doesn't mean Java 5.0
applications can run in a 1.4 JRE...
> Why Eclipse 3.4 is not backward compatible with Eclipse 3.3 etc...
> Why EMF, GMF except migration guides are never backward compatible ?
As far as I know, applications written against EMF 1.0 would still run
with EMF 2.5.
>
> Building an application on the top of GMF is more dangerous if you
> want to upgrade from Eclipse 3.2 to the latest Eclipse than being in a
> minefield :-)
How is that relevant in the UML newsgroup?
> Could you imagine that JDK 6 would not be backward compatible with JDK
> 5 ?
No. But I also know an application using JDK 5 won't run on a 1.4 JRE.
> In the last 7 years Eclipse has changed from 2.0, to 2.1, 2.2, 3.0,
> 3.1, 3.2,3.3, 3.4 and soon 3.5 and never any backward compatibility ?
Eclipse has provided binary compatibility in each case.
> This is a non sense
I'm having trouble making sense of your rant.
> and thanks to the EclipseUML2 plugin for giving a solution to this
> problem.
I'm totally confused.
> I don't see any reason why should I use Eclipse 3.5 in order to be
> compatible with UML 2.2 ?
Because UML 2.2 is being developed as part of Galileo. That means it's
using Eclipse 3.5 and EMF 2.5. If EMF 2.5 uses any things new to
Eclipse 3.5 then it will require Eclipse 3.5. I don't have time to
build and test EMF 2.5 against Eclipse 3.4 or other old versions and I
intend to remove deprecations and use new capabilities as they become
available.
> It should be backward compatible with any previous Eclipse build !!
I could be made compatible, but that's different from it should be.
Generally the development process moves forward and as it does, new
features are added and of course when you use those new features, you
will depend on the latest version and will not run on an older vesion.
> I think that the Eclipse foundation should stop this non backward
> compatibility because this is today the major Eclipse problem.
This is like arguing that new features should not be added or if they
are, no one down stream should get to use them. Good luck convincing
anyone that's a sound strategy.
> Omondo doesn't need new features, we just need that our users could
> invest on the same Eclipse platform for many years but today this is
> not possible !!
Whatever your users invest ought to keep working on the latest Eclipse
platform. If the OMG decides to make incompatible changes, that's
perhaps a questionable strategy on their part. You might take it up
with them. If the UML project decides to keep up with those changes,
maybe even that's a questionable strategy, though it seems from comments
that the community appreciates UML2 staying current.

I think you're complaining about something that's an inevitable as
growing old... Software will always evolve in a forward direction...
>
> Vlad
> Omondo
>
>
>
Re: [Announce] OMG's UML 2.2 is ready - UML2 3.0.0 API has been updated. [message #477903 is a reply to message #477901] Wed, 29 October 2008 13:57 Go to previous messageGo to next message
Vlad Varnica is currently offline Vlad VarnicaFriend
Messages: 546
Registered: July 2009
Location: Milton Keynes - UK
Senior Member
Ed,

My comments below.


1. Personally I think you're confusing some topics here. Binary backward
compatible is when an application written against an older version of
Java, Eclipse, EMF, or UML2 also works without change or even
recompilation on a newer one.

Ed do you know how many Eclipse 3.3 plugins which are still working on
Eclipse 3.4 ? None of them are working therefore backward plugin
compatibility is not possible.

2. As far as I know, applications written against EMF 1.0 would still run
with EMF 2.5.

Ok, you are right for EMF but Eclipse plugin using EMF 1.0 are not
compatible with Eclipse 3.4. If we want to run EclipseUML on Eclipse 3.4
you need the latest EMF. Is that right ?

3. How is that relevant in the UML newsgroup?

Ok, I agree the point.

4. No. But I also know an application using JDK 5 won't run on a 1.4 JRE.
Ok

5. I'm having trouble making sense of your rant.

Imagine that you are a company and have invested two years just to collect
all needed plugins for your environment. I am sure that you would not be
very happy to loose many plugins just because you need to upgrade your
eclipse. This is why my customers are complaining.

6. I'm totally confused.
I think that many are confused because even if EclipseUML2 model is coming
from EMF, this plugin is more powerful than EMF for doing UML 2. What I
mean is that in UML 2.2 you can either decide to use EMF transformation to
generate xmi or directly use the XMI as your model :-)
This is a lot more powerful.

7. Because UML 2.2 is being developed as part of Galileo. That means it's
using Eclipse 3.5 and EMF 2.5. If EMF 2.5 uses any things new to Eclipse
3.5 then it will require Eclipse 3.5. I don't have time to build and test
EMF 2.5 against Eclipse 3.4 or other old versions and I intend to remove
deprecations and use new capabilities as they become available.

Why UML 2.2 should be develop as a part of galileo ?
It would have been not a big job to have upgraded the UML Ganymede.
btw we will upgrade it manually we don't need EMF for that :-)

8. I could be made compatible, but that's different from it should be.
Generally the development process moves forward and as it does, new
features are added and of course when you use those new features, you will
depend on the latest version and will not run on an older vesion.

ok, I agree but I would prefer extending existing Ganymede than always
looking for new features.

9. This is like arguing that new features should not be added or if they
are, no one down stream should get to use them. Good luck convincing
anyone that's a sound strategy.

No comment

10. Whatever your users invest ought to keep working on the latest Eclipse
platform. If the OMG decides to make incompatible changes, that's perhaps
a questionable strategy on their part. You might take it up with them.
If the UML project decides to keep up with those changes, maybe even
that's a questionable strategy, though it seems from comments that the
community appreciates UML2 staying current.

I think you're complaining about something that's an inevitable as growing
old... Software will always evolve in a forward direction...

The UML changes between 2.1 and 2.2 are not incompatible. This is a small
fix.
The incompatible change are EMF and new Gallileo with previous Eclipse 3.4
plugins.

Vlad,
Omondo
Re: [Announce] OMG's UML 2.2 is ready - UML2 3.0.0 API has been updated. [message #477906 is a reply to message #477897] Wed, 29 October 2008 18:57 Go to previous messageGo to next message
Tom Morris is currently offline Tom MorrisFriend
Messages: 89
Registered: July 2009
Member
Vlad Varnica wrote:

> I would say that the problem is more related to Eclipse backward
> compatibility and not really to EclipseUML2 model which provides a
> solution.

You are welcome to your opinion, but that's definitely NOT what I was
talking about. Plugins requiring the absolute latest versions of their
dependent problems certainly can create problems, but its a separate
problem.

What I was noticing as being either missing or inadequately explained is
the rest of the story regarding model compatibility for applications
which use different versions of the UML2 plugin. Requiring all tools in
the customer's toolchain to upgrade in lockstep is one solution, but it
turns out to be very difficult to achieve in practice and INCREDIBLY
unpopular with customers.

There really needs to be a compatibility story for version N and N+1 to
coexist for some period of time and be able to interoperate.

Tom
Re: [Announce] OMG's UML 2.2 is ready - UML2 3.0.0 API has been updated. [message #477909 is a reply to message #477906] Thu, 30 October 2008 08:59 Go to previous messageGo to next message
Vlad Varnica is currently offline Vlad VarnicaFriend
Messages: 546
Registered: July 2009
Location: Milton Keynes - UK
Senior Member
Tom,

I personally think that either you use EclipseUML2 model or you are not
fully OMG complaint wiht the latest specification.
The upgrade of tools models or export should be made by each vendor and
not by the Eclipse foundation.
I think that each customer before purchasing a UML tool should first check
if the model or at least the export is compliant with EclipseUML2.
Doing that way will be a lot more simple :-)

If you look for example at Omondo you will notice that you can just drag
and drop a RSA or Eclipse Modeling model element and immediately merge all
your models inside EclipseUML and EclipseUML2 model (e.g. UML2 plugin).
The latest OMG specification upgrade is almost the same as UML 2.1 except
few modifications. It will really not be a big job for each vendor to
upgrade.


Vlad,
Omondo
Re: [Announce] OMG's UML 2.2 is ready - UML2 3.0.0 API has been updated. [message #477910 is a reply to message #477903] Thu, 30 October 2008 12:18 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 31035
Registered: July 2009
Senior Member
Vlad,

Comments below.

Vlad Varnica wrote:
> Ed,
>
> My comments below.
>
>
> 1. Personally I think you're confusing some topics here. Binary
> backward compatible is when an application written against an older
> version of Java, Eclipse, EMF, or UML2 also works without change or
> even recompilation on a newer one.
>
> Ed do you know how many Eclipse 3.3 plugins which are still working on
> Eclipse 3.4 ? None of them are working therefore backward plugin
> compatibility is not possible.
All of them? As an experiment I installed Eclipse 3.4.1 and unzipped
emf-sdo-xsd-SDK-2.3.1.zip into it and mdt-uml2-SDK-2.1.0.zip It
definitely works. So what is the basis for your assertions?
>
> 2. As far as I know, applications written against EMF 1.0 would still
> run with EMF 2.5.
>
> Ok, you are right for EMF but Eclipse plugin using EMF 1.0 are not
> compatible with Eclipse 3.4.
I'm not sure that's true. Certainly Eclipse plugins for EMF 2.3 work
with Eclipse 3.4 as the above experiment reveals.
> If we want to run EclipseUML on Eclipse 3.4 you need the latest EMF.
> Is that right ?
Wrong. As I pointed out EMF 2.3 works on Eclipse 3.3 and eclipse 3.4
and ought to work on any Eclipse 3.x. where x > 3. That's the range we
declared in the MANIFEST.MF
>
> 3. How is that relevant in the UML newsgroup?
>
> Ok, I agree the point.
> 4. No. But I also know an application using JDK 5 won't run on a 1.4
> JRE.
> Ok
>
> 5. I'm having trouble making sense of your rant.
>
> Imagine that you are a company and have invested two years just to
> collect all needed plugins for your environment.
We have a release train at Eclipse so that all the needed plugins are
collected for you. Of course we can do nothing about things not at Eclipse.
> I am sure that you would not be very happy to loose many plugins just
> because you need to upgrade your eclipse. This is why my customers are
> complaining.
All your plugins should continue to work with the latest Eclipse. Of
course if UML itself makes binary incompatible changes and you want to
move to the latest version of that, you're entire stack of dependencies
will need a new version. So I can see that's frustrating and annoying,
but that's a different problem from this blanket complaint which asserts
that your old plugins stop working.
>
> 6. I'm totally confused.
> I think that many are confused because even if EclipseUML2 model is
> coming from EMF, this plugin is more powerful than EMF for doing UML
> 2. What I mean is that in UML 2.2 you can either decide to use EMF
> transformation to generate xmi or directly use the XMI as your model :-)
> This is a lot more powerful.
No, that wasn't it. That confuses me more. Perhaps now you're simply
equating EMF and Ecore. I'm not sure what the point is.
>
> 7. Because UML 2.2 is being developed as part of Galileo. That means
> it's using Eclipse 3.5 and EMF 2.5. If EMF 2.5 uses any things new to
> Eclipse 3.5 then it will require Eclipse 3.5. I don't have time to
> build and test EMF 2.5 against Eclipse 3.4 or other old versions and I
> intend to remove deprecations and use new capabilities as they become
> available.
>
> Why UML 2.2 should be develop as a part of galileo ? It would have
> been not a big job to have upgraded the UML Ganymede.
> btw we will upgrade it manually we don't need EMF for that :-)
I guess now I'm confusing the versions UML 3.0 is for Galileo. Replace
UML 2.2 with 3.0 in the above statement.
>
> 8. I could be made compatible, but that's different from it should
> be. Generally the development process moves forward and as it does,
> new features are added and of course when you use those new features,
> you will depend on the latest version and will not run on an older
> vesion.
>
> ok, I agree but I would prefer extending existing Ganymede than always
> looking for new features.
It's hard to make everyone happy. Some people prefer to keep up with
the standard.
>
> 9. This is like arguing that new features should not be added or if
> they are, no one down stream should get to use them. Good luck
> convincing anyone that's a sound strategy.
>
> No comment
>
> 10. Whatever your users invest ought to keep working on the latest
> Eclipse platform. If the OMG decides to make incompatible changes,
> that's perhaps a questionable strategy on their part. You might take
> it up with them. If the UML project decides to keep up with those
> changes, maybe even that's a questionable strategy, though it seems
> from comments that the community appreciates UML2 staying current.
>
> I think you're complaining about something that's an inevitable as
> growing old... Software will always evolve in a forward direction...
>
> The UML changes between 2.1 and 2.2 are not incompatible. This is a
> small fix.
> The incompatible change are EMF and new Gallileo with previous Eclipse
> 3.4 plugins.
I'm so totally confused.

I think you have a legitimate concern about UML making binary
incompatible changes. I don't think your concern will affect the
decision to do it though. So it seems to me you are free to keep using
UML 2.2 and you should expect it to work with Eclipse 3.5. Yet for some
reason you assert this won't work and then throw in a whole whack of
complaints around that...
>
> Vlad,
> Omondo
>
>
>
>
>
>
>
Re: [Announce] OMG's UML 2.2 is ready - UML2 3.0.0 API has been updated. [message #477912 is a reply to message #477909] Thu, 30 October 2008 13:56 Go to previous message
james bruck is currently offline james bruckFriend
Messages: 1724
Registered: July 2009
Senior Member
I might be able to shed some light on the history of interoperability
between versions N and N+1.

The very first migration work from UML2 1.x to UML2 2.0 was a very large
undertaking and we did investigate migrating backwards as well as forwards.
It was first thought that one metamodel mapping would suffice for both
migration directions but we soon discovered this was not the case. A
completely seperate resource handler that overrode the pre-save as opposed
to the post-load was created and experimented with - the code still exists
somewhere. In the end, we abandoned backward compatibility simply because
the requirement was dropped and no one from the opensource community asked
for that or volunteered any assistance for that matter.

From UML2 2.0.x to UML2 2.1, interoperability was supported. This was a
very minor task and the changes occurred in a maintanence branch so the
requirement was a bit more stringent or at least we felt so.

In the latest UML2 2.2.x to UML2 3.0.0 no requirement was expressed to
support backward compatibility, although it should be relatively straight
forward.


I would be interested in hearing how migration is working out for those
building on top of the UML2 API and if there is more that needs to be
addressed - what do your customers say? Forward migration was intended to
be relatively seamless.


In terms of Eclipse compatibility.... It would, in theory, be possible to
recompile the lastest UML2 API against older EMF dependencies and a Ganymede
version of Eclipse. The latest UML2 API does not use any new API not
already in Gany, to my knowldege anyway. Keep in mind however that other
related opensource components like OCL will be picking up the latest
versions of UML2. I would not recommend this course of action but you
may consider this if it is a priority for you.


Cheers,
- James.


"Vlad Varnica" <varnica@omondo.com> wrote in message
news:d6464fd41be6f16e62d3a8fb25a3f72d$1@www.eclipse.org...
> Tom,
>
> I personally think that either you use EclipseUML2 model or you are not
> fully OMG complaint wiht the latest specification.
> The upgrade of tools models or export should be made by each vendor and
> not by the Eclipse foundation. I think that each customer before
> purchasing a UML tool should first check if the model or at least the
> export is compliant with EclipseUML2. Doing that way will be a lot more
> simple :-)
>
> If you look for example at Omondo you will notice that you can just drag
> and drop a RSA or Eclipse Modeling model element and immediately merge all
> your models inside EclipseUML and EclipseUML2 model (e.g. UML2 plugin).
> The latest OMG specification upgrade is almost the same as UML 2.1 except
> few modifications. It will really not be a big job for each vendor to
> upgrade.
>
>
> Vlad,
> Omondo
>
Re: [Announce] OMG's UML 2.2 is ready - UML2 3.0.0 API has been updated. [message #626988 is a reply to message #477788] Tue, 07 October 2008 01:20 Go to previous message
Rafael Chaves is currently offline Rafael ChavesFriend
Messages: 362
Registered: July 2009
Senior Member
Great news, James. I really didn't see this coming. It is amazing how
tools adopting UML2 can always be so close to the spec (both in
conformance and timeliness). The migration guide is awesome, too,
excelent work!

Cheers,

Rafael

James Bruck wrote:
> Hi All,
>
> The latest version of the UML superstructure specification is ready and in
> keeping in lock step with the changes at the OMG, a new UML2 API is ready.
>
> * The version of UML as defined by the OMG is UML 2.2.
> * The latest version of the UML2 API is 3.0.0.
>
> The next UML2 build will have updated API's and code that will handle
> migration (similar to migration in the past).
>
> Please have a look at :
> http://www.eclipse.org/modeling/mdt/uml2/docs/guides/UML2_3. 0_Migration_Guide/guide.html
> for more details.
>
> As always, please post questions or concerns to this newsgroup.
>
> Cheers,
> - James.
>
>
Re: [Announce] OMG's UML 2.2 is ready - UML2 3.0.0 API has been updated. [message #626989 is a reply to message #477789] Tue, 07 October 2008 10:32 Go to previous message
Vlad Varnica is currently offline Vlad VarnicaFriend
Messages: 546
Registered: July 2009
Location: Milton Keynes - UK
Senior Member
James,

Will this next UML2 build be Ganymede compliant ?
Thanks for your migration guide documentation which will certainly be very
useful to our team :-)

Vlad,
Omondo
Re: [Announce] OMG's UML 2.2 is ready - UML2 3.0.0 API has been updated. [message #626990 is a reply to message #477790] Tue, 07 October 2008 18:29 Go to previous message
james bruck is currently offline james bruckFriend
Messages: 1724
Registered: July 2009
Senior Member
Hi Vlad,

There are no guarantees about Ganymede compliance with this latest build.
This version of UML2 also depends on the latest EMF and I cannot guarantee
EMF's compatibility.
However, it may very well be compliant since there are no special depdencies
on functionality not available in Ganymede (to my knowledge).

I believe that OCL and UML2Tools will be aligning to the latest UML during
the M3 milestone so you would have to consider if you use those components
and whether they would be Ganymede compatible.

The compliance with UML 2.2 is really intended as a Galileo feature.

By the way, if you are not interested in adopting the changes and updated
API, you could stick with the UML2 maintenance branch. I intend on
pushing other defect fixes to the maintenance branch as well as [head].


Cheers,
- James.


"Vlad Varnica" <varnica@omondo.com> wrote in message
news:54bfd2b6af8618766a12b4b6914775e5$1@www.eclipse.org...
> James,
>
> Will this next UML2 build be Ganymede compliant ?
> Thanks for your migration guide documentation which will certainly be very
> useful to our team :-)
>
> Vlad,
> Omondo
>
>
>
Re: [Announce] OMG's UML 2.2 is ready - UML2 3.0.0 API has been updated. [message #626992 is a reply to message #477788] Tue, 07 October 2008 21:49 Go to previous message
james bruck is currently offline james bruckFriend
Messages: 1724
Registered: July 2009
Senior Member
Hi All,

Some minor updates to the article have been made including links to the
individual OMG issues for easy access.

Cheers,
- James.


"James Bruck" <jbruck@ca.ibm.com> wrote in message
news:gcdtro$89l$1@build.eclipse.org...
> Hi All,
>
> The latest version of the UML superstructure specification is ready and in
> keeping in lock step with the changes at the OMG, a new UML2 API is ready.
>
> * The version of UML as defined by the OMG is UML 2.2.
> * The latest version of the UML2 API is 3.0.0.
>
> The next UML2 build will have updated API's and code that will handle
> migration (similar to migration in the past).
>
> Please have a look at :
> http://www.eclipse.org/modeling/mdt/uml2/docs/guides/UML2_3. 0_Migration_Guide/guide.html
> for more details.
>
> As always, please post questions or concerns to this newsgroup.
>
> Cheers,
> - James.
>
Re: [Announce] OMG's UML 2.2 is ready - UML2 3.0.0 API has been updated. [message #627104 is a reply to message #477788] Tue, 28 October 2008 17:57 Go to previous message
Tom Morris is currently offline Tom MorrisFriend
Messages: 89
Registered: July 2009
Member
It's great to have a detailed changes document like the Migration Guide.
Thanks for taking the time to produce it.

It's unfortunate that the OMG is continuing their tradition of
incompatible versions. Since they don't care about compatibility, it
makes the job of the Eclipse team extra difficult. The UML2 migration
document covers the details of migrating forward to the new API version,
but additional information on the general compatibility strategy for
the UML2 plugin would be really useful. Since UML/XMI is intended to
(eventually) be an interchange format, it exists, not in isolation, but
as part of an interdependent ecosystem of frameworks, components, and tools.

What assumptions/recommendations is the UML2 team making to applications
concerning backward compatibility? Is there a way for applications to
manage which models get upgraded other than by selecting which UML2
version they use? Can both versions coexist in a single application so
that users can be given the choice of writing UML 2.1.2 or UML 2.2? Do
users of applications built on the older API get a reasonable error
message if they try to open a file written by apps using the new API?
Are there other aspects of compatibility than API and UML/XMI format to
be concerned about (e.g. in-memory objects)?

Tom
Re: [Announce] OMG's UML 2.2 is ready - UML2 3.0.0 API has been updated. [message #627106 is a reply to message #477895] Wed, 29 October 2008 08:46 Go to previous message
Vlad Varnica is currently offline Vlad VarnicaFriend
Messages: 546
Registered: July 2009
Location: Milton Keynes - UK
Senior Member
Tom,

I would say that the problem is more related to Eclipse backward
compatibility and not really to EclipseUML2 model which provides a
solution.

I mean that why Eclipse 3.5 will not be backward compatible with Eclipse
3.4. Why Eclipse 3.4 is not backward compatible with Eclipse 3.3 etc...
Why EMF, GMF except migration guides are never backward compatible ?

Building an application on the top of GMF is more dangerous if you want to
upgrade from Eclipse 3.2 to the latest Eclipse than being in a minefield
:-)
Could you imagine that JDK 6 would not be backward compatible with JDK 5 ?
In the last 7 years Eclipse has changed from 2.0, to 2.1, 2.2, 3.0, 3.1,
3.2,3.3, 3.4 and soon 3.5 and never any backward compatibility ?
This is a non sense and thanks to the EclipseUML2 plugin for giving a
solution to this problem.
I don't see any reason why should I use Eclipse 3.5 in order to be
compatible with UML 2.2 ?
It should be backward compatible with any previous Eclipse build !!
I think that the Eclipse foundation should stop this non backward
compatibility because this is today the major Eclipse problem.
Omondo doesn't need new features, we just need that our users could
invest on the same Eclipse platform for many years but today this is not
possible !!

Vlad
Omondo
Re: [Announce] OMG's UML 2.2 is ready - UML2 3.0.0 API has been updated. [message #627110 is a reply to message #477897] Wed, 29 October 2008 10:54 Go to previous message
Ed Merks is currently offline Ed MerksFriend
Messages: 31035
Registered: July 2009
Senior Member
Vlad,

Comments below.

Vlad Varnica wrote:
> Tom,
>
> I would say that the problem is more related to Eclipse backward
> compatibility and not really to EclipseUML2 model which provides a
> solution.
Personally I think you're confusing some topics here. Binary backward
compatible is when an application written against an older version of
Java, Eclipse, EMF, or UML2 also works without change or even
recompilation on a newer one.
>
> I mean that why Eclipse 3.5 will not be backward compatible with
> Eclipse 3.4.
It will be, but of course new things are added and applications that use
then new or changed things, will depend on that new version. I.e., Java
5.0 is backward compatible with Java 1.4, but that doesn't mean Java 5.0
applications can run in a 1.4 JRE...
> Why Eclipse 3.4 is not backward compatible with Eclipse 3.3 etc...
> Why EMF, GMF except migration guides are never backward compatible ?
As far as I know, applications written against EMF 1.0 would still run
with EMF 2.5.
>
> Building an application on the top of GMF is more dangerous if you
> want to upgrade from Eclipse 3.2 to the latest Eclipse than being in a
> minefield :-)
How is that relevant in the UML newsgroup?
> Could you imagine that JDK 6 would not be backward compatible with JDK
> 5 ?
No. But I also know an application using JDK 5 won't run on a 1.4 JRE.
> In the last 7 years Eclipse has changed from 2.0, to 2.1, 2.2, 3.0,
> 3.1, 3.2,3.3, 3.4 and soon 3.5 and never any backward compatibility ?
Eclipse has provided binary compatibility in each case.
> This is a non sense
I'm having trouble making sense of your rant.
> and thanks to the EclipseUML2 plugin for giving a solution to this
> problem.
I'm totally confused.
> I don't see any reason why should I use Eclipse 3.5 in order to be
> compatible with UML 2.2 ?
Because UML 2.2 is being developed as part of Galileo. That means it's
using Eclipse 3.5 and EMF 2.5. If EMF 2.5 uses any things new to
Eclipse 3.5 then it will require Eclipse 3.5. I don't have time to
build and test EMF 2.5 against Eclipse 3.4 or other old versions and I
intend to remove deprecations and use new capabilities as they become
available.
> It should be backward compatible with any previous Eclipse build !!
I could be made compatible, but that's different from it should be.
Generally the development process moves forward and as it does, new
features are added and of course when you use those new features, you
will depend on the latest version and will not run on an older vesion.
> I think that the Eclipse foundation should stop this non backward
> compatibility because this is today the major Eclipse problem.
This is like arguing that new features should not be added or if they
are, no one down stream should get to use them. Good luck convincing
anyone that's a sound strategy.
> Omondo doesn't need new features, we just need that our users could
> invest on the same Eclipse platform for many years but today this is
> not possible !!
Whatever your users invest ought to keep working on the latest Eclipse
platform. If the OMG decides to make incompatible changes, that's
perhaps a questionable strategy on their part. You might take it up
with them. If the UML project decides to keep up with those changes,
maybe even that's a questionable strategy, though it seems from comments
that the community appreciates UML2 staying current.

I think you're complaining about something that's an inevitable as
growing old... Software will always evolve in a forward direction...
>
> Vlad
> Omondo
>
>
>
Re: [Announce] OMG's UML 2.2 is ready - UML2 3.0.0 API has been updated. [message #627112 is a reply to message #477901] Wed, 29 October 2008 13:57 Go to previous message
Vlad Varnica is currently offline Vlad VarnicaFriend
Messages: 546
Registered: July 2009
Location: Milton Keynes - UK
Senior Member
Ed,

My comments below.


1. Personally I think you're confusing some topics here. Binary backward
compatible is when an application written against an older version of
Java, Eclipse, EMF, or UML2 also works without change or even
recompilation on a newer one.

Ed do you know how many Eclipse 3.3 plugins which are still working on
Eclipse 3.4 ? None of them are working therefore backward plugin
compatibility is not possible.

2. As far as I know, applications written against EMF 1.0 would still run
with EMF 2.5.

Ok, you are right for EMF but Eclipse plugin using EMF 1.0 are not
compatible with Eclipse 3.4. If we want to run EclipseUML on Eclipse 3.4
you need the latest EMF. Is that right ?

3. How is that relevant in the UML newsgroup?

Ok, I agree the point.

4. No. But I also know an application using JDK 5 won't run on a 1.4 JRE.
Ok

5. I'm having trouble making sense of your rant.

Imagine that you are a company and have invested two years just to collect
all needed plugins for your environment. I am sure that you would not be
very happy to loose many plugins just because you need to upgrade your
eclipse. This is why my customers are complaining.

6. I'm totally confused.
I think that many are confused because even if EclipseUML2 model is coming
from EMF, this plugin is more powerful than EMF for doing UML 2. What I
mean is that in UML 2.2 you can either decide to use EMF transformation to
generate xmi or directly use the XMI as your model :-)
This is a lot more powerful.

7. Because UML 2.2 is being developed as part of Galileo. That means it's
using Eclipse 3.5 and EMF 2.5. If EMF 2.5 uses any things new to Eclipse
3.5 then it will require Eclipse 3.5. I don't have time to build and test
EMF 2.5 against Eclipse 3.4 or other old versions and I intend to remove
deprecations and use new capabilities as they become available.

Why UML 2.2 should be develop as a part of galileo ?
It would have been not a big job to have upgraded the UML Ganymede.
btw we will upgrade it manually we don't need EMF for that :-)

8. I could be made compatible, but that's different from it should be.
Generally the development process moves forward and as it does, new
features are added and of course when you use those new features, you will
depend on the latest version and will not run on an older vesion.

ok, I agree but I would prefer extending existing Ganymede than always
looking for new features.

9. This is like arguing that new features should not be added or if they
are, no one down stream should get to use them. Good luck convincing
anyone that's a sound strategy.

No comment

10. Whatever your users invest ought to keep working on the latest Eclipse
platform. If the OMG decides to make incompatible changes, that's perhaps
a questionable strategy on their part. You might take it up with them.
If the UML project decides to keep up with those changes, maybe even
that's a questionable strategy, though it seems from comments that the
community appreciates UML2 staying current.

I think you're complaining about something that's an inevitable as growing
old... Software will always evolve in a forward direction...

The UML changes between 2.1 and 2.2 are not incompatible. This is a small
fix.
The incompatible change are EMF and new Gallileo with previous Eclipse 3.4
plugins.

Vlad,
Omondo
Re: [Announce] OMG's UML 2.2 is ready - UML2 3.0.0 API has been updated. [message #627115 is a reply to message #477897] Wed, 29 October 2008 18:57 Go to previous message
Tom Morris is currently offline Tom MorrisFriend
Messages: 89
Registered: July 2009
Member
Vlad Varnica wrote:

> I would say that the problem is more related to Eclipse backward
> compatibility and not really to EclipseUML2 model which provides a
> solution.

You are welcome to your opinion, but that's definitely NOT what I was
talking about. Plugins requiring the absolute latest versions of their
dependent problems certainly can create problems, but its a separate
problem.

What I was noticing as being either missing or inadequately explained is
the rest of the story regarding model compatibility for applications
which use different versions of the UML2 plugin. Requiring all tools in
the customer's toolchain to upgrade in lockstep is one solution, but it
turns out to be very difficult to achieve in practice and INCREDIBLY
unpopular with customers.

There really needs to be a compatibility story for version N and N+1 to
coexist for some period of time and be able to interoperate.

Tom
Re: [Announce] OMG's UML 2.2 is ready - UML2 3.0.0 API has been updated. [message #627118 is a reply to message #477906] Thu, 30 October 2008 08:59 Go to previous message
Vlad Varnica is currently offline Vlad VarnicaFriend
Messages: 546
Registered: July 2009
Location: Milton Keynes - UK
Senior Member
Tom,

I personally think that either you use EclipseUML2 model or you are not
fully OMG complaint wiht the latest specification.
The upgrade of tools models or export should be made by each vendor and
not by the Eclipse foundation.
I think that each customer before purchasing a UML tool should first check
if the model or at least the export is compliant with EclipseUML2.
Doing that way will be a lot more simple :-)

If you look for example at Omondo you will notice that you can just drag
and drop a RSA or Eclipse Modeling model element and immediately merge all
your models inside EclipseUML and EclipseUML2 model (e.g. UML2 plugin).
The latest OMG specification upgrade is almost the same as UML 2.1 except
few modifications. It will really not be a big job for each vendor to
upgrade.


Vlad,
Omondo
Re: [Announce] OMG's UML 2.2 is ready - UML2 3.0.0 API has been updated. [message #627119 is a reply to message #477903] Thu, 30 October 2008 12:18 Go to previous message
Ed Merks is currently offline Ed MerksFriend
Messages: 31035
Registered: July 2009
Senior Member
Vlad,

Comments below.

Vlad Varnica wrote:
> Ed,
>
> My comments below.
>
>
> 1. Personally I think you're confusing some topics here. Binary
> backward compatible is when an application written against an older
> version of Java, Eclipse, EMF, or UML2 also works without change or
> even recompilation on a newer one.
>
> Ed do you know how many Eclipse 3.3 plugins which are still working on
> Eclipse 3.4 ? None of them are working therefore backward plugin
> compatibility is not possible.
All of them? As an experiment I installed Eclipse 3.4.1 and unzipped
emf-sdo-xsd-SDK-2.3.1.zip into it and mdt-uml2-SDK-2.1.0.zip It
definitely works. So what is the basis for your assertions?
>
> 2. As far as I know, applications written against EMF 1.0 would still
> run with EMF 2.5.
>
> Ok, you are right for EMF but Eclipse plugin using EMF 1.0 are not
> compatible with Eclipse 3.4.
I'm not sure that's true. Certainly Eclipse plugins for EMF 2.3 work
with Eclipse 3.4 as the above experiment reveals.
> If we want to run EclipseUML on Eclipse 3.4 you need the latest EMF.
> Is that right ?
Wrong. As I pointed out EMF 2.3 works on Eclipse 3.3 and eclipse 3.4
and ought to work on any Eclipse 3.x. where x > 3. That's the range we
declared in the MANIFEST.MF
>
> 3. How is that relevant in the UML newsgroup?
>
> Ok, I agree the point.
> 4. No. But I also know an application using JDK 5 won't run on a 1.4
> JRE.
> Ok
>
> 5. I'm having trouble making sense of your rant.
>
> Imagine that you are a company and have invested two years just to
> collect all needed plugins for your environment.
We have a release train at Eclipse so that all the needed plugins are
collected for you. Of course we can do nothing about things not at Eclipse.
> I am sure that you would not be very happy to loose many plugins just
> because you need to upgrade your eclipse. This is why my customers are
> complaining.
All your plugins should continue to work with the latest Eclipse. Of
course if UML itself makes binary incompatible changes and you want to
move to the latest version of that, you're entire stack of dependencies
will need a new version. So I can see that's frustrating and annoying,
but that's a different problem from this blanket complaint which asserts
that your old plugins stop working.
>
> 6. I'm totally confused.
> I think that many are confused because even if EclipseUML2 model is
> coming from EMF, this plugin is more powerful than EMF for doing UML
> 2. What I mean is that in UML 2.2 you can either decide to use EMF
> transformation to generate xmi or directly use the XMI as your model :-)
> This is a lot more powerful.
No, that wasn't it. That confuses me more. Perhaps now you're simply
equating EMF and Ecore. I'm not sure what the point is.
>
> 7. Because UML 2.2 is being developed as part of Galileo. That means
> it's using Eclipse 3.5 and EMF 2.5. If EMF 2.5 uses any things new to
> Eclipse 3.5 then it will require Eclipse 3.5. I don't have time to
> build and test EMF 2.5 against Eclipse 3.4 or other old versions and I
> intend to remove deprecations and use new capabilities as they become
> available.
>
> Why UML 2.2 should be develop as a part of galileo ? It would have
> been not a big job to have upgraded the UML Ganymede.
> btw we will upgrade it manually we don't need EMF for that :-)
I guess now I'm confusing the versions UML 3.0 is for Galileo. Replace
UML 2.2 with 3.0 in the above statement.
>
> 8. I could be made compatible, but that's different from it should
> be. Generally the development process moves forward and as it does,
> new features are added and of course when you use those new features,
> you will depend on the latest version and will not run on an older
> vesion.
>
> ok, I agree but I would prefer extending existing Ganymede than always
> looking for new features.
It's hard to make everyone happy. Some people prefer to keep up with
the standard.
>
> 9. This is like arguing that new features should not be added or if
> they are, no one down stream should get to use them. Good luck
> convincing anyone that's a sound strategy.
>
> No comment
>
> 10. Whatever your users invest ought to keep working on the latest
> Eclipse platform. If the OMG decides to make incompatible changes,
> that's perhaps a questionable strategy on their part. You might take
> it up with them. If the UML project decides to keep up with those
> changes, maybe even that's a questionable strategy, though it seems
> from comments that the community appreciates UML2 staying current.
>
> I think you're complaining about something that's an inevitable as
> growing old... Software will always evolve in a forward direction...
>
> The UML changes between 2.1 and 2.2 are not incompatible. This is a
> small fix.
> The incompatible change are EMF and new Gallileo with previous Eclipse
> 3.4 plugins.
I'm so totally confused.

I think you have a legitimate concern about UML making binary
incompatible changes. I don't think your concern will affect the
decision to do it though. So it seems to me you are free to keep using
UML 2.2 and you should expect it to work with Eclipse 3.5. Yet for some
reason you assert this won't work and then throw in a whole whack of
complaints around that...
>
> Vlad,
> Omondo
>
>
>
>
>
>
>
Re: [Announce] OMG's UML 2.2 is ready - UML2 3.0.0 API has been updated. [message #627121 is a reply to message #477909] Thu, 30 October 2008 13:56 Go to previous message
james bruck is currently offline james bruckFriend
Messages: 1724
Registered: July 2009
Senior Member
I might be able to shed some light on the history of interoperability
between versions N and N+1.

The very first migration work from UML2 1.x to UML2 2.0 was a very large
undertaking and we did investigate migrating backwards as well as forwards.
It was first thought that one metamodel mapping would suffice for both
migration directions but we soon discovered this was not the case. A
completely seperate resource handler that overrode the pre-save as opposed
to the post-load was created and experimented with - the code still exists
somewhere. In the end, we abandoned backward compatibility simply because
the requirement was dropped and no one from the opensource community asked
for that or volunteered any assistance for that matter.

From UML2 2.0.x to UML2 2.1, interoperability was supported. This was a
very minor task and the changes occurred in a maintanence branch so the
requirement was a bit more stringent or at least we felt so.

In the latest UML2 2.2.x to UML2 3.0.0 no requirement was expressed to
support backward compatibility, although it should be relatively straight
forward.


I would be interested in hearing how migration is working out for those
building on top of the UML2 API and if there is more that needs to be
addressed - what do your customers say? Forward migration was intended to
be relatively seamless.


In terms of Eclipse compatibility.... It would, in theory, be possible to
recompile the lastest UML2 API against older EMF dependencies and a Ganymede
version of Eclipse. The latest UML2 API does not use any new API not
already in Gany, to my knowldege anyway. Keep in mind however that other
related opensource components like OCL will be picking up the latest
versions of UML2. I would not recommend this course of action but you
may consider this if it is a priority for you.


Cheers,
- James.


"Vlad Varnica" <varnica@omondo.com> wrote in message
news:d6464fd41be6f16e62d3a8fb25a3f72d$1@www.eclipse.org...
> Tom,
>
> I personally think that either you use EclipseUML2 model or you are not
> fully OMG complaint wiht the latest specification.
> The upgrade of tools models or export should be made by each vendor and
> not by the Eclipse foundation. I think that each customer before
> purchasing a UML tool should first check if the model or at least the
> export is compliant with EclipseUML2. Doing that way will be a lot more
> simple :-)
>
> If you look for example at Omondo you will notice that you can just drag
> and drop a RSA or Eclipse Modeling model element and immediately merge all
> your models inside EclipseUML and EclipseUML2 model (e.g. UML2 plugin).
> The latest OMG specification upgrade is almost the same as UML 2.1 except
> few modifications. It will really not be a big job for each vendor to
> upgrade.
>
>
> Vlad,
> Omondo
>
Previous Topic:Profile OCL validation
Next Topic:Tags for Stereotype don't appear
Goto Forum:
  


Current Time: Mon Apr 06 18:32:50 GMT 2020

Powered by FUDForum. Page generated in 0.19565 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top