Comment 1 Cedric Brun 2014-06-26 07:26:22 EDT

Thanks for your feedback.

How is your .ecore file at first ? how are the references serialized, are they relative or absolutes ?

I  have to digg through it, It might come from an URI normalization which would find things into the workspace or into the targetplatform...

is commons.ecore also in the targetplatform or in the workspace ?

Would that be possible for you to give me example projects so that I can reproduce the issue ?

Comment 2 Hendy Irawan 2014-06-26 07:35:03 EDT

> How is your .ecore file at first ? how are the references serialized, are they relative or absolutes ?

They are all relatives, in the form of ../../(some more)/project/src/main/resources/somepackage/commons.ecore

> is commons.ecore also in the targetplatform or in the workspace ?

It's in another project in the same workspace. It's not in target platform and I don't use target platform since all are Maven projects, no PDE projects.

> Would that be possible for you to give me example projects so that I can reproduce the issue ?

Not yet.. I'll try to find if it's reproducible with a file in my open source project.

What I know is it doesn't happen with all .ecore files, since I've made a couple other diagrams and working OK. this one is with quite complex Ecore.

And and I've just used Ecore Tools 2.0 for an hour now. Brilliant work BTW :)

Self note: A couple other minor bugs I've found (not so critical):

1. After "Initialize Ecore Diagram", .aird file doesn't show up in Eclipse Project Explorer view, but the file exists in the filesystem. F5 doesn't make it show up. Re-Initialize Ecore Diagram still won't make it show up. Restart Eclipse doesn't make it show up, but after restart I can re-initialize Ecore Diagram and it'll show up.

2. I once made the "Arrange All" button gone, this happens after I create a few representations of the same .aird file. Reopening diagram file makes button show up again.

Comment 3 Cedric Brun 2014-06-26 08:16:18 EDT

> Not yet.. I'll try to find if it's reproducible with a file in my open
> source project.
> 
> What I know is it doesn't happen with all .ecore files, since I've made a
> couple other diagrams and working OK. this one is with quite complex Ecore.

I tried to reproduce by having two projects, one Ecore in src/some/package in one of the project and the other one at the root of the second project.

All the references are kept intacts when modifying and saving, I could not reproduce it so far.

That being said the stripping of "src" in the uris is reminding me of some logic in the Acceleo code generator (that could be an unexpected interaction between Acceleo, Sirius and EcoreTools...) , are you using it in your projects ? Is there any Acceleo project in your workspace ? 

> 
> And and I've just used Ecore Tools 2.0 for an hour now. Brilliant work BTW :)

Thanks for this, a comment like that goes a long way in motivating me.
> 
> Self note: A couple other minor bugs I've found (not so critical):
> 
> 1. After "Initialize Ecore Diagram", .aird file doesn't show up in Eclipse
> Project Explorer view, but the file exists in the filesystem. F5 doesn't
> make it show up. Re-Initialize Ecore Diagram still won't make it show up.
> Restart Eclipse doesn't make it show up, but after restart I can
> re-initialize Ecore Diagram and it'll show up.
> 
Weird.. Is there anything suspicious in the Error Log view ?
I added a comment here https://bugs.eclipse.org/bugs/show_bug.cgi?id=438126 so that I make sure to have a deeper look on this when I work on the initialization action again.

> 2. I once made the "Arrange All" button gone, this happens after I create a
> few representations of the same .aird file. Reopening diagram file makes
> button show up again.

I noticed this  too but could not have a clear scenario to reproduce it so far.

Comment 4 Hendy Irawan 2014-06-26 08:50:15 EDT

Aww you're right.... the Error Log!
How foolish of me... sorry

Comment 5 Hendy Irawan 2014-06-27 02:43:22 EDT

BTW I got this during Initialize Ecore Diagram : (not sure if it's related, when this happens, the .ecore hasn't been altered)

