Home » Modeling » UML2 » [Announce] OMG's UML 2.2 is ready - UML2 3.0.0 API has been updated.
| | | | | |
| 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   |
 Vlad Varnica
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 |
Ed Merks
Messages: 33137
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
>
>
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| 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 |
Vlad Varnica
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 #477910 is a reply to message #477903] |
Thu, 30 October 2008 12:18 |
Ed Merks
Messages: 33137
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
>
>
>
>
>
>
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| 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 |
james bruck
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 #627106 is a reply to message #477895] |
Wed, 29 October 2008 08:46 |
Vlad Varnica
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 |
Ed Merks
Messages: 33137
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
>
>
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| 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 |
Vlad Varnica
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 #627119 is a reply to message #477903] |
Thu, 30 October 2008 12:18 |
Ed Merks
Messages: 33137
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
>
>
>
>
>
>
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| 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 |
james bruck
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
>
|
|
|
Goto Forum:
Current Time: Fri Apr 19 21:11:53 GMT 2024
Powered by FUDForum. Page generated in 0.05018 seconds |
] 
Search
Help
Register
Login
Home
