eclipse-ocl / org.eclipse.ocl

Eclipse Public License 2.0
0 stars 0 forks source link

[editor] imported files not recognized #753

Closed eclipse-ocl-bot closed 1 month ago

eclipse-ocl-bot commented 1 month ago

| --- | --- | | Bugzilla Link | 353793 | | Status | CLOSED FIXED | | Importance | P3 normal | | Reported | Aug 03, 2011 12:24 EDT | | Modified | May 20, 2013 11:35 EDT | | Version | 3.1.0 | | Depends on | 350894 | | Reporter | Ed Willink |

Description

From Juan Cadavid on the mdt-ocl newsgroup:

I have a problem when importing and using elements from other Ecore files inside my current file in OclInEcore. Suppose I have a.ecore:

module _'a.ecore'\ package packA : packA = 'packA'{\ class A;\ }

which is imported by b.ecore:

module _'b.ecore'\ import packA : 'a.ecore#/';

package packB : packB = 'packB'\ {\ class B extends packA::A;\ }

This file displays no errors in the editor when saved; but when I close and reopen I get this:

module _'b.ecore'\ package packB : packB = 'packB'\ {\ class B;\ }

Is there anything I'm doing wrong? I'm using the Indigo release version. This used to work well before.

eclipse-ocl-bot commented 1 month ago

By Ed Willink on Aug 04, 2011 01:44

Probably a duplicate of Bug 350894, which I'm going to fix immediately for SR1.

eclipse-ocl-bot commented 1 month ago

By Ed Willink on Aug 04, 2011 04:59