java.lang.reflect.InvocationTargetException
	at org.eclipse.jface.operation.ModalContext.run(ModalContext.java:423)
	at org.eclipse.jface.dialogs.ProgressMonitorDialog.run(ProgressMonitorDialog.java:527)
	at org.eclipse.ui.internal.progress.ProgressMonitorJobsDialog.run(ProgressMonitorJobsDialog.java:284)
	at org.eclipse.ui.internal.progress.ProgressManager.run(ProgressManager.java:1190)
	at org.eclipse.sirius.ui.tools.internal.actions.creation.CreateRepresentationAction.run(CreateRepresentationAction.java:136)
	at org.eclipse.sirius.ui.tools.internal.wizards.CreateRepresentationWizard.performFinish(CreateRepresentationWizard.java:65)
	at org.eclipse.jface.wizard.WizardDialog.finishPressed(WizardDialog.java:853)
	at org.eclipse.jface.wizard.WizardDialog.buttonPressed(WizardDialog.java:438)
	at org.eclipse.jface.dialogs.Dialog$2.widgetSelected(Dialog.java:619)
	at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:248)
	at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
	at org.eclipse.swt.widgets.Display.sendEvent(Display.java:4486)
	at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1388)
	at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3831)
	at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3441)
	at org.eclipse.jface.window.Window.runEventLoop(Window.java:832)
	at org.eclipse.jface.window.Window.open(Window.java:808)
	at org.eclipse.emf.ecoretools.design.action.EcoreInitDiagramFileAction.openCreateRepresentationWizard(EcoreInitDiagramFileAction.java:168)
	at org.eclipse.emf.ecoretools.design.action.EcoreInitDiagramFileAction.run(EcoreInitDiagramFileAction.java:88)
	at org.eclipse.ui.internal.PluginAction.runWithEvent(PluginAction.java:253)
	at org.eclipse.jface.action.ActionContributionItem.handleWidgetSelection(ActionContributionItem.java:595)
	at org.eclipse.jface.action.ActionContributionItem.access$2(ActionContributionItem.java:511)
	at org.eclipse.jface.action.ActionContributionItem$5.handleEvent(ActionContributionItem.java:420)
	at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
	at org.eclipse.swt.widgets.Display.sendEvent(Display.java:4486)
	at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1388)
	at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3831)
	at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3441)
	at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$9.run(PartRenderingEngine.java:1151)
	at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
	at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:1032)
	at org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:148)
	at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:636)
	at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
	at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:579)
	at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:150)
	at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:135)
	at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:134)
	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:104)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:382)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:236)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:483)
	at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:648)
	at org.eclipse.equinox.launcher.Main.basicRun(Main.java:603)
	at org.eclipse.equinox.launcher.Main.run(Main.java:1465)
	at org.eclipse.equinox.launcher.Main.main(Main.java:1438)
Caused by: java.lang.NullPointerException
	at org.eclipse.sirius.ui.tools.internal.actions.creation.CreateRepresentationAction$1.run(CreateRepresentationAction.java:126)
	at org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext.java:122)

eclipse.buildId=4.4.0.I20140606-1215
java.version=1.8.0_05
java.vendor=Oracle Corporation
BootLoader constants: OS=linux, ARCH=x86_64, WS=gtk, NL=en_US
Framework arguments:  -product org.eclipse.epp.package.jee.product
Command-line arguments:  -os linux -ws gtk -arch x86_64 -product org.eclipse.epp.package.jee.product

Comment 6 Hendy Irawan 2014-06-27 02:44:15 EDT

BTW, here's a screencast of the bug: http://youtu.be/p9E4Ka9c-fY

It's 100% reproducible using my projects.

Comment 7 Cedric Brun 2014-06-27 03:53:11 EDT

> 
> java.lang.reflect.InvocationTargetException
> 	at org.eclipse.jface.operation.ModalContext.run(ModalContext.java:423)
> 	at
> org.eclipse.jface.dialogs.ProgressMonitorDialog.run(ProgressMonitorDialog.
> java:527)
> 	at
> org.eclipse.ui.internal.progress.ProgressMonitorJobsDialog.
> run(ProgressMonitorJobsDialog.java:284)
> 	at
> org.eclipse.ui.internal.progress.ProgressManager.run(ProgressManager.java:
> 1190)
> 	at

