Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cross-project-issues-dev] Eclipse Mars 1 RC4 issue with Buildship / workspace prompt

I think the fix in incorrect.  I added a comment to the defect with the details.


From:        Etienne Studer <etienne@xxxxxxxxxx>
To:        Cross project issues <cross-project-issues-dev@xxxxxxxxxxx>
Date:        09/22/2015 12:08 PM
Subject:        [cross-project-issues-dev] Eclipse Mars 1 RC4 issue with Buildship        / workspace prompt
Sent by:        cross-project-issues-dev-bounces@xxxxxxxxxxx


In our Gradle forum, a user recently reported a problem with not seeing the workspace prompt when starting Eclipse and suspected that it is related to Buildship. We created a BugZilla issue for this. After deeper investigations, Simon Scholz from Vogella GmbH eventually found the problem and a fix:

When launching a Gradle build with Buildship 1.0.3, an extension point is used to start the Buildship UI bundle. The code in Buildship which is responsible for starting the Buildship UI bundle is called even when the UI bundle is already active. This causes the /configuration/org.eclipse.osgi/{x} file to change into an unstable state, and as a consequence the workspace prompt is not shown anymore when starting Eclipse. The plugin activation code has been in Buildship for a very long time but until very recently, nobody had ever experienced this problem.

Buildship 1.0.4, built today, contains a patch for this issue by only starting the UI bundle programmatically if the bundle is not already in state “ACTIVE". This avoids the corruption of /configuration/org.eclipse.osgi/{x} and thus the workspace prompt is always properly shown when starting Eclipse.

It seems like there is an underlying bug in the org.osgi.framework.Bundle.start() method that causes the /configuration/org.eclipse.osgi/{x} to become corrupt when start() is called and the bundle is already "ACTIVE". Unfortunately, we were not able to read the /configuration/org.eclipse.osgi/{x} file and thus we were not able to confirm this theory, nor could we figure out what was actually changed with tools like kdiff3.

How should we proceed from here?

Kind regards, Etienne
cross-project-issues-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit

Back to the top