Community
Participate
Working Groups
As assumed by Pierre-Charles David, the following change in 4.0.0 caused the save operation of representations to fail for Xbase models: https://git.eclipse.org/r/#/c/64483/ By reverting, considering file and platform resource as savable instead of only "not read-only" resources, the save operation succeeded. This just confirms the cause of the unsupported operation exception, but, as I understand it, does not solve the initial problem with read-only resources. Regards, Eirik
See also this thread for more details: https://www.eclipse.org/forums/index.php/t/1079002/
The commit which caused the regression was made for bug #483807. Any attempt to fix the regression should take that other ticket's case into account (and not cause a different regression). Erik: what's the simplest case to reproduce the issue? Can you point to a publicly accessible Xbase-based metamodel that can easily be installed to reproduce and test the issue?
(In reply to Pierre-Charles David from comment #2) > The commit which caused the regression was made for bug #483807. Any attempt > to fix the regression should take that other ticket's case into account (and > not cause a different regression). > > Erik: what's the simplest case to reproduce the issue? Can you point to a > publicly accessible Xbase-based metamodel that can easily be installed to > reproduce and test the issue? I haven't found any out-of-the-box sample for Xbase/Sirius. I created a Xtext project from the "Five simple steps to your JVM language" tutorial and added a minimal specification and representation bundle. You can clone it from: https://github.com/eirikg/XbaseSiriusIntegration I added a readme file at the root of the org.example.domainmodel bundle project. Hope you can use it to verify the exception.
Hi Eirik, I forked the XBaseSiriusIntegration project to try to reproduce your issue, and the xtend-gen folder contains only empty packages (with .gitingore) files. In order to facilitate the triage of this issue and the future homologation once corrected, could you add a commit on your project with xtend generated code. It will ease the reproduction and reduce the needed steps to use your reproduction data/project. Regards
Hi Maxime Added the generated java files and (.java_trace and .xtendbin) generated by Extend. In case you were not aware of it, the Xtend builder will generate the java files after a fork when a full build is run. To prevent it you can deactivate the Xtend builder in the preference dialog
Thanks Erik, I am aware of the Xtend builder, but having the generated code in the repo will ease the reproduction and the homologation of the issue when it will be resolved. The Xtend builder and tooling will not be required to do the validation of the correction.
I had the same problem, and I have managed to work it around by updating the XtextSavingPolicy implementation (see commit https://github.com/ujhelyiz/org.eclipse.sirius/commit/a41aafadfce1afd0ef36fee88fcd56ac2c491c84). This change simply filters all TypeResource instances from the set of saved resources, and thus avoids the entire issue. If you are interested in this fix, I'd be glad to provide it as a Gerrit change as well or am prepared to update it if something is incorrect with it.
As shown in [1], calling save on a TypeResource will throw an UnsupportedOperationException: > @Override > public void save(Map<?, ?> options) throws IOException { > throw new UnsupportedOperationException(); > } Your fix seems very interesting, do not hesitate to provide it. However, it will be very specific to this use case: I wonder if we should not also do additional tests in the saving policy to check if we need to ad a guard on resrouce.getUri().isPlatformPlugin(). Regards, ----- [1] https://github.com/eclipse/xtext-extras/blob/master/org.eclipse.xtext.common.types/src/org/eclipse/xtext/common/types/access/TypeResource.java
New Gerrit change created: https://git.eclipse.org/r/84664
(In reply to Maxime Porhel from comment #8) > > Your fix seems very interesting, do not hesitate to provide it. > However, it will be very specific to this use case: I wonder if we should > not also do additional tests in the saving policy to check if we need to ad > a guard on resrouce.getUri().isPlatformPlugin(). I have pushed the fix to Gerrit (see comment #9) The platform uri might be also necessary, however I have currently no test case available for that use case. It is possible that it works out of the box, as the read-only check in ResourceSetSync#isReadOnly might detect those element, albeit I am not sure. Regardless, I was not able to set the read only flag this method check correctly, so I opted to simply check for TypeResources. Furthermore, given that is not Xtext/Xbase-specific, that should target a different SavingPolicy implementation (but I am not sure which one).
Gerrit change https://git.eclipse.org/r/84664 was merged to [master]. Commit: http://git.eclipse.org/c/sirius/org.eclipse.sirius.git/commit/?id=4037bfb9a9ed4d7b44da5087a453bee9ee95375f
The fix is merged, thanks Zoltan! I'm leaving the ticket opened for now with the "needtest" tag, to remember to try to create a non-regression test before we close it. Given that it's Xbase specific, I'm not sure if it will be possible in a reasonable time with our current test infra.
Available in Sirius 4.1.2 (see https://wiki.eclipse.org/Sirius/4.1.2 for details).
*** Bug 521343 has been marked as a duplicate of this bug. ***
