Bugzilla – Full Text Bug Listing
| Summary: | [editor] imported files not recognized | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Modeling] OCL | Reporter: | Ed Willink <ed> | ||||
| Component: | Core | Assignee: | OCL Inbox <mdt-ocl-inbox> | ||||
| Status: | CLOSED FIXED | QA Contact: | Ed Willink <ed> | ||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | eclipse, juan.cadavid, michele.mancioppi | ||||
| Version: | 3.1.0 | ||||||
| Target Milestone: | SR1 | ||||||
| Hardware: | PC | ||||||
| OS: | Windows Vista | ||||||
| Whiteboard: | |||||||
| Bug Depends on: | 350894 | ||||||
| Bug Blocks: | |||||||
| Attachments: |
|
||||||
Probably a duplicate of Bug 350894, which I'm going to fix immediately for SR1. (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<ecore::EString>; [Once the CS to AS mapping is auto-generated from models, the resolution order cannot possibly go wrong .... ] (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. Pushed to origin/master Created attachment 200972 [details]
Selected changes for SR1
Patch contains the same changes as those to master, less those that are cosmetic renaming/refactoring/tidying.
Please approve for SR1. (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? 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. (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. merged to maintenance/R3_1 Apologies for my staggering ignorance, but which of the many update sites distributes the OCLinECORE version that fixes this bug? (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 :-{ ). (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. (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. (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? (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 (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! CLOSED after a year in the RESOLVED state. |
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.