Community
Participate
Working Groups
This preference may require developers to either install multiple JREs or work with unnecessary errors in their workspace, neither of which is desirable.
New Gerrit change created: https://git.eclipse.org/r/68852
Gerrit change https://git.eclipse.org/r/68852 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.team.git/commit/?id=87f3b9b8652edd636453f33ab7ba9adf862a3012
Why is a correct setup not desirable? We had too many problems in the past with commits that used APIs that were not available on the bundle's EE. This setting stopped such problems.
> Why is a correct setup not desirable? One of my objectives for this year is to lower the entry barrier for new Eclipse contributors. One prerequisite for that is to simplify or automate the setup steps. Installing multiple JREs is time consuming and hard to automate. It's also difficult on platforms such as OSX where the older JREs are hard to find. > We had too many problems in the past with commits that used APIs that > were not available on the bundle's EE. Was this before or after we had Jenkins and gerrit verifying each patch prior to submission? If it was before then we don't need this setting anymore since we now have Jenkins doing this job. If it's after, then we either need to educate our committers not to skip the review queue or fix whatever problem was present in our build servers that was prevented them from detecting such errors. Neither alternative requires making contributors install multiple JREs. It's certainly beneficial for some of us to be running multiple JREs -- particularly those of us who review community patches... but we're a minority. It should not be required for all contributors.
(In reply to Markus Keller from comment #3) > Why is a correct setup not desirable? > > We had too many problems in the past with commits that used APIs that were > not available on the bundle's EE. This setting stopped such problems. This bug was discussed during last week's status call and we agreed that this change should not have been merged. Switching important project preferences from error to warning, especially those that are known to have prevented many problems in the past, is wrong and cannot be done without getting agreement from all committers of the component. This change was pushed in a hurry without getting such agreement and without prior discussion. We also agreed that preferences of an individual contributors cannot influence the workflow of all committers of the component. Proposing such change does not mean it will or should be merged because it may not be wanted, like in this case. (In reply to Stefan Xenos from comment #4) > Installing multiple JREs is time consuming and hard to automate. This is no longer true because all team projects require now Java 1.8 so there is no reason why we would not want to get more safety by showing an error when the workspace is not configured correctly. Based on the above, I have reverted the commit from comment 2 so that we get back the right set of options: http://git.eclipse.org/c/platform/eclipse.platform.team.git/commit/?id=92faeacdde13313fa8407d7247cf189833f77f65
(In reply to Szymon Ptaszkiewicz from comment #5) > This bug was discussed during last week's status call and we agreed that > this change should not have been merged. The decision is, that all committers must decide such changes. Also, the final decision remains with the component leads.
(In reply to Dani Megert from comment #6) > (In reply to Szymon Ptaszkiewicz from comment #5) > > This bug was discussed during last week's status call and we agreed that > > this change should not have been merged. > > The decision is, that all committers must decide such changes. Also, the > final decision remains with the component leads. Thanks for the correction/clarification.
My bad. I had no idea this would be controversial. I'll go through proper channels next time I mess with project settings.
Given we have this topic open, it seems good forum to raise a few questions. 1) How many different JREs are currently required for all this strict compatibility at development time? 2) Are we *really* expecting *all* contributors to visit this page http://www.oracle.com/technetwork/java/javase/archive-139210.html to install a whack of JREs (I have Mac and Linux virtual boxes too) just to have an error free workspace in order to be able to contribute? 2) Given that this is so important, why don't the EE settings work properly? 3) If they don't work, why don't we fix them? 4) Why isn't a warning sufficient such that it *must* be an error? (I know the answer to that one, because there are 10,000 other warnings, but that begs another unrelated question doesn't it?) 5) Why can't the Gerrit/Jenkins build use the whack of JREs to verify that we (committers and contributors) don't make mistakes before they're merged to master? In any case, I wrote the Oomph setup to automatically change these settings because in my opinion this is a major barrier to entry; with Oomph we don't let barriers get in the way. We try to find a way to work around those, because otherwise nothing improves. Hopefully we can make opt-out optional 491355: Provide some way for users to opt out of specific oomph rules inherited from the project setup https://bugs.eclipse.org/bugs/show_bug.cgi?id=491355 All that being said, I certainly agree that things like this should be decided as a team. Just keep in mind that that the team can be very large or very small depending on what the small team decides.
Fyi, in Platform UI (recently voted to the most open project) we have this preference set to a warning. And the Gerrit validation build find these issues. +1 for reducing it from error to warning.
+1 for reducing it from error to warning. The concern expressed in comment #3 no longer applies due verification of Gerrit changes by the Hudson builds.
+1 for setting this to "not an error" However I'd say that "ignore" would be preferable to "warning" since warnings are things we want the end user to do something about and - for the vast majority of contributors - there is no added benefit to having a bunch of extra JVMs installed. I'd also say that this should apply to every eclipse.org subproject with gerrit, not just team (or even just platform)... so perhaps we should move this discussion to the cross-team issues mailing list?
(In reply to Stefan Xenos from comment #12) > +1 for setting this to "not an error" > > However I'd say that "ignore" would be preferable to "warning" since > warnings are things we want the end user to do something about and - for the > vast majority of contributors - there is no added benefit to having a bunch > of extra JVMs installed. > > I'd also say that this should apply to every eclipse.org subproject with > gerrit, not just team (or even just platform)... so perhaps we should move > this discussion to the cross-team issues mailing list? A compromise would be to not set this in the project. That way, those developers who want to set this as an error can do so. Or they can set it to 'Info' or 'Ignore'.
Yes, it's the project-specific nature of the setting that makes it particularly problematic. It's easy to set a global preference and with Oomph a developer can set this preference once and for all for all their workspaces and IDEs. But a project-specific preference can only be changed by making the git clone dirty.
(In reply to Dani Megert from comment #13) > A compromise would be to not set this in the project. That way, those > developers who want to set this as an error can do so. Or they can set it to > 'Info' or 'Ignore'. @Szymon, are you as project lead OK with this suggestion? I think this would also the problem for the constributors, still allow you to have this as error for you.
(In reply to Lars Vogel from comment #15) > @Szymon, are you as project lead OK with this suggestion? I think this would > also the problem for the constributors, still allow you to have this as > error for you. Can you translate this to English please ;-)
(In reply to Dani Megert from comment #16) > (In reply to Lars Vogel from comment #15) > > @Szymon, are you as project lead OK with this suggestion? I think this would > > also the problem for the constributors, still allow you to have this as > > error for you. > > Can you translate this to English please ;-) @Szymon, are you, as project lead, OK with this suggestion from Dani?
(In reply to Lars Vogel from comment #17) > @Szymon, are you, as project lead, OK with this suggestion from Dani? If we can make this a platfrom-wide policy for at least all components that are part of Eclipse SDK, then I think it makes sense.
Renaming bug to match the current proposal.
I'm not sure what component to assign this to now, though.
(In reply to Stefan Xenos from comment #20) > I'm not sure what component to assign this to now, though. As it affects the whole SDK, I think the PMC component is right. I bring in out in the next PMC meeting.
The PMC decided that all project from the top-level project should remove their project specific settings for the Java Compiler -> Building settings. This eaves it to the developer to configure this. This way, each developer can decide, if he wants to see an error or warning for "strictly compatible JRE". I will provide a patch for team. @Stefan, maybe you can provide patches for other projects which use project specific settings for the "Building" preferences.
New Gerrit change created: https://git.eclipse.org/r/70490
(In reply to Lars Vogel from comment #22) > The PMC decided that all project from the top-level project should remove > their project specific settings for the Java Compiler -> Building settings. The decision was only made for the concrete setting mentioned int his bug and not for all settings on that page. For details see https://wiki.eclipse.org/Eclipse/PMC#Meeting_Minutes
(In reply to Dani Megert from comment #24) > (In reply to Lars Vogel from comment #22) > > The PMC decided that all project from the top-level project should remove > > their project specific settings for the Java Compiler -> Building settings. > > The decision was only made for the concrete setting mentioned int his bug > and not for all settings on that page. For details see > https://wiki.eclipse.org/Eclipse/PMC#Meeting_Minutes Is that possible? AFAIK you cannot remove a single setting.
(In reply to Lars Vogel from comment #25) > (In reply to Dani Megert from comment #24) > > (In reply to Lars Vogel from comment #22) > > > The PMC decided that all project from the top-level project should remove > > > their project specific settings for the Java Compiler -> Building settings. > > > > The decision was only made for the concrete setting mentioned int his bug > > and not for all settings on that page. For details see > > https://wiki.eclipse.org/Eclipse/PMC#Meeting_Minutes > > > Is that possible? AFAIK you cannot remove a single setting. Sure. It's per single pref.
(In reply to Dani Megert from comment #26) > Sure. It's per single pref. I don't see how to do this via the user interface. The combo has warning, error, info and ignore. So your suggestion is to delete this directly from the .settings. Correct?
> delete this directly from the .settings I believe that would work. Let's try it!
(In reply to Lars Vogel from comment #27) > (In reply to Dani Megert from comment #26) > > Sure. It's per single pref. > > I don't see how to do this via the user interface. The combo has warning, > error, info and ignore. So your suggestion is to delete this directly from > the .settings. Correct? Yep.
New Gerrit change created: https://git.eclipse.org/r/70866
New Gerrit change created: https://git.eclipse.org/r/70870
New Gerrit change created: https://git.eclipse.org/r/70871
New Gerrit change created: https://git.eclipse.org/r/70872
I've attached the changes for JDT UI, debug, core, and the related oomph setup files... if someone would be kind enough to take a look.
New Gerrit change created: https://git.eclipse.org/r/70874
New Gerrit change created: https://git.eclipse.org/r/70877
New Gerrit change created: https://git.eclipse.org/r/70880
New Gerrit change created: https://git.eclipse.org/r/70882
New Gerrit change created: https://git.eclipse.org/r/70892
Gerrit change https://git.eclipse.org/r/70877 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.runtime.git/commit/?id=a80e7d1ed24e369941218741e62f6eca298a6fd4
Gerrit change https://git.eclipse.org/r/70874 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.team.git/commit/?id=a0cc0d24778652f7ab3ce880ff84fde0b082469d
Gerrit change https://git.eclipse.org/r/70880 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.git/commit/?id=ddea3b8e87737dbf830ccde4162c0e0eee12646c
New Gerrit change created: https://git.eclipse.org/r/70924
Gerrit change https://git.eclipse.org/r/70924 was merged to [master]. Commit: http://git.eclipse.org/c/equinox/rt.equinox.p2.git/commit/?id=30aa50233fe07edc71b6729f7690454170215932
Gerrit change https://git.eclipse.org/r/70870 was merged to [master]. Commit: http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?id=ed815ac91a3ab8ae8aeee6cb2d66e5166ceefe2a
Gerrit change https://git.eclipse.org/r/70892 was merged to [master]. Commit: http://git.eclipse.org/c/pde/eclipse.pde.ui.git/commit/?id=7898353da87031c0d716dcdcfc9f70a32649b671
Gerrit change https://git.eclipse.org/r/70866 was merged to [master]. Commit: http://git.eclipse.org/c/jdt/eclipse.jdt.ui.git/commit/?id=281d688ca74b83e8bfb1e1e0d24dddf85156506c
(In reply to Eclipse Genie from comment #33) > New Gerrit change created: https://git.eclipse.org/r/70872 How about Platform Debug and Core changes? Are you planning to provide it ?
(In reply to Sarika Sinha from comment #48) > (In reply to Eclipse Genie from comment #33) > > New Gerrit change created: https://git.eclipse.org/r/70872 > > How about Platform Debug and Core changes? Are you planning to provide it ? Typo, Platform Debug and Ant !!!
> Typo, Platform Debug and Ant !!! As far as I can tell, none of the Ant projects override this preference. If you're aware of one that I missed, please contribute a patch. I'll follow up with a patch to Debug.
New Gerrit change created: https://git.eclipse.org/r/70985
Please see attached for the change to debug.
(In reply to Stefan Xenos from comment #50) > > Typo, Platform Debug and Ant !!! > > As far as I can tell, none of the Ant projects override this preference. If > you're aware of one that I missed, please contribute a patch. > > I'll follow up with a patch to Debug. We have it in ant.core, ant.ui, ant.launching, ant.tests.core, ant.tests.ui where the preference is defaulted to error. I will do the required changes.
Gerrit change https://git.eclipse.org/r/70872 was merged to [master]. Commit: http://git.eclipse.org/c/jdt/eclipse.jdt.debug.git/commit/?id=e9ff639d4730843faa8a537ee6a43d3ff3f1caa5
Gerrit change https://git.eclipse.org/r/70985 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.debug.git/commit/?id=9756a0418a88aaf12d1d231511891014825b6712
Thanks, Sharika!
Gerrit change https://git.eclipse.org/r/70871 was merged to [master]. Commit: http://git.eclipse.org/c/oomph/org.eclipse.oomph.git/commit/?id=59c26d1606107b4a9ce7ad47521e997c22a8444e
I think there's just one last patch left before we can mark this as fixed. Ed, can you take a look?
The remaining patch is probably https://git.eclipse.org/r/#/c/70882/
I have run a search query against all git repositories used in Eclipse SDK and the setting is still present in the following repositories: eclipse.platform.releng, eclipse.platform.resources, eclipse.platform.text, eclipse.platform.ui.tools and eclipse.platform.ui.
(In reply to Szymon Ptaszkiewicz from comment #60) > I have run a search query against all git repositories used in Eclipse SDK > and the setting is still present in the following repositories: > eclipse.platform.releng, eclipse.platform.resources, eclipse.platform.text, > eclipse.platform.ui.tools and eclipse.platform.ui. Please file separate bugs reports. I'm considering the PMC's task done.
(In reply to Dani Megert from comment #61) > Please file separate bugs reports. Filled Bug 492875 for: - eclipse.platform.text, - eclipse.platform.ui.tools - eclipse.platform.ui
Filed bug 492911 for the changes to the resources plugin.
Filed bug 492911 for the changes to releng
(In reply to Stefan Xenos from comment #64) > Filed bug 492911 for the changes to releng My bad. That should have been bug 492912.
*** Bug 493261 has been marked as a duplicate of this bug. ***
I think we should also set the "Execution Environment references not checked because no Environment descriptions are installed" to warning. I clone this bug so that we can discuss that.
Looks like we forgot the Ant projects. Created Bug 502245 for that.
