Thanks Thomas, your suggested flag has been added now.
On 22.09.2015 19:56, Thomas Watson
wrote:
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
--
Trainer, Consultant and Developer
vogella GmbH
Haindaalwisch 17a, 22395 Hamburg
Amtsgericht Hamburg: HRB 127058
Geschäftsführer: Lars Vogel, Jennifer Nerlich de Vogel
USt-IdNr.: DE284122352
Tel (040) 78804360, Fax (032) 221739404, Email: simon.scholz@xxxxxxxxxxx, Web: http://www.vogella.com
|