Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 353793 - [editor] imported files not recognized
Summary: [editor] imported files not recognized
Status: CLOSED FIXED
Alias: None
Product: OCL
Classification: Modeling
Component: Core (show other bugs)
Version: 3.1.0   Edit
Hardware: PC Windows Vista
: P3 normal (vote)
Target Milestone: SR1   Edit
Assignee: OCL Inbox CLA
QA Contact: Ed Willink CLA
URL:
Whiteboard:
Keywords:
Depends on: 350894
Blocks:
  Show dependency tree
 
Reported: 2011-08-03 12:24 EDT by Ed Willink CLA
Modified: 2013-05-20 11:35 EDT (History)
3 users (show)

See Also:


Attachments
Selected changes for SR1 (10.00 KB, patch)
2011-08-05 07:54 EDT, Ed Willink CLA
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Ed Willink CLA 2011-08-03 12:24:25 EDT
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.
Comment 1 Ed Willink CLA 2011-08-04 01:44:17 EDT
Probably a duplicate of Bug 350894, which I'm going to fix immediately for SR1.
Comment 2 Ed Willink CLA 2011-08-04 04:59:15 EDT
(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 .... ]
Comment 3 Ed Willink CLA 2011-08-04 16:46:01 EDT
(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.
Comment 4 Ed Willink CLA 2011-08-05 06:37:09 EDT
Pushed to origin/master
Comment 5 Ed Willink CLA 2011-08-05 07:54:33 EDT
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.
Comment 6 Ed Willink CLA 2011-08-05 07:55:49 EDT
Please approve for SR1.
Comment 7 Axel Uhl CLA 2011-08-05 08:05:58 EDT
(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?
Comment 8 Ed Willink CLA 2011-08-05 08:56:51 EDT
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.
Comment 9 Axel Uhl CLA 2011-08-05 10:41:22 EDT
(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.
Comment 10 Ed Willink CLA 2011-08-06 12:22:26 EDT
merged to maintenance/R3_1
Comment 11 Michele Mancioppi CLA 2011-09-04 07:40:32 EDT
Apologies for my staggering ignorance, but which of the many update sites distributes the OCLinECORE version that fixes this bug?
Comment 12 Michele Mancioppi CLA 2011-09-04 08:42:56 EDT
(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 :-{ ).
Comment 13 Ed Willink CLA 2011-09-04 09:05:21 EDT
(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.
Comment 14 Ed Willink CLA 2011-09-04 09:12:37 EDT
(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.
Comment 15 Michele Mancioppi CLA 2011-09-04 09:17:09 EDT
(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?
Comment 16 Ed Willink CLA 2011-09-04 11:11:01 EDT
(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
Comment 17 Michele Mancioppi CLA 2011-09-04 11:19:04 EDT
(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!
Comment 18 Ed Willink CLA 2013-05-20 11:35:55 EDT
CLOSED after a year in the RESOLVED state.