Community
Participate
Working Groups
See bug 421706 for some context. The manifest declares it requires itself and it reexports itself: http://git.eclipse.org/c/sirius/org.eclipse.sirius.git/tree/plugins/org.eclipse.sirius/META-INF/MANIFEST.MF#n164 Require-Bundle: ... org.eclipse.sirius;visibility:=reexport No idea why you would want to require yourself let alone reexport yourself. Has this bundle ever been installed and resolved successfully? It should cause endless recursion in the resolver anytime someone requires org.eclipse.siruis. I recommend you remove the requirement on org.eclipse.sirius. I'm marking blocker since I don't see how this bundle will actually resolve successfully at runtime.
This bug does prevent "modeling EPP package" from starting up. Not sure if easier (and feasible) to leave Sirrus out of EPP package for M3 or to fix this bundle and respin _everything_. Unfortunate this has not been detected before now? How does the team do testing? Or was this some sort of last minute change?
(In reply to David Williams from comment #1) > This bug does prevent "modeling EPP package" from starting up. I cross-checked it... the modeling package is the only one that contains the sirius bundle, and is hopefully the only package that is affected.
I removed the offending line with http://git.eclipse.org/c/sirius/org.eclipse.sirius.git/commit/?id=09cf006e61252d01b8b8f8cff17c0069aea175a9 and launched a new build (https://hudson.eclipse.org/sirius/job/sirius-master/61/) as an emergency response. The build should be available in the update-site referenced by Luna in a few minutes. I have neither tested the result nor yet investigated how we got in this situation. Sorry about that.
Apparently this was introduced by me with commit http://git.eclipse.org/c/sirius/org.eclipse.sirius.git/commit/?id=0745304c5dcfd33794d483b3de844eaa02024b10 (warning: *very* large commit), but this was made at the end of September. I don't understand how we could not have experienced the issue. I just did the following check: * locally reverted the fix mentioned above * built the result (with the bug) locally * tried to install the whole content of the resulting p2 repo into Luna M2 (using a fresh eclipse-standard-luna-M2-linux-gtk-x86_64.tar.gz). I get some "errors" about p2 not being able to install 2 of the features (the EEF integration and its sources), but if I accept this "remediation plan", the installation of the rest of the features works without any other error or warning. However, I confirm that *the resulting install will not restart*. It gets stuck on the splash screen, even before showing the progress bar. I also confirm that the exact same procedure as above *works* with the most recent build at http://download.eclipse.org/sirius/updates/nightly/0.9, which includes the emergency fix.
Note that the repo with the buggy version works perfectly fine with Kepler SR1 (a fresh eclipse-standard-kepler-SR1-linux-gtk-x86_64.tar.gz): everything installs and starts fine.
(In reply to Pierre-Charles David from comment #5) > Note that the repo with the buggy version works perfectly fine with Kepler > SR1 (a fresh eclipse-standard-kepler-SR1-linux-gtk-x86_64.tar.gz): > everything installs and starts fine. I am not surprised, we have a new resolver impl in luna and this new resolver impl is not properly detecting this situation which leads to endless recursion.
FWIW, I have re-enabled the simrel.luna.runaggregator job on Hudson. It is unclear to me if your fix will get "picked up" there (to go into 'staging' soon) or not ... but, if not ... you might want to arrange for that. Thanks,
Fixed in Sirius, but the fix was too late to be picked up by Luna M3. The versions in staging and in our own update-sites are safe to install. Looking at the Git history, the bug was probably a side-effect of the project's rebranding (from the pre-Eclipse namespace into org.eclipse.sirius), maybe mixed with the EMF code generation for our meta-model. I needed several iterations of project, packages and EMF meta-model namespace adjustments before obtaining something which looks right in the org.eclipse.sirius namespace, and I guess the offending line was added at some intermediate step of this work. I was doing all my tests on helios/indigo/juno/kepler at the time, so I did not notice the bug, which only appears with luna. (BTW, maybe PDE could have a warning/error on this kind of self-requirement?) Anyway, we will be more careful in the future, and maybe include an automated install/restart test in our suite (it should be scriptable using p2 director). See also http://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/msg10062.html.
(In reply to Pierre-Charles David from comment #8) > (BTW, maybe PDE could have a warning/error on this Thanks for the information. I can see how something like this could have happened over the coarse of many refactorings. I think PDE probably should have some warning on bundles that require themselves.
Verified on 0.9.0.201312100846 build.
Released in Sirius 0.9.0
For what it's worth now, this issue was probably caused by https://bugs.eclipse.org/bugs/show_bug.cgi?id=425424. Indeed, we have 2 .ecore in the org.eclipse.sirius plug-in, each with its own .genmodel.
