Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [] Respin of Mars 1 for Buildship

+1 for a week. It's essentially RC5. In my corporate world, we do RC's until we get it right but keep a sharp eye on the content of them to make sure we eventually get it right ;).

No comment on the JGit issue. But since it's serious enough to bring up at this point, I'll trust the team that it is needed.


From: [] on behalf of David M Williams [david_williams@xxxxxxxxxx]
Sent: Wednesday, September 23, 2015 11:37 AM
To: Eclipse Planning Council private list
Subject: Re: [] Respin of Mars 1 for Buildship

This has formally met the criteria for an exception. (I'll wait a little longer to make it official, to give a few hours for objections, if anyone dares :).

But, two more questions for your Planning Council member input:

1. How long should we delay the formal release? I was thinking of a full week (to give time for some adopter and community confirmation for the new builds). Markus was thinking of three days (Monday instead of Friday).

I'd like to hear if others have an opinion? Keep in mind, M2 is due next Friday too. But, also keep in mind, in the past, doing a rebuild has sometimes "changed the repository" in unexpected ways, since p2 is "pulling" from a reduced set of artifacts, so sometimes comes up with a better solution than it would when working with more artifacts ("better" in terms of reduced numbers .. but ... in some rare cases, might not be what's desired).

2. Do you think it worth picking up another fix? From JGit, so that only one version of com.jcraft.jsch is in the repository?  See bug 477148 and bugs it references for the problem. The fix is for them to change what is "included" in their feature. I do not want to "pile on" just because we are doing a respin, but I do think that issue has the *potential* to be nastier than the Buildship bug. I say "potential" just because there may not be a work around for it, if someone does get "class loader constraint" violations, but am not sure. And, also not sure how many scenarios the problem might manifest itself in. There's only been one concrete problem reported, that wasn't reproducible after a re-install ... so seems related to the order in which things are done. And, FWIW, doing a re-spin would not magically leave out the "lower" version of com.jcraft.jsch, since both 51 and 53 are (currently) explicitly included by features.

Advice welcome,

From:        Markus Knauer <mknauer@xxxxxxxxxxxxxxxxx>
To:        Eclipse Planning Council private list <>,
Date:        09/23/2015 11:01 AM
Subject:        Re: [] Respin of Mars 1 for Buildship
Sent by:


I tested the behaviour and the fix this afternoon, and to me it seems to be worth a rebuild to avoid a bad user experience of many users who will be testing the new Buildship Gradle tooling.


On 23 September 2015 at 16:56, Max Rydahl Andersen <manderse@xxxxxxxxxx> wrote:
On 23 Sep 2015, at 15:55, Doug Schaefer wrote:

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.




From: <
tools-pmc-bounces@xxxxxxxxxxx<mailto:tools-pmc-bounces@xxxxxxxxxxx>> on behalf of Etienne Studer <etienne@xxxxxxxxxx<mailto:etienne@xxxxxxxxxx>>
Reply-To: Tools PMC mailing list <
Date: Wednesday, September 23, 2015 at 7:28 AM
To: Tools PMC mailing list <

Subject: [tools-pmc] [Request] Respin of Mars 1


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

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

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.

_______________________________________________ mailing list

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@xxxxxxxxxxxto request removal.

_______________________________________________ mailing list

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@xxxxxxxxxxxto request removal.


EclipseSource Group
Telefon: +49 721 664733-0 (GMT +2)
Telefax: +49 721 66473329

Innoopract Informationssysteme GmbH
Lammstrasse 21, 76133 Karlsruhe Germany
General Manager: Jochen Krause
Registered Office: Karlsruhe, Commercial Register Mannheim HRB 107883
_______________________________________________ mailing list

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@xxxxxxxxxxx to request removal.

Back to the top