Community
Participate
Working Groups
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).
Created attachment 197861 [details] Extending IMP version range See previous comment
Pushed patch to bugs/349157.
(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*.
(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.
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.
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).
(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.
(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.
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 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.)
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.
(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.
bug/349157 renamed to archive/349157 to clarify GIT history of abandoned work.
> 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?
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.
CLOSED after more than a year in RESOLVED state.
and CLOSE
