Hi
Dave Williams gave directions on how to proceed with this problem:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=478054
In short, there will be no respin of Mars 1.
Buildship 1.0.5 is available in the marketplace and contains the fix for this
issue, incl. the contribution from Thomas.
Thanks for everyone’s input and sorry for the disturbance this issue created.
Regards, Etienne
On 22.09.2015, at 19:07, Etienne Studer <etie...@gradle.com> wrote:
> 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@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
