[uml] Accommodate MDT/UML2 major version change

[eclipse-ocl-bot]

| --- | --- | | Bugzilla Link | 424476 | | Status | CLOSED FIXED | | Importance | P3 normal | | Reported | Dec 19, 2013 12:36 EDT | | Modified | May 25, 2015 17:19 EDT | | Reporter | Ed Willink |

Description

MDT/UML2 is going to 5.0 so ocl.uml which export UML must have a major version too, since the UML classes are part of the templated API.

The pivot currently re-exports uml.resources, but this export can be re-tracted. UML is used internally as part of the UML file to Pivot conversion but not as part of the true API.

[eclipse-ocl-bot]

By Ed Willink on Jan 15, 2014 17:44

Eclipse UML2 has released a 5.0 I-build and I've made changes locally to accommodate the major version change. Apart from a probably irrelevant strange binary class version problem there was no problem. Only MANIFEST.MF changes.

Since we are only using the class subset of UML we really aren't seeing the subtle changes, so I see no real reason for a major version change.

I think we can do a minor version change (not a +0.0.100 change) widening the internal dependency bounds to 4.0 to 6.0 and removing the re-export.

This breaks source compatibility since downstream users will have to add their own UML imports, but that would have happened anyway since we want to remove our re-exports.

I think binary compatibility is preserved so that this will allow Eclipse OCL for Luna to be installed on Juno using whichever Eclipse UML2 is available.

We are not changing our API and not exporting a changed API, so no major change seems to be legal according to http://wiki.eclipse.org/Version_Numbering#When_to_change_the_major_segment.

[eclipse-ocl-bot]

By Kenn Hussey on Jan 15, 2014 19:16