is another issue which has been fixed and distributed already since the release (See https://bugs.eclipse.org/bugs/show_bug.cgi?id=438287)

Comment 8 Cedric Brun 2014-06-27 03:54:42 EDT

(In reply to Hendy Irawan from comment #6)
> BTW, here's a screencast of the bug: http://youtu.be/p9E4Ka9c-fY
> 

I'm waiting for Google to encode it. 

> It's 100% reproducible using my projects.

Which is a piece of good news.

AFAIK you did not answer my previous question : the stripping of "src" in the uris is reminding me of some logic in the Acceleo code generator (that could be an unexpected interaction between Acceleo, Sirius and EcoreTools...) , are you using it in your projects ? Is there any Acceleo project in your workspace ?

Comment 9 Hendy Irawan 2014-06-27 04:16:02 EDT

I've not installed any Acceleo plugins and there's no Acceleo projects in my workspace.

I also don't have any Sirius projects.

(actually I try not to have any PDE projects, but everytime Eclipse generates Java from .genmodel it insists on generating plugin.xml etc. which are never used by my plain Maven projects)

Comment 10 Cedric Brun 2014-06-27 05:53:37 EDT

The video allow me to see the problem going on but without being able to debug it it is going to be like shooting in the dark.

Is that possible to keep the project layout, remove all the code, all the Ecore content you can't share and attach this ?

Or just "mimicking" your workspace and ecore structure with dummy projects and files ?

Comment 11 Hendy Irawan 2014-06-27 06:39:05 EDT

BTW, the .aird file doesn't have outline in Package Explorer view (the default view used by Java Perspective), but works in Project Explorer view. Should I file this as another bug?

Also, double-clicking .aird file in Package Explorer view opens it in text editor.

See: http://imgur.com/x7kYCif

Comment 12 Hendy Irawan 2014-06-27 06:49:08 EDT

Hi Cedric,

I've sent the minimum workspace to reproduce in private email.

Hope it helps. :)

Thank you.

Comment 13 Cedric Brun 2014-06-27 08:18:39 EDT

I gave it a quick try on my development machine.
Linux x86_64 within the Luna modeling package. I can do the exact same scenario you did without reproducing the change to the Ecore file. Once I create the diagram, if I save nothing changes in the .ecore file. If I introduce a change in it (adding an EClass) and I save, the file gets reloaded but the file does not get broken.

I'll try on windows with a JEE package now.

Comment 14 Hendy Irawan 2014-06-27 08:28:42 EDT

that's weird... I'm using Eclipse 4.4 JEE package Linux 64 + Xtext and some other plugins...

I'm using Linux Mint 17 KDE 64bit, however I'm pretty sure this should be OS independent.

Comment 15 Cedric Brun 2014-06-27 08:40:11 EDT

Hum, neither reproducted with Eclipse 4.4 JEE + EcoreTools installed through the marketplace.

Now we'll have to digg through potential integration issue with another plugin. 

Would you mind attaching your configuration to this bugzilla  (Help/Installation Details/Configuration)?

Would you be able to tell me from which update-sites you installed what ?

Or even better, putting a zip of your eclipse installation somewhere ? As I'm on linux64 myself I should be able to use it directly...

Comment 16 Hendy Irawan 2014-06-27 08:49:16 EDT

Sure...

Beware it's a ~400 MB tar.xz though...

It'll be taking me about 3 hours to upload it... :)

I'll let you know when it's available.

Comment 17 Cedric Brun 2014-06-27 08:56:08 EDT

In the meantime I'll install Xtext 2.6.0

Feel free to attach your configuration anyway, that could help upfront.

Comment 18 Hendy Irawan 2014-06-27 09:01:44 EDT

Created attachment 244592 [details]
Eclipse plugins configuration

attached config

I'm using Xtext 2.6.1 BTW

although none of my projects (both in that workspace or my real workspace) are using Xtext

Comment 19 Cedric Brun 2014-06-27 09:41:19 EDT

Ok, you can stop your upload. I got it thanks to the configuration you gave me.

Stay tuned.

Comment 20 Hendy Irawan 2014-06-27 09:58:26 EDT

Really? Wow thats great news!

Thanks for all the help and prompt response :)

Comment 21 Cedric Brun 2014-06-27 09:59:05 EDT

The problem is related to the org.eclipse.sirius.runtime.ide.xtext plugin which enable a common use of Sirius + Xtext in the same projects.

If this plugin is here, the initialization of the diagram destroy the model. If this plugin is not here, nothing bad happens.

