10:06 a.m.
FYI.
Since we don't include Buildship, this probably won't affect us much.
But it DOES mean that some users of Mars.1 EPP bundles (who also use
Buildship) might hit the problem mentioned below, unless they upgrade
to Mars.1a.
Nick
---------- Forwarded message ----------
From: Doug Schaefer <dschaefer(a)qnx.com>
Date: Wed, Sep 23, 2015 at 9:55 AM
Subject: [eclipse.org-planning-council] FW: Respin of Mars 1 for Buildship
To: Eclipse Planning Council <eclipse.org-planning-council(a)eclipse.org>
For your consideration.
I’ve commented on the cross-projects list with my thinking here. Since
we don’t seem to have a way to ensure we get maintenance releases of
the projects to users of the EPP packages, we have to do what’s right
for the users of those packages and fix these problems how we can. And
unfortunately, right now, that requires a respin.
Doug.
From: <tools-pmc-bounces(a)eclipse.org> on behalf of Etienne Studer
<etienne(a)gradle.com>
Reply-To: Tools PMC mailing list <tools-pmc(a)eclipse.org>
Date: Wednesday, September 23, 2015 at 7:28 AM
To: Tools PMC mailing list <tools-pmc(a)eclipse.org>
Subject: [tools-pmc] [Request] Respin of Mars 1
Hello
I’d like to ask the Tools PMC to do a re-spin of Mars 1 due to a
critical bug in Buildship 1.0.3, the Buildship version that is
currently in Mars 1 RC4 and its EPP packages (Java / Committer / RCP).
The bug has been fixed in Buildship 1.0.5.
See also https://bugs.eclipse.org/bugs/show_bug.cgi?id=478151
Some details below:
What is the bug?
Buildship calls Bundle#start() to eagerly activate its UI plugin. This
is a problem since it causes the OSGi framework to persistently mark
that bundle for eager activation upon restart. Once Eclipse is
restarted, the bundle that was persistently activated will be
activated very early in the startup process which will likely cause it
to touch preferences 'too early' which results in no workspace prompt
and the default workspace being used.
See also https://bugs.eclipse.org/bugs/show_bug.cgi?id=478054.
How does the bug become apparent?
Once a Gradle task has been launched from the Tasks View, the user
will not be prompted for the workspace anymore the next time he starts
Eclipse, but instead the very default Eclipse workspace is used.
Who is affected?
The bug affects those users (and only those users) that run a Gradle
task through Buildship from within Eclipse.
When was the bug identified and investigated?
We were able to confirm that this is a Buildship bug yesterday. We
also found the cause and a fix yesterday. All Buildship versions <
1.0.5 contain the bug.
When was this bug introduced?
The bug is there since June 6th, as we have found out in retrospect (yesterday).
Why was this bug not found earlier?
Most likely, because the relation between Buildship and how the bug
manifests itself in Eclipse is not obvious to the user observing the
issue.
Is there a fix available?
Yes, the fix is available in Buildship 1.0.5, available as of last
night. It has been confirmed by three Gradle forum users that the
issue has been resolved in Buildship 1.0.5 .
I believe that it is critical for the introduction of Buildship into
the Eclipse SimRel and the Eclipse distributions that we get this fix
in for Mars 1. Otherwise, it will be a bad start for Buildship,
especially considering that the bug was known before the release and a
fix would have been available. Also, users might associate the bug
with a general Eclipse problem, which could cause unfair frustrations
about the Eclipse IDE.
Thanks for considering it.
Regards, Etienne
---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential
information, privileged material (including material protected by the
solicitor-client or other applicable privileges), or constitute
non-public information. Any use of this information by anyone other
than the intended recipient is prohibited. If you have received this
transmission in error, please immediately reply to the sender and
delete this information from your system. Use, dissemination,
distribution, or reproduction of this transmission by unintended
recipients is not authorized and may be unlawful.
_______________________________________________
eclipse.org-planning-council mailing list
eclipse.org-planning-council(a)eclipse.org
https://dev.eclipse.org/mailman/listinfo/eclipse.org-planning-council
IMPORTANT: Membership in this list is generated by processes internal
to the Eclipse Foundation. To be permanently removed from this list,
you must contact emo(a)eclipse.org to request removal.
--
Nick Boldt :: Productization Lead :: JBoss Tools & Dev Studio :: Red Hat, Inc.
http://nick.divbyzero.com