(In reply to Ed Willink from comment #1)

Note that none of the API-affecting changes for 5.0 have been made in UML2 yet, so it may be too early to decide whether to bump the version of OCL. An an example of some of the API-affecting changes planned for UML2 5.0, the UML metamodel API is going to experience breaking changes (e.g., removal of operations and constraints) and the Standard profile is being re-unified (making the L2 and L3 profiles obsolete.

[eclipse-ocl-bot]

By Kenn Hussey on Jan 15, 2014 20:45

FYI, there's a 'uml25' branch in the UML2 git repository which you can monitor if you'd like to "play along at home"...

[eclipse-ocl-bot]

By Ed Willink on Jan 16, 2014 03:37

(In reply to Kenn Hussey from comment #3)

FYI, there's a 'uml25' branch in the UML2 git repository which you can monitor if you'd like to "play along at home"...

Ah, new toys and two JUnit failures to investigate.

Obviously any changes that affect Eclipse OCL will have to be accommodated by us. So we have to have the old and new code anyway, it's just a question of whether we have a compatibility switch between the two.

Downstream, e.g. QVTo, the Ecore view of UML seems adequate, so QVTo has no UML dependencies. I think this demonstrates that the complexities of UML are localised to Eclipse OCL and so we can hide them behind our own API.

[eclipse-ocl-bot]

By Ed Willink on Jan 16, 2014 07:45

Once branch edw/424476 is installed the latest UML2 I-build can be installed without needing to upgrade anything else that I normally use.

The branch just does a minor version upgrade with respect to Kepler and broadens the UML2 bounds to 4.0 to 6.0.

Projects such as EMFq and QVTo see only a minor version change from OCL, so we should avoid relenmg hassle for others.

If UML2 evolution for UML 2.5 introduces changes that impact on our API (e.g. renaming Class as Klass) then we will have to have a major version change. I'm hopeful everything that matters will be behind the scenes.

Please review.

[eclipse-ocl-bot]

By Adolfo Sanchez-Barbudo Herrera on Jan 17, 2014 06:21

Hi

Adjusting dependencies is always delicate. Being strict, no re-exporting a dependency anymore should merit a major change increase. Basically, because it's a change which breaks clients using the re-exported classes. Clients shouldn't expect to be broken with a minor version increase.

I understand the convenience of removing the re-export, but again, if we want to be rigorous, a major version increase is required for that specific plugins to correct the unnecessary re-export (and transitively, the depending plugins which re-export them, as well as the including features).

Another interesting point of the policy is the following:

"Exporting a version range that spans multiple major versions of a plug-in is not recommended, because it forces downstream plug-ins to support versions with arbitrary breaking changes between them. Therefore, the most common change to a version range will be increasing the minor or service segment of one of the bounds, or incrementing both bounds up to a range within the next major version."

Unfortunately, if uml.resource changed to a 5.0 plugin version, it seems hard to scape from increasing the major version increase for those plugins re-exporting uml.resource. Then, we can remove the unnecessary re-exports which have caused this hassle. For those plugins still requiring to export uml.resourse, they will need a 5.0 to 6.0 range.

[Time to strip the uml feature out from the core one ?. Otherwise, non-UML Luna OCL features couldn't be installed in Juno and previous releases]

Regards,\ Adolfo.

[eclipse-ocl-bot]

By Ed Willink on Jan 17, 2014 06:34

You missed a critical point. We stop re-exporting any UML plugins, so this definitely solves the multi-version re-export query.

Not re-exporting is an API change but it's not our API change so I think it's ok, although very borderline. Source consumers are broken, but they can change. Binary consumers don't use the re-export so are not affected, I hope.

[eclipse-ocl-bot]

By Adolfo Sanchez-Barbudo Herrera on Jan 17, 2014 07:45

Hi Ed,

Being rigorous, if we remove a re-export, I see no other option than bumping up the major version. Fortunately, your proposal of removing the re-export and keeping a [4.0,6.0) version range, sounds very convenient to have the Luna OCL components installable in previous Eclipse versions.

I think it could be beneficial asking for a third point of view, to double check we are taking the right direction.

There is some rationale about these conclusions below.

Cheers,\ Adolfo.\ ----- TL;DR -----\ (In reply to Ed Willink from comment #7)

You missed a critical point. We stop re-exporting any UML plugins, so this definitely solves the multi-version re-export query.

Sorry, I didn't want to check every depencency on UML in the branch until agreement. As commented, the dependency [5.0-6.0) would only be required if the re-export were maintained. If every re-export is removed your proposal sounds very convinient. In any case, this doesn't allow us not having to increase the own plug-in major version.

Not re-exporting is an API change but it's not our API change so I think it's ok, although very borderline. Source consumers are broken, but they can change. Binary consumers don't use the re-export so are not affected, I hope.

I don't agree in this case. Due to that dependency reexport, we are UML API providers, therefore responsible of this provision. Client bundles might potentially be broken because of the re-export removal, and the only way to announce this potential hazard is increasing the major version number (even though the client solution is as simple as including the missing dependency in a manifest.mf file, which could be a good point for a migration guide).

If we have a look to this section[1], I could come up with this rationale: If different actions (including increasing the major versions) are taken when adjusting the version range of the an exported plugins, I find quite reasonable taking some actions when suddenly we say we don't re-export them anymore (we don't provide some UML API anymore). IMO, increasing the major version, seems to be the more sensible action because of the reasoning in the previous paragraph.

http://wiki.eclipse.org/Version_Numbering#How_to_specify_versions_when_plug-ins_re-export_other_plug-ins

[eclipse-ocl-bot]

By Ed Willink on Jan 17, 2014 07:58

Please identify the exact sentence that you think says we have to do a major version increase.

You are ignoring the difference between source and binary compatibility.

We are making a breaking change to upward source compatibility (re-export is no longer there) but that is trivially fixed by source consumers adding an import. We are not actually chnaging any invokable APIs just the access to them.

We are not making any change to binary compatibility.

[eclipse-ocl-bot]

By Adolfo Sanchez-Barbudo Herrera on Jan 17, 2014 10:45

... as always, very constructive and friendly with your replies...

Adopting the same attitude. Comments in-line below.

Regards,\ Adolfo.

(In reply to Ed Willink from comment #9)

Please identify the exact sentence that you think says we have to do a major version increase.

"the major segment indicates breakage in the API"

You are ignoring the difference between source and binary compatibility.

I'm starting to doubt that you master it.

We are making a breaking change to upward source compatibility (re-export is no longer there) but that is trivially fixed by source consumers adding an import. We are not actually chnaging any invokable APIs just the access to them.

We are not making any change to binary compatibility.

"Agreed", changes are not usually made to binary compatibility. However, our changes will produce that our next deliverables are not binary compatible (with respect to the previously delivered one). Both source and binary compatibility is violated, because clients will (potentially) have to change their bundles to adopt our changes (they will have change their manifests and re-build).

Either you missed my point of client bundles might be broken if we remove the re-export, or you are ignoring how class loading works in osgi-based environments, or you are ignoring what compatibility is.

Due to the fact you usually give your assertions premises while others have to provide the evidences .... Don't worry, give me some time to come up with a repeatable use case.

[eclipse-ocl-bot]

By Ed Willink on Jan 17, 2014 10:59

How is binary compatibility broken?

[eclipse-ocl-bot]

By Adolfo Sanchez-Barbudo Herrera on Jan 17, 2014 11:05

Created attachment 239104 BrokenBundle

Steps:

1. Set the attached bundle in the dropins folder of your first installation
2. Run a second Eclipse instance with ocl/master in your workspace.
3. Start the classLoadingTest plugin.
4. In the first eclipse instance console you will see message [1]
5. Close the second instance.
6. Run a second Eclipse instance with ocl/424476 instead
7. Start the classLoadingTest plugin.
8. In the first eclipse instance console you will see message [2] -> Third plugin bundle has been broken.

Note: A way to start a bundle: Plugins Registry View -> Select the bundle -> Show Advanced Operations -> Start

[1] Trying to start the bundle Bundle started

[2] !ENTRY org.eclipse.pde.runtime 4 0 2014-01-17 14:09:44.582 !MESSAGE Exception in classloadingtest.Activator.start() of bundle classLoadingTest. !STACK 0 org.osgi.framework.BundleException: Exception in classloadingtest.Activator.start() of bundle classLoadingTest. at org.eclipse.osgi.internal.framework.BundleContextImpl.startActivator(BundleContextImpl.java:792) at org.eclipse.osgi.internal.framework.BundleContextImpl.start(BundleContextImpl.java:721) at org.eclipse.osgi.internal.framework.EquinoxBundle.startWorker0(EquinoxBundle.java:930) at org.eclipse.osgi.internal.framework.EquinoxBundle$EquinoxModule.startWorker(EquinoxBundle.java:319) at org.eclipse.osgi.container.Module.doStart(Module.java:558) at org.eclipse.osgi.container.Module.start(Module.java:429) at org.eclipse.osgi.internal.framework.EquinoxBundle.start(EquinoxBundle.java:393) at org.eclipse.osgi.internal.framework.EquinoxBundle.start(EquinoxBundle.java:412) at org.eclipse.pde.internal.runtime.registry.model.LocalRegistryBackend.start(LocalRegistryBackend.java:66) at org.eclipse.pde.internal.runtime.registry.model.Bundle.start(Bundle.java:126) at org.eclipse.pde.internal.runtime.registry.RegistryBrowser$13.run(RegistryBrowser.java:450) at org.eclipse.jface.action.Action.runWithEvent(Action.java:499) at org.eclipse.jface.action.ActionContributionItem.handleWidgetSelection(ActionContributionItem.java:588) at org.eclipse.jface.action.ActionContributionItem.access$2(ActionContributionItem.java:505) at org.eclipse.jface.action.ActionContributionItem$5.handleEvent(ActionContributionItem.java:415) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84) at org.eclipse.swt.widgets.Display.sendEvent(Display.java:4351) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1061) at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:4170) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3759) at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$9.run(PartRenderingEngine.java:1122) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332) at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:1006) at org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:146) at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:611) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332) at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:565) at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:150) at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:125) at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:109) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:80) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:372) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:226) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:636) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:591) at org.eclipse.equinox.launcher.Main.run(Main.java:1450) at org.eclipse.equinox.launcher.Main.main(Main.java:1426) Caused by: java.lang.NoClassDefFoundError: org/eclipse/uml2/uml/UMLFactory at classloadingtest.Activator.start(Activator.java:13) at org.eclipse.osgi.internal.framework.BundleContextImpl$3.run(BundleContextImpl.java:771) at org.eclipse.osgi.internal.framework.BundleContextImpl$3.run(BundleContextImpl.java:1) at java.security.AccessController.doPrivileged(Native Method) at org.eclipse.osgi.internal.framework.BundleContextImpl.startActivator(BundleContextImpl.java:764) ... 41 more Caused by: java.lang.ClassNotFoundException: org.eclipse.uml2.uml.UMLFactory cannot be found by osgi.identity; osgi.identity="classLoadingTest"; type="osgi.bundle"; version:Version="1.0.0.201401171358"; singleton:="true" at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:411) at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:331) at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:323) at org.eclipse.osgi.internal.loader.ModuleClassLoader.loadClass(ModuleClassLoader.java:160) at java.lang.ClassLoader.loadClass(ClassLoader.java:356) ... 46 more Root exception: java.lang.NoClassDefFoundError: org/eclipse/uml2/uml/UMLFactory at classloadingtest.Activator.start(Activator.java:13) at org.eclipse.osgi.internal.framework.BundleContextImpl$3.run(BundleContextImpl.java:771) at org.eclipse.osgi.internal.framework.BundleContextImpl$3.run(BundleContextImpl.java:1) at java.security.AccessController.doPrivileged(Native Method) at org.eclipse.osgi.internal.framework.BundleContextImpl.startActivator(BundleContextImpl.java:764) at org.eclipse.osgi.internal.framework.BundleContextImpl.start(BundleContextImpl.java:721) at org.eclipse.osgi.internal.framework.EquinoxBundle.startWorker0(EquinoxBundle.java:930) at org.eclipse.osgi.internal.framework.EquinoxBundle$EquinoxModule.startWorker(EquinoxBundle.java:319) at org.eclipse.osgi.container.Module.doStart(Module.java:558) at org.eclipse.osgi.container.Module.start(Module.java:429) at org.eclipse.osgi.internal.framework.EquinoxBundle.start(EquinoxBundle.java:393) at org.eclipse.osgi.internal.framework.EquinoxBundle.start(EquinoxBundle.java:412) at org.eclipse.pde.internal.runtime.registry.model.LocalRegistryBackend.start(LocalRegistryBackend.java:66) at org.eclipse.pde.internal.runtime.registry.model.Bundle.start(Bundle.java:126) at org.eclipse.pde.internal.runtime.registry.RegistryBrowser$13.run(RegistryBrowser.java:450) at org.eclipse.jface.action.Action.runWithEvent(Action.java:499) at org.eclipse.jface.action.ActionContributionItem.handleWidgetSelection(ActionContributionItem.java:588) at org.eclipse.jface.action.ActionContributionItem.access$2(ActionContributionItem.java:505) at org.eclipse.jface.action.ActionContributionItem$5.handleEvent(ActionContributionItem.java:415) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84) at org.eclipse.swt.widgets.Display.sendEvent(Display.java:4351) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1061) at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:4170) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3759) at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$9.run(PartRenderingEngine.java:1122) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332) at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:1006) at org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:146) at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:611) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332) at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:565) at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:150) at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:125) at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:109) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:80) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:372) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:226) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:636) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:591) at org.eclipse.equinox.launcher.Main.run(Main.java:1450) at org.eclipse.equinox.launcher.Main.main(Main.java:1426) Caused by: java.lang.ClassNotFoundException: org.eclipse.uml2.uml.UMLFactory cannot be found by osgi.identity; osgi.identity="classLoadingTest"; type="osgi.bundle"; version:Version="1.0.0.201401171358"; singleton:="true" at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:411) at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:331) at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:323) at org.eclipse.osgi.internal.loader.ModuleClassLoader.loadClass(ModuleClassLoader.java:160) at java.lang.ClassLoader.loadClass(ClassLoader.java:356) ... 46 more

