Community
Participate
Working Groups
Original post from Christoph Baumann: https://discuss.gradle.org/t/eclipse-does-not-prompt-for-workspace-any-more-after-installing-buildship/11605 "After I installed the BuildShip plugin, Eclipse (Luna) stopped asking me which workspace to open at startup and instead just opens the default workspace. Starting Eclipse with the -clean option temporarily solves the issue, but the problem reappears after some days. At first I thought that this must be a coincidence, because there seems to be no logical connection between the BuildShip plugin and the workspace chooser. But after experiencing the same behaviour on another machie, I started wondering if this is happening to some of you guys to."
GitHub Pull Request 173 created by [SimonScholz] https://github.com/eclipse/buildship/pull/173
Fixed. Thanks, Simon, for the PR.
I don't think the fix is correct. You are attempting an eager persistent activation of the contributing bundle with a call to: bundle.start(); That causes the OSGi framework to persistently mark that bundle for eager activation upon restart. That is why it appears that the framework cache is 'corrupt'. Because on restart the bundle you persistently activated will be activated very early in the startup process which will likely cause it to touch preferences 'too early' which usually results in no workspace prompt. Instead I recommend you eagerly start the bundle with the transient flag: bundle.start(Bundle.START_TRANSIENT);
GitHub Pull Request 174 created by [SimonScholz] https://github.com/eclipse/buildship/pull/174
Thanks a lot for helping again with an OSGi issue, Thomas. I just added a PR, which uses the suggested flag.
Thanks a lot Thomas. I've integrated the PR with your fix.
Can you (briefly) explain why you eagerly call 'start' to begin with? That's a bit unusual, right? (Can easily add to the "startup time" in all the EPP packages you are part of). It appears your core plugin starts (anyway) ... what starts it so early? and, then you also start EXTENSION_ATTRIBUTE_PLUGIN_ID. Why must it be started, instead of something just using one of it's classes? [And, I'm not saying there is never a reason to ... I'm just trying to understand the "big picture" better. Is this "startup costs" something that will effect non-Gradle users? Or, only if using Gradle? = = = = Any potential work arounds? Why did this "just start now"?
The affected code is in org.eclipse.buildship.core.launch.internal.BuildExecutionParticipants#activateParticipantPlugins. This code does not get called until the user explicitly chooses to run a Gradle task in the UI (by then, Eclipse is already fully up and running). So, there is nothing that Buildship triggers on Eclipse startup. The side-effect of trying to start an already activated bundle (not at start-up!) is what I called the 'corrupted' file (correctly explained by Thomas in his comment). This side-effect of the corrupted file then becomes visible the next time Eclipse is started. This should all be fixed now in 1.0.5 based on the fix by Simon and Thomas.
If someone never launches Gradle from within Eclipse/Buildship, he will never experience the problem of this issue.
(In reply to Etienne Studer from comment #9) > If someone never launches Gradle from within Eclipse/Buildship, he will > never experience the problem of this issue. Thanks for the additional detail and explanations. And thanks to you, Tom, for quickly spotting the root problem, which was accidentally causing a bundle to start early, the next time the workbench comes up. (I think I know some others that should scan their code for bundle.start() instead of bundle.start(Bundle.START_TRANSIENT) :) If not obvious, BTW, a semi-workaround is for users to specify -data <desiredWorkspace> on the command line. I'm assuming that works (since it has in similar cases). Not as nice as a dialog with "memory", but, ... better than nothing. (And, better than changing in preferences, and then restarting). While no one from buildship ever asked explicitly for a respin of the Sim. Release, it was implied by some on cross-project list, so I'll answer here, since primarily relevant to buildship project. This is a pretty good example of "not bad enough for a respin". And, I am not saying it is not bad ... just not "blockingly bad", does no damage, is not reputation busting embarrassing; it does have some a "cross-project" impact, but is relatively small; does not prevent buildship users from applying the fix from your own buildship project repository; and there is at least something of a workaround. So, I'd suggest you prepare your 1.0.5 release in your own project, and those that want to "get the fix" can update to it. Granted, ... they have to know about it, and "pick it" to install ... i.e. will not be an "automatic" update for EPP packages .. but, that's a larger problem. Feel free to ask, if any questions (or, clarify, if I've misunderstood anything). Thank again to all!
Thanks for the clarification, Dave. The full fix incl. the contribution from Thomas is available in Buildship 1.0.5, released a few hours ago.
is buildship part of any EPP?
(In reply to Jonas Helming from comment #12) > is buildship part of any EPP? Yes, it is included in three packages: Java, Java EE, RCP/RAP.
(In reply to Markus Knauer from comment #13) > (In reply to Jonas Helming from comment #12) > > is buildship part of any EPP? > > Yes, it is included in three packages: Java, Java EE, RCP/RAP. Sorry. I take the liberty to reopen. Will this bug affect (roughly ~2/3 of) all Eclipse users? If not, please explain why "some users" wont be affected by this. If so, this is a BLOCKER.
The method, which is the root cause of this issue only gets called, if a Gradle task is launched. Therefore "only" Gradle user will be affected by this. But since Buildship is new and lots of user might want to test it is still really bad to have this bug in EPP.
I don't understand the reason for reopening this issue. It has been fixed and is available in Buildship 1.0.5. Whether it triggers a respin of Mars 1 or not seems another question to me.
(In reply to Simon Scholz from comment #15) Simon, thanks for repeating and summarizing the essence from above. Etienne, there is yet no bug about the respin, right? Do you mind keeping this bug open for a few more days? David, I agree that it's not a blocker. But... I actually do think "it is reputation busting embarrassing" from a marketing perspective: I question that users may draw the conclusion that this problem comes from using Gradle, and thus, know how to fix it (by updating to 1.0.5.). I think this bug affects core functionality of the Java IDE and thus should be fixed before the release. I clearly vote for a respin.
(In reply to Markus Knauer from comment #13) > (In reply to Jonas Helming from comment #12) > > is buildship part of any EPP? > > Yes, it is included in three packages: Java, Java EE, RCP/RAP. Correction... my fault: Java, Committers, RCP/RAP packages.
Seems like SimRel and EPP contain BuildShip 1.0.2, which is not hurt by this critical bug, so it seems like there is no reason to worry and debate about Mars.1 ! Great! I'm marking this bug as resolved, Following discussions about BuildShip integration in SimRel, if necessary, should be tracked in different bugs, against SimRel and/or EPP, and linking to this one.
Issue resolved in BuildShip.
This bug has been in the code for many months (undetected and unreported) and is in all Buildship versions < 1.0.5.
Thought I'd add a reminder to Buildship team ... even if we do a respin, or even if someone with an existing install, with the problem already, upgrades to 1.0.5, that upgrade, by itself, I *think* will not fix those existing installs. By that point bundle has been marked for "early startup" and my guess is that an update, by itself does not "clear" that. (Tom, please clarify, if you know right off). So, I suggest the Buildship team to be sure to test that scenario, and may still have to "socialize" the work around, or ... I guess ... encourage a fresh install? I'm not sure "-clean" will fix the problem, either? But, would be good to know the results of your continued testing. Thanks,
When you are ready, please contribute to the Mars_maintenance.1 branch, of the simrel.build repo. (And, just as well do it directly ... no plans to change Gerrit job). And, just as well update the Mars_maintenance release too, so "in sync".
(In reply to David Williams from comment #22) > Thought I'd add a reminder to Buildship team ... even if we do a respin, or > even if someone with an existing install, with the problem already, upgrades > to 1.0.5, that upgrade, by itself, I *think* will not fix those existing > installs. By that point bundle has been marked for "early startup" and my > guess is that an update, by itself does not "clear" that. (Tom, please > clarify, if you know right off). > > So, I suggest the Buildship team to be sure to test that scenario, and may > still have to "socialize" the work around, or ... I guess ... encourage a > fresh install? I'm not sure "-clean" will fix the problem, either? But, > would be good to know the results of your continued testing. > > Thanks, After upgrading to Buildship 1.0.5, the problem seems to go away by itself. Nevertheless, we have informed our users here: https://discuss.gradle.org/t/buildship-1-0-5-is-now-available/11850
(In reply to David Williams from comment #23) > When you are ready, please contribute to the Mars_maintenance.1 branch, of > the simrel.build repo. (And, just as well do it directly ... no plans to > change Gerrit job). > > And, just as well update the Mars_maintenance release too, so "in sync". Thanks, David. We will do this first thing this morning (European TZ).
(In reply to David Williams from comment #23) > When you are ready, please contribute to the Mars_maintenance.1 branch, of > the simrel.build repo. (And, just as well do it directly ... no plans to > change Gerrit job). > > And, just as well update the Mars_maintenance release too, so "in sync". Hi David, The simrel git repository is updated. The 'clean build' job on Hudson has finished and the http://download.eclipse.org/releases/maintenance update site contains Buildship 1.0.5.
*** Bug 473005 has been marked as a duplicate of this bug. ***
Setting status to closed.
