[releng] Wrong version range for imp

[eclipse-ocl-bot]

| --- | --- |
| Bugzilla Link | 349157 |
| Status | CLOSED WONTFIX |
| Importance | P3 normal |
| Reported | Jun 12, 2011 17:38 EDT |
| Modified | May 27, 2014 09:53 EDT |
| Version | 3.1.0 |
| Reporter | Axel Uhl |

Description

org.eclipse.ocl.examples.editor.ui has a version range [0.1.104,0.1.105) for org.eclipse.imp.runtime. This doesn't compile for Indigo RC4 where imp comes in 0.1.108. I suggest we set the version range to [0.1.104,0.1.110).

[eclipse-ocl-bot]

By Axel Uhl on Jun 12, 2011 17:41

Created attachment 197861
Extending IMP version range

See previous comment

:notepad_spiral: 349157.patch

[eclipse-ocl-bot]

By Axel Uhl on Jun 12, 2011 17:43

Pushed patch to bugs/349157.

[eclipse-ocl-bot]

By Ed Willink on Jun 13, 2011 01:49

(In reply to comment #0)

This doesn't compile for Indigo RC4 where imp comes in 0.1.108.

Fortunately this isn't quite true or we'd be asking for an Indigo respin. o.e.o.e.editor.ocl* is not part of Helios or Indigo; the IP issue was the original reason for Xtext migration.

This plugin was part of the IMP support for IMP editors migrated from QVTd. It is not used by the Xtext or Pivot support. It was only retained because QVTd has not moved on. Not a good enough reason.

IMP is incubation and makes regular small API changes so just raising the bound without test is ignoring the problem. Let's eliminate all IMP/LPG editor relics and lose o.e.o.e.editor* and o.e.o.e.parser*.

[eclipse-ocl-bot]

By Axel Uhl on Jun 13, 2011 04:02

(In reply to comment #3)

(In reply to comment #0)

This doesn't compile for Indigo RC4 where imp comes in 0.1.108.

Fortunately this isn't quite true or we'd be asking for an Indigo respin.
o.e.o.e.editor.ocl* is not part of Helios or Indigo; the IP issue was the
original reason for Xtext migration.

This plugin was part of the IMP support for IMP editors migrated from QVTd. It
is not used by the Xtext or Pivot support. It was only retained because QVTd
has not moved on. Not a good enough reason.

IMP is incubation and makes regular small API changes so just raising the bound
without test is ignoring the problem. Let's eliminate all IMP/LPG editor relics
and lose o.e.o.e.editor* and o.e.o.e.parser*.

I wouldn't call it "without test." I ensured that everything compiles and that all tests are green. But if you can come up with a way to eliminate the dependency altogether, even better. I just have the problem that with these bundles checked out I have errors in my workspace which is inconvenient. Therefore, if compile/tests-green suffices for the time being, maybe you can +1 this one and then come up with a way to eliminate the dependency in a separate bug altogether.

[eclipse-ocl-bot]

By Ed Willink on Jun 13, 2011 04:21

There are very few, if any tests on these bundles. For now just delete o.e.o.e.editor* and o.e.o.e.parser* from your workspace.

[eclipse-ocl-bot]

By Ed Willink on Aug 30, 2011 01:16

The IMP-based code is obsolete, so any consumer takes responsibility for use. Let's not provide any needless impediments.

Just remove the upper bound altogether (for Juno; no change for SR1/SR2).

[eclipse-ocl-bot]

By Ed Willink on Aug 30, 2011 01:34

(In reply to comment #6)

The IMP-based code is obsolete, so any consumer takes responsibility for use.
Let's not provide any needless impediments.

Just remove the upper bound altogether (for Juno; no change for SR1/SR2).

No. I think this should go in SR1 RC2 as well today. We don't care, but anyone using both OCL Examples (not necessarily needing IMP at all) and IMP gets a bounds conflict.

Removing the bound limit avoids a Bugzilla from an Indigo ImpactAnalyzer+IMP user.

[eclipse-ocl-bot]

By Axel Uhl on Aug 30, 2011 08:42

(In reply to comment #7)

(In reply to comment #6)

The IMP-based code is obsolete, so any consumer takes responsibility for use.
Let's not provide any needless impediments.

Just remove the upper bound altogether (for Juno; no change for SR1/SR2).

No. I think this should go in SR1 RC2 as well today. We don't care, but anyone
using both OCL Examples (not necessarily needing IMP at all) and IMP gets a
bounds conflict.

Removing the bound limit avoids a Bugzilla from an Indigo ImpactAnalyzer+IMP
user.

Done. Branch bug/349157 ready for review with this trivial change. Let me know into which branches to merge.

[eclipse-ocl-bot]

By Ed Willink on Aug 30, 2011 12:47

Do the same change on both maintenance/R3_1 and master, setting the relevant plugin to 3.1.1. (The feature is already 3.1.1 so no ripple.)

If you're on line and able to do this now, reply and do so, otherwise I will do so at 18:15 (30 minutes time), since it needs to be in for the SR1 RC2 build.

[eclipse-ocl-bot]

By Ed Willink on Aug 30, 2011 12:50

I prefer no upper bound since we are disclaiming all responsibility for compatibility; just providing the code with minimum impediment to anyone who wants it. (If IMP leaps to 1.400, I don't want to have to change this again.)

[eclipse-ocl-bot]

By Adolfo Sanchez-Barbudo Herrera on Aug 30, 2011 13:09

Ed

(In reply to comment #9)

Do the same change on both maintenance/R3_1 and master, setting the relevant
plugin to 3.1.1. (The feature is already 3.1.1 so no ripple.)

If you're on line and able to do this now, reply and do so, otherwise I will do
so at 18:15 (30 minutes time), since it needs to be in for the SR1 RC2 build.

I don't follow ... AFAI have understood, the issue is part of non-released plugin isn't it ? Why do we need this change for today's build ?

(I'll do in in an hour time, more or less).

Cheers,
Adolfo.

[eclipse-ocl-bot]

By Ed Willink on Aug 30, 2011 13:32

(In reply to comment #11)

I don't follow ... AFAI have understood, the issue is part of non-released
plugin isn't it ? Why do we need this change for today's build ?

Well spotted. All change. IMP was not used in Indigo, so no change in SR1.

IMP will not be used in Juno, so no change needed for Mx.

I've just been trying to do the SR1 patch; loading LPG doesn't seem easy.

Do we care whether unreleased code is easier to consume? I don't think so.

I'm still subscribed to imp-dev. I recall discussion of a minor but breaking API change. I don't think we need to support this code in any way. Consumers copy and mend.

[eclipse-ocl-bot]

By Ed Willink on Sep 13, 2011 01:59

bug/349157 renamed to archive/349157 to clarify GIT history of abandoned work.

[eclipse-ocl-bot]

By Faiez Za on Sep 17, 2012 04:25

IMP will not be used in Juno, so no change needed for Mx.

I find in http://www.eclipse.org/projects/project-plan.php?planurl=modeling/mdt/ocl/project-info/plan_juno.xml#release_deliverables that

Eclipse (MDT) OCL 4.0.0 source code will be available as versions tagged "R4_0" in the project's GIT repository.

However, I find in the tagged version "R4_0" in the
org.eclipse.ocl.examples.editor.ui.imp.CommonParseResult class

some IMP imports.

It is normal?

[eclipse-ocl-bot]

By Ed Willink on Sep 17, 2012 05:13

You should find that org.eclipse.ocl.examples.editor.ui.imp is in the "archives" folder.

When we used CVS, we could provide a *.psf file that imported the right plugins. GIT unfortunately requires a total clone, and then seems to leave the user to guess at which projects to import. See Bug 355912 for discussion of a GIT replacement for CVS PSFs.

[eclipse-ocl-bot]

By Ed Willink on May 27, 2014 09:46

CLOSED after more than a year in RESOLVED state.

[eclipse-ocl-bot]

By Ed Willink on May 27, 2014 09:53

and CLOSE