Can you confirm you installed this integration feature explicitely ? I just want to assess how many people might get hit by this bug.

In the meantime if you don't use this feature you should remove it using "Help/Installation Details", its called "org.eclipse.sirius.runtime.ide.xtext"

Looking at the code in this plugin (which is very little) I guess we have a very subtle interaction here...

Comment 22 Hendy Irawan 2014-06-27 10:09:59 EDT

Yes. I installed xtext by searching "xtext" in "all Luna update sites" then installing all shown plugins.

Xtext and xtext-sirius are in "Modeling" group IIRC, and part of Luna update sites.

Comment 23 Cedric Brun 2014-06-27 10:17:39 EDT

I narrowed it down to the XtextResourceSet() :

in org.eclipse.sirius.common.xtext.internal.XTextResourceSetFactory :
1 - If I comment out the part which "configure" the XtextResourceSet with the project by setting up URI mappings the bug is still there.
2- If I switch to a classical ResourceSetImpl() then the model does not get corrupted.
 

Sven, does triming "src" segments from URIs ring a bell to you ?

Comment 24 Cedric Brun 2014-06-27 10:43:21 EDT

Well the code is actually quite specific about it.

In org.eclipse.xtext.resource.XtextPlatformResourceURIHandler when resolving an URI, "src" and "src-gen" segments are removed.

Comment 25 Sven Efftinge 2014-06-28 15:21:43 EDT

(In reply to Cedric Brun from comment #24)
> Well the code is actually quite specific about it.
> 
> In org.eclipse.xtext.resource.XtextPlatformResourceURIHandler when resolving
> an URI, "src" and "src-gen" segments are removed.

Yes, that is "a fix" to make platform:resource uris work with compiled bundles.
I.e. during development files that reside in projectname/src/foo/bar.ext will be located in projectname/foo/bar.ext in a built jar.

I didn't quite got the scenario where it causes trouble for you, could you try to provide a reduced example to reproduce the underlying problem?

Comment 26 Cedric Brun 2014-07-04 04:50:02 EDT

(In reply to Sven Efftinge from comment #25)
> (In reply to Cedric Brun from comment #24)
> > Well the code is actually quite specific about it.
> > 
> > In org.eclipse.xtext.resource.XtextPlatformResourceURIHandler when resolving
> > an URI, "src" and "src-gen" segments are removed.
> 
> Yes, that is "a fix" to make platform:resource uris work with compiled
> bundles.
> I.e. during development files that reside in projectname/src/foo/bar.ext
> will be located in projectname/foo/bar.ext in a built jar.
> 
> I didn't quite got the scenario where it causes trouble for you, could you
> try to provide a reduced example to reproduce the underlying problem?

The scenario is the following:
	  

When the Xtext+Sirius bridge is installed Sirius will instanciate an XtextResourceSet to operate on the models. It is a "plugin wide" choice,	   meaning if this plugin is installed, an XtextResourceSet will always be used even if you don't use any Xtext resource. We assumed an XtextResourceSet was supposed to work for non Xtext models too.
	  
In this case, the user is actually using EcoreTools but the
XtextPlatformResourceURIHandler which is installed with the
XtextResourceSet will mangle the ecore model uris which are loaded if
there is an "src" or "src-gen" fragment in the URI, effectively breaking his model when "save" is called. (Looking while debugging, it's actually the "load" which will trigger the proxy resolution and then the specific uri resolving which changes the URI.
	  
Is Sirius right in instanciating an XtextResourceSet to be able to load	  XtextResources ? 
If I'm not mistaken this is actually only required for Xtext dsls which will refer to classpath:// models, right ?

I'm attaching a project with a simple test case which only rely on EMF and Xtext, which fails with the XtextResourceSet yet passes with the ResourceSetImpl().  You can run it as a standalone Junit.

Comment 27 Cedric Brun 2014-07-04 04:51:14 EDT

Created attachment 244815 [details]
Project with Standalone JUnit test to reproduce the change in URI serialization

Comment 28 Cedric Brun 2015-03-23 12:29:33 EDT

It's been fixed in Xtext and shipped in 2.6.1.

Hendy, feel free to re-open if you still encounter the issue with an updated Xtext.