:compression: classLoadingTest_1.0.0.201401171601.jar

[eclipse-ocl-bot]

By Adolfo Sanchez-Barbudo Herrera on Jan 17, 2014 11:38

(In reply to Ed Willink from comment #11)

How is binary compatibility broken?

How can a bundle figure out where to load a class from, providing the bundle manifest doesn't depend directly/indirectly (via re-export) on the bundle which provides such a class ?

If you need to change (and obviously rebuild) the bundle to accommodate others changes, there is not any compatibility (nor binary/source) at all with respect to those changes.

A -> B -rexports-> C

If A uses class defined in C, a change that

A -> B -> C

Enforces A to create a dependency on C:

A -> B -> C\ A -> C

Therefore A needs to be changed to go on working with a class from C, hence, B is not compatible (nor binary nor source) because A gets broken unless A includes that A -> C dependency

As I understand binary/compatibility:

• binary compatibility: Every client code will work as before without doing anything on their side.
• source compatibility: Every client code will work as before without changing any code on their side, although a recompilation is required.

Due to the fact that a bundle is more than just Java code (also their manifest files), ocl/424476 will break the binary compatibility of those plugins which remove the re-exports (as the reported use case demonstrates)

If anything doesn't make sense, please let me know.

Regards,\ Adolfo.

[eclipse-ocl-bot]

By Ed Willink on Jan 17, 2014 12:26

(In reply to Adolfo Sanchez-Barbudo Herrera from comment #13)

(In reply to Ed Willink from comment #11)

How is binary compatibility broken?

How can a bundle figure out where to load a class from, providing the bundle manifest doesn't depend directly/indirectly (via re-export) on the bundle which provides such a class ?

Thanks. You're right. I though that the packager, which makes the Manifest.mf files unreadable also made them transitive. The extra content is class signatures not bundle imports.

So we have no choice on the major version, but at least we can drop the re-exports so that next time we can absorb the change.

============

"Exporting a version range that spans multiple major versions of a plug-in is not recommended, because it forces downstream plug-ins to support versions with arbitrary breaking changes between them."

"Not recommended" but not prohibited.

This can be ok short term except for totally irresponsible clients, but next time we have to re-export three then four major versions... Let's take the hit once and lose the re-exports.

[eclipse-ocl-bot]

By Adolfo Sanchez-Barbudo Herrera on Jan 19, 2014 16:22

(In reply to Ed Willink from comment #14)

(In reply to Adolfo Sanchez-Barbudo Herrera from comment #13)

(In reply to Ed Willink from comment #11)

How is binary compatibility broken?

How can a bundle figure out where to load a class from, providing the bundle manifest doesn't depend directly/indirectly (via re-export) on the bundle which provides such a class ?

Thanks. You're right. I though that the packager, which makes the Manifest.mf files unreadable also made them transitive. The extra content is class signatures not bundle imports.

So we have no choice on the major version, but at least we can drop the re-exports so that next time we can absorb the change.

============

"Exporting a version range that spans multiple major versions of a plug-in is not recommended, because it forces downstream plug-ins to support versions with arbitrary breaking changes between them."

"Not recommended" but not prohibited.

This can be ok short term except for totally irresponsible clients, but next time we have to re-export three then four major versions... Let's take the hit once and lose the re-exports.

Agree.

I´ll have a look to the branch tomorrow, but in principle, I feel that just your branch + (transitively) increasing the major version number of those versions which have removed the re-export should suffice.

Regards,\ Adolfo.

[eclipse-ocl-bot]

By Ed Willink on Jan 19, 2014 17:59

I've just updated the branch and it seeems to build against the latest UML2 I-build which has the latest 5.0 version changes and aggregation in the interim repo.

The intended changes are:

• major version change for all non-Pivot UML re-exporters\ --- includes old Console
• no further minor change for Pivot examples\ --- two major version range UML import for Pivot only
• no re-export of any UML plugin anywhere
• feature ripples

[eclipse-ocl-bot]

By Ed Willink on Jan 20, 2014 08:31

I have finally succeeded in installing the branch test build.

Secrets:

Install EMF from its interim to get the very new ecore.edit version 'required' by UML

Install (M4) EMF Validation (NOT EMF Validation SDK since that pulls in OCL Core and UML)

Install UML2 '5.0'

Install (M4) MWE, Xpand's Xtend, Xtext

Install OCL '5.0'

---

Just need to find out why the UML plugin tests fail...

?? provide a feature more suitable for EMF Validation SDK

?? provide a feature enabling Pivot OCL on Kepler

[eclipse-ocl-bot]

By Ed Willink on Jan 20, 2014 09:56

(In reply to Ed Willink from comment #17)

Just need to find out why the UML plugin tests fail...

Ugh! The UML interim repo has a 4.1.2 build more recent than the 5.0!

(Bug 426137)

[eclipse-ocl-bot]

By Adolfo Sanchez-Barbudo Herrera on Jan 20, 2014 11:41

Hi Ed,

May be I'm missing something, but I don't follow why Pivot UML re-exporters don't have to increase its major version. Likewise, I don't understand the following:

"--- two major version range UML import for Pivot only"

If we don't need to re-export anymore because we are simply using UML API which doesn't need to be re-exported, why do we have to increase the minor version range of those plugins ? This minor range increase prevents the components to be installed in kepler and previous. Are you sure about this ?

My recollection of individual review of the changes is the following:

ocl.build

Although we don't deliver it , I'd also increase the version (similarly to what is done to tests plugins, for instance)

ocl.edit \ \ org.eclipse.uml2.common.edit dependency should be set 1.5.0 as minimum version range, otherwise it can't be installable in Kepler and previous.

ocl.examples.domain

It looks like there is no UML classes usage. Remove dependency ?

ocl.examples.interpreter

org.eclipse.uml2.uml dependency should be set 4.0 as minimum version range, otherwise it can't be installable in Kepler and previous.\ \ ocl.examples.pivot \ \ I didn't understand why pivot doesn't have to increase its major version.\ \ ocl.uml

org.eclipse.uml2.uml.resources dependency should be set 4.0 as minimum version range, otherwise it can't be installable in Kepler and previous.

ocl.uml.edit

org.eclipse.uml2.uml.edit dependency should be set 4.0 as minimum version range.

ocl.uml.ui

org.eclipse.uml2.uml dependency should be set 4.0 as minimum version range, otherwise it can't be installable in Kepler and previous.

[eclipse-ocl-bot]

By Ed Willink on Jan 20, 2014 15:30

Thanks. I think we agree on the non-pivot upper bound major change.

You're probably right that the common lower bounds need to be unchanged, or UML eliminated altogether. Needs an update, and a test. Probably also needs the small Pivot-only feature and the large Pivot-only features that Laurent wants. These should demonstrate Kepler installability.

The pivot plugins have all already had their minor change, so don't need another minor change, and since they're only examples we can retract any accidental UML re-exports.

Since the residual issues are sufficiently minor and UML has now pushed the 5.0 change to master, we need to get an I-build out 'fast'. I'll therefore push the 'final' experiment to master.

[eclipse-ocl-bot]

By Adolfo Sanchez-Barbudo Herrera on Jan 21, 2014 06:57

Hi Ed,

Apologies for the delay, but I've been setting up a new installation, workspace and such.

The branch looks better now. The argument that "they're only examples we can retract any accidental UML re-exports" is quite arguable, specially when the pivot API is increasingly being adopted. In any case, I think that I've already done my job to this respect.

[If it depended on me, that examples.pivot plugin should be 4.0.0 rather than 3.4.0 :P ]

Other final comments:

• IMO, new features should have a 1.0.0 version
• feature.xml files should fit their names, providers etc. In order to get the name from feature.properties, they require to specify % . Have a look to other features as an example.

Regards,\ Adolfo.

[eclipse-ocl-bot]

By Ed Willink on Jan 22, 2014 14:48

Pushed to master for M5.

The Pivot will be promoted to 1.0 in Lun+1 hopefully.

Starting versions are very debateable. 1.0 is policy, but no one mentioned it on a recent croos-project-dev query where they opted for 4.4.

Which feature.xml is wrong?

[eclipse-ocl-bot]

By Adolfo Sanchez-Barbudo Herrera on Jan 24, 2014 05:47

(In reply to comment #22)\

Which feature.xml is wrong?

They were fixed, thereafter.

Regards,\ Adolfo.

[eclipse-ocl-bot]

By Ed Willink on Jan 24, 2014 06:02

Thanks.

I think the only difference between branch and master jobs now is that master promotes.

[eclipse-ocl-bot]

By Ed Willink on May 25, 2015 17:19

CLOSED after more than a year in the RESOLVED state.