(In reply to comment #1)

Probably a duplicate of Bug 350894, which I'm going to fix immediately for SR1.

This example has an extra complication; the qualified name is a superclass reference and there is bug in the resolution order dependencies; superclasses wait till all type specializations have definitions, but if there are no specializations, A::B may resolve B while A is still a proxy. Workaround: put in a bogus specialization such as

import 'http://www.eclipse.org/emf/2002/Ecore';

...

class BogusSpecialization extends ecore::EEList;

[Once the CS to AS mapping is auto-generated from models, the resolution order cannot possibly go wrong .... ]

eclipse-ocl-bot commented 1 month ago

By Ed Willink on Aug 04, 2011 16:46

(In reply to comment #1)

Probably a duplicate of Bug 350894, which I'm going to fix immediately for SR1.

Actually nothing to do with Bug 350894. Once the reference resolution ordering is fixed the CS to pivot conversioon tries to locate the pivot by moniker, bit since the target was from another resource it already had a pivot so the lookup of a missing moniker was both unnecessary and wrong.

Can't see a workaround for this. You'll have to use the Sample Ecore Editor to mend after saving.

Patch imminent; may be bundled with Bug 350894.

eclipse-ocl-bot commented 1 month ago

By Ed Willink on Aug 05, 2011 06:37

Pushed to origin/master

eclipse-ocl-bot commented 1 month ago

By Ed Willink on Aug 05, 2011 07:54

Created attachment 200972 Selected changes for SR1

Patch contains the same changes as those to master, less those that are cosmetic renaming/refactoring/tidying.

:notepad_spiral: %5B353793%5D+selected+edits+from+master+stream.patch

eclipse-ocl-bot commented 1 month ago

By Ed Willink on Aug 05, 2011 07:55

Please approve for SR1.

eclipse-ocl-bot commented 1 month ago

By Axel Uhl on Aug 05, 2011 08:05

(In reply to comment #6)

Please approve for SR1.

You already pushed to master. If approval was needed, shouldn't this have happened before pushing to master?

eclipse-ocl-bot commented 1 month ago

By Ed Willink on Aug 05, 2011 08:56

The push to master was for examples plugins, so approval not required.

The patch for maintenance/R3_1 requires approval, if only a "doesn't look damaging" nod through.

eclipse-ocl-bot commented 1 month ago

By Axel Uhl on Aug 05, 2011 10:41

(In reply to comment #8)

The push to master was for examples plugins, so approval not required.

The patch for maintenance/R3_1 requires approval, if only a "doesn't look damaging" nod through.

Ah, I see. Well, all suggested changes are in examples/. Doesn't look damaging, +1.

eclipse-ocl-bot commented 1 month ago

By Ed Willink on Aug 06, 2011 12:22

merged to maintenance/R3_1

eclipse-ocl-bot commented 1 month ago

By Michele Mancioppi on Sep 04, 2011 07:40

Apologies for my staggering ignorance, but which of the many update sites distributes the OCLinECORE version that fixes this bug?

eclipse-ocl-bot commented 1 month ago

By Michele Mancioppi on Sep 04, 2011 08:42

(In reply to comment #11)

Apologies for my staggering ignorance, but which of the many update sites distributes the OCLinECORE version that fixes this bug?

Well, more, hectic searching did help :-)\ http://download.eclipse.org/modeling/mdt/ocl/updates/milestones

Still finding a way to fix its dependencies, though (might have to use an Eclipse 3.8M1 platform :-{ ).

eclipse-ocl-bot commented 1 month ago

By Ed Willink on Sep 04, 2011 09:05

(In reply to comment #12)

Still finding a way to fix its dependencies, though (might have to use an Eclipse 3.8M1 platform :-{ ).

If you install the full update site, you will need 3.8M1 (or 4.2M1). However it's only a needless pedantry from the build system that mandates 3.8. So you igf you're comfortable zapping a bogus dependency it should work.

But since

(In reply to comment #10)

merged to maintenance/R3_1

The fixed should be in the SR i.e. 3.1.1 which should be available as a normal update from within Eclipse.

eclipse-ocl-bot commented 1 month ago

By Ed Willink on Sep 04, 2011 09:12

(In reply to comment #13)

But since

(In reply to comment #10)

merged to maintenance/R3_1

The fixed should be in the SR i.e. 3.1.1 which should be available as a normal update from within Eclipse.

Correction: SR1 is currently at RC2, so you can download/update 3.1.1RC2 to get the fix in Indigo.

eclipse-ocl-bot commented 1 month ago

By Michele Mancioppi on Sep 04, 2011 09:17

(In reply to comment #14)

(In reply to comment #13)

But since

(In reply to comment #10)

merged to maintenance/R3_1

The fixed should be in the SR i.e. 3.1.1 which should be available as a normal update from within Eclipse.

Correction: SR1 is currently at RC2, so you can download/update 3.1.1RC2 to get the fix in Indigo.

Thanks for the prompt answer(In reply to comment #14)

(In reply to comment #13)

But since

(In reply to comment #10)

merged to maintenance/R3_1

The fixed should be in the SR i.e. 3.1.1 which should be available as a normal update from within Eclipse.

Correction: SR1 is currently at RC2, so you can download/update 3.1.1RC2 to get the fix in Indigo.

Sorry for being thick as marble, but by "3.1.1RC2" you mean the whole modeling package, version 3.1.1RC2? Do you maybe have handy the update site where I can pull the updates from?

eclipse-ocl-bot commented 1 month ago

By Ed Willink on Sep 04, 2011 11:11

(In reply to comment #15)

Sorry for being thick as marble, but by "3.1.1RC2" you mean the whole modeling package, version 3.1.1RC2? Do you maybe have handy the update site where I can pull the updates from?

No. SR releases are supposed to be trivial safe fixes, so there should be no project cross-dependencies.

3.1.1RC2 is available from http://www.eclipse.org/modeling/mdt/downloads/?project=ocl

and with corresponding datestamnp from

http://download.eclipse.org/modeling/mdt/ocl/updates/maintenance

eclipse-ocl-bot commented 1 month ago

By Michele Mancioppi on Sep 04, 2011 11:19

(In reply to comment #16)

(In reply to comment #15)

Sorry for being thick as marble, but by "3.1.1RC2" you mean the whole modeling package, version 3.1.1RC2? Do you maybe have handy the update site where I can pull the updates from?

No. SR releases are supposed to be trivial safe fixes, so there should be no project cross-dependencies.

3.1.1RC2 is available from http://www.eclipse.org/modeling/mdt/downloads/?project=ocl

and with corresponding datestamnp from

http://download.eclipse.org/modeling/mdt/ocl/updates/maintenance

Thanks a lot!

eclipse-ocl-bot commented 1 month ago

By Ed Willink on May 20, 2013 11:35

CLOSED after a year in the RESOLVED state.