| Thanks, Thomas. I have applied your improvement to our fix. It is in Buildship 1.0.5, released just a few minutes ago.
Regards, Etienne
I think the fix in https://bugs.eclipse.org/bugs/show_bug.cgi?id=478054is incorrect. I added a comment to the defect with the details.
Tom
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
Hi
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/framework.info.{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/framework.info.{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/framework.info.{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/framework.info.{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
cross-project-issues-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev |
