Community
Participate
Working Groups
According to bug 526020 (see https://stackoverflow.com/q/46731161/6505250) it appears that an update from Oxygen.0 (4.7.0) or Oxygen.1 (4.7.1) to Oxygen.1a (4.7.1a) does not uninstall or overwrite a previously installed Java 9 BETA (http://marketplace.eclipse.org/content/java-9-support-oxygen). According to Marketplace statistics, the Java 9 BETA has been installed about 10,000 times. Workaround: uninstall Java 9 BETA manually (https://wiki.eclipse.org/FAQ_How_do_I_remove_a_plug-in%3F). Due to the changed Marketplace entry or/and the changed http://download.eclipse.org/eclipse/updates/4.7-U-builds repository this issue can not be reproduced (Java 9 BETA is no longer available in its original form). It looks like the feature ID of the Marketplace entry has changed from "org.eclipse.jdt.java9patch.feature.group" to "org.eclipse.jdt.feature.group". Maybe the problem could be fixed if the 4.7-U-builds repository contained "org.eclipse.jdt.java9patch.feature.group" with a higher version number referring to the 4.7.1a content. How can the problem be solved? If many users are affected, should they be informed? And if yes, in which way? See http://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/msg14930.html
I have opened bug 526065 to track the root cause of this problem.
(In reply to Holger Voormann from comment #1) > I have opened bug 526065 to track the root cause of this problem. Oops, wrong bug (I wish comments could be deleted)
One interesting suggestion came from David: https://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/msg14931.html
(In reply to Holger Voormann from comment #0) > Marketplace statistics, the Java 9 BETA has been installed about 10,000 times. I hope the number to be a bit smaller, assuming that many users started with a new install or EPP. Or that they did not install the BETA support into the "real" IDE. Also, the number is the total. Many users installed the support several times as it evolved. (In reply to Jay Arthanareeswaran from comment #3) > One interesting suggestion came from David: > > https://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/msg14931.html I don't think uploading yet another patch which tries to fix the issue is the right approach. Given it also means the user has to do something, we should just communicate that one can either uninstall the installed stuff and then update to 1a again (didn't try this works) or start with a fresh Oxygen 1a install or EPP.
(In reply to Dani Megert from comment #4) > I don't think uploading yet another patch which tries to fix the issue is > the right approach. I think "yet another patch" is nothing more than a best practice that should always be done, once a patch becomes released. Not to mention, there was probably an error made in specifying the maximum and minimum feature version the patch was for. Patches should be created for a very narrow range of feature versions and the maximum version should never include the to-be-released version. > Given it also means the user has to do something, ... All they should have to do is "check for updates" which appears to be how they get into the problem, to begin with. Perhaps there are not 10,000 users that will hit this problem, but what if there are 1000, or even 500, that have not yet clicked "check for updates". It would make their lives easier if that is all they had to do, instead of then learning that they had to uninstall something. I suppose you could justify it if you take the position that those that install patches are playing with fire and they understand up front that their dev environment may be burned later. But, IMHO, that's not very professional when relatively easy to do more for them. All just my opinion -- to state another point of view. This bug does not affect me!
As for testing: I just found an "old" installation with these features installed: Buildship: Eclipse Plug-ins for Gradle 2.0.2.v20170420-0909 org.eclipse.buildship.feature.group Eclipse Buildship Code Recommenders for Java Developers 2.4.9.v20170613-1301 org.eclipse.recommenders.rcp.feature.feature.group Eclipse Code Recommenders Code Recommenders Mylyn Integration 2.4.9.v20170613-1301 org.eclipse.recommenders.mylyn.rcp.feature.feature.group Eclipse Code Recommenders Code Recommenders Snipmatch 2.4.9.v20170613-1301 org.eclipse.recommenders.snipmatch.rcp.feature.feature.group Eclipse Code Recommenders EclEmma Java Code Coverage 3.0.0.201706140232 org.eclipse.eclemma.feature.feature.group Eclipse EclEmma Eclipse IDE for Java Developers 4.7.0.20170620-1800 epp.package.java Eclipse Packaging Project Eclipse Java Development Tools 3.13.0.v20170612-0950 org.eclipse.jdt.feature.group Eclipse.org Eclipse JDT (Java Development Tools) Patch with Java 9 support (BETA) for Oxygen development stream 1.1.1.v20170826-0521_BETA_JAVA9 org.eclipse.jdt.java9patch.feature.group Eclipse.org Eclipse Platform 4.7.0.v20170612-1255 org.eclipse.platform.feature.group Eclipse.org Eclipse RCP 4.7.0.v20170612-1255 org.eclipse.rcp.feature.group Eclipse.org Eclipse XML Editors and Tools 3.9.0.v201706011851 org.eclipse.wst.xml_ui.feature.feature.group Eclipse Web Tools Platform Git integration for Eclipse 4.8.0.201706111038-r org.eclipse.egit.feature.group Eclipse EGit Git integration for Eclipse - Task focused interface 4.8.0.201706111038-r org.eclipse.egit.mylyn.feature.group Eclipse EGit Java implementation of Git 4.8.0.201706111038-r org.eclipse.jgit.feature.group Eclipse JGit m2e - Maven Integration for Eclipse (includes Incubating components) 1.8.0.20170516-2043 org.eclipse.m2e.feature.feature.group Eclipse.org - m2e m2e - slf4j over logback logging (Optional) 1.8.0.20170516-2043 org.eclipse.m2e.logback.feature.feature.group Eclipse.org - m2e Mylyn Builds Connector: Hudson/Jenkins 1.15.0.v20170411-2141 org.eclipse.mylyn.hudson.feature.group Eclipse Mylyn Mylyn Context Connector: Eclipse IDE 3.23.0.v20170411-2108 org.eclipse.mylyn.ide_feature.feature.group Eclipse Mylyn Mylyn Context Connector: Java Development 3.23.0.v20170411-2108 org.eclipse.mylyn.java_feature.feature.group Eclipse Mylyn Mylyn Task List 3.23.0.v20170614-1854 org.eclipse.mylyn_feature.feature.group Eclipse Mylyn Mylyn Task-Focused Interface 3.23.0.v20170414-0629 org.eclipse.mylyn.context_feature.feature.group Eclipse Mylyn Mylyn Tasks Connector: Bugzilla 3.23.0.v20170411-2036 org.eclipse.mylyn.bugzilla_feature.feature.group Eclipse Mylyn Mylyn Versions Connector: Git 1.15.0.v20170411-2003 org.eclipse.mylyn.git.feature.group Eclipse Mylyn Mylyn WikiText 3.0.6.201703111926 org.eclipse.mylyn.wikitext_feature.feature.group Eclipse Mylyn Oomph Setup 1.9.0.v20170706-0615 org.eclipse.oomph.setup.feature.group Eclipse Oomph Project Using check for updates this was transformed into Buildship: Eclipse Plug-ins for Gradle 2.1.2.v20170807-1324 org.eclipse.buildship.feature.group Eclipse Buildship Code Recommenders for Java Developers 2.4.10.v20170911-1410 org.eclipse.recommenders.rcp.feature.feature.group Eclipse Code Recommenders Code Recommenders Mylyn Integration 2.4.10.v20170911-1410 org.eclipse.recommenders.mylyn.rcp.feature.feature.group Eclipse Code Recommenders Code Recommenders Snipmatch 2.4.10.v20170911-1410 org.eclipse.recommenders.snipmatch.rcp.feature.feature.group Eclipse Code Recommenders EclEmma Java Code Coverage 3.0.0.201706140232 org.eclipse.eclemma.feature.feature.group Eclipse EclEmma Eclipse IDE for Java Developers 4.7.1.20171009-0410 epp.package.java Eclipse Packaging Project Eclipse Java Development Tools 3.13.1.v20171009-0410 org.eclipse.jdt.feature.group Eclipse.org Eclipse JDT (Java Development Tools) Patch with Java 9 support (BETA) for Oxygen development stream 1.1.1.v20170826-0521_BETA_JAVA9 org.eclipse.jdt.java9patch.feature.group Eclipse.org Eclipse Platform 4.7.1.v20171009-0410 org.eclipse.platform.feature.group Eclipse.org Eclipse RCP 4.7.1.v20171009-0410 org.eclipse.rcp.feature.group Eclipse.org Eclipse XML Editors and Tools 3.9.1.v201707252002 org.eclipse.wst.xml_ui.feature.feature.group Eclipse Web Tools Platform Git integration for Eclipse 4.8.0.201706111038-r org.eclipse.egit.feature.group Eclipse EGit Git integration for Eclipse - Task focused interface 4.8.0.201706111038-r org.eclipse.egit.mylyn.feature.group Eclipse EGit Java implementation of Git 4.8.0.201706111038-r org.eclipse.jgit.feature.group Eclipse JGit m2e - Maven Integration for Eclipse (includes Incubating components) 1.8.2.20171007-0217 org.eclipse.m2e.feature.feature.group Eclipse.org - m2e m2e - slf4j over logback logging (Optional) 1.8.2.20171007-0217 org.eclipse.m2e.logback.feature.feature.group Eclipse.org - m2e Mylyn Builds Connector: Hudson/Jenkins 1.15.0.v20170411-2141 org.eclipse.mylyn.hudson.feature.group Eclipse Mylyn Mylyn Context Connector: Eclipse IDE 3.23.0.v20170411-2108 org.eclipse.mylyn.ide_feature.feature.group Eclipse Mylyn Mylyn Context Connector: Java Development 3.23.0.v20170411-2108 org.eclipse.mylyn.java_feature.feature.group Eclipse Mylyn Mylyn Task List 3.23.1.v20170623-0008 org.eclipse.mylyn_feature.feature.group Eclipse Mylyn Mylyn Task-Focused Interface 3.23.0.v20170414-0629 org.eclipse.mylyn.context_feature.feature.group Eclipse Mylyn Mylyn Tasks Connector: Bugzilla 3.23.1.v20170623-0008 org.eclipse.mylyn.bugzilla_feature.feature.group Eclipse Mylyn Mylyn Versions Connector: Git 1.15.0.v20170411-2003 org.eclipse.mylyn.git.feature.group Eclipse Mylyn Mylyn WikiText 3.0.6.201703111926 org.eclipse.mylyn.wikitext_feature.feature.group Eclipse Mylyn Oomph Setup 1.9.0.v20170706-0615 org.eclipse.oomph.setup.feature.group Eclipse Oomph Project In particular see this plug-in version as a witness org.eclipse.jdt.core (3.13.0.v20170826-0521_BETA_JAVA9) "Java Development Tools Core" [Active] So, yes, the bug is reproducible.
(In reply to David Williams from comment #5) > Not to mention, there was probably an error made in specifying the maximum > and minimum feature version the patch was for. Patches should be created for > a very narrow range of feature versions and the maximum version should never > include the to-be-released version. This would require a fix for bug 304156 (or some xml hacking of p2 metadata). Additionally, from another patch feature I see content.xml generated with range="0.0.0" regarding the feature being patched. Perhaps p2 is discarding some version information altogether?
(In reply to Stephan Herrmann from comment #7) > (In reply to David Williams from comment #5) > > Not to mention, there was probably an error made in specifying the maximum > > and minimum feature version the patch was for. Patches should be created for > > a very narrow range of feature versions and the maximum version should never > > include the to-be-released version. > > This would require a fix for bug 304156 (or some xml hacking of p2 metadata). > Yes, but ... back when I used to create these patches, there as an XSL transform that fixed the XML data semi-automatically. (I mean, how could you not want that! :) I do not know if that build was maintained and too lazy to look right now.
In P-build we had "org.eclipse.jdt.java9patch.feature.group". This was new feature only for BETA_JAVA9 branch. This installed new jdt.ui, jdt.core, jdt.debug plugins. Now in regular builds these plugins are installed using "org.eclipse.jdt.feature.group". Check for updates always updates "org.eclipse.jdt.feature.group". Now we have two features offering same plugins(with different versions). "org.eclipse.jdt.feature.group" has higher versions (service level is higher) "org.eclipse.jdt.java9patch.feature.group" has lower versions. I am wondering why the higher version plugins are not getting loaded into eclipse instead of plugins from "org.eclipse.jdt.java9patch.feature.group".
(In reply to David Williams from comment #5) > > Given it also means the user has to do something, ... > > All they should have to do is "check for updates" which appears to be how > they get into the problem, to begin with. I think you are not talking about the patch here but about a new version of Oxygen 1a. My comment was regarding the Java 9 patch on the Marketplace.
(In reply to Sravan Kumar Lakkimsetti from comment #9) > I am wondering why the higher version plugins are not getting loaded into > eclipse instead of plugins from "org.eclipse.jdt.java9patch.feature.group". It could be a p2 bug. Another reason could be that after installing org.eclipse.jdt.java9patch.feature.group which contains JDT*, it only allows to update JDT* via that group (just a guess).
(In reply to Sravan Kumar Lakkimsetti from comment #9) > I am wondering why the higher version plugins are not getting loaded into > eclipse instead of plugins from "org.eclipse.jdt.java9patch.feature.group". I thinks that's the very nature of patch features: they override plug-in versions of the feature being patched. (In reply to Dani Megert from comment #10) > (In reply to David Williams from comment #5) > > > Given it also means the user has to do something, ... > > > > All they should have to do is "check for updates" which appears to be how > > they get into the problem, to begin with. > > I think you are not talking about the patch here but about a new version of > Oxygen 1a. My comment was regarding the Java 9 patch on the Marketplace. I cannot read David's mind, but let's for a second consider the option to publish a new version of the Java 9 patch (just using the original patch feature ID, but with different intention now), which effectively "removes" the version lock of the original patch feature, to "open" plug-in versions up again. The effect should be, that a simple check for updates lets the .1a versions of plug-ins win, despite the patch being present. Perhaps, we could even update the patch feature to a new version of the same ID, which actually no longer is a patch, thus completely giving up the version lock? I haven't tried any of this. We're probably late for Oxygen.1a anyway, but might be good to have a solution prepared for the next round (Java 18.3)?
(In reply to Stephan Herrmann from comment #12) > which effectively "removes" the version lock of the original patch feature, Where do we have that version lock? OK, it looks like you're in the same wrong boat as David. The Java 9 patch was never consumed/installed via update software. Check for updates is useless here. The Java 9 patch has to be manually installed via Marketplace. That's why I claim this is not useful. We would have find a fix first, then respin Oxygen 1a and populate the repository. That would allow users to use "check for updates" and get the fix.
(In reply to Dani Megert from comment #10) > > I think you are not talking about the patch here but about a new version of > Oxygen 1a. My comment was regarding the Java 9 patch on the Marketplace. No, I did mean patch on Marketplace. When the Java 9 patch installed, it leaves a repository in your "available software sites", right? One of the P-build locations? If so, then "check for updates" will check it too. (If not, then never mind my whole discussion! :) (In reply to Sravan Kumar Lakkimsetti from comment #9) > In P-build we had "org.eclipse.jdt.java9patch.feature.group". This was new > feature only for BETA_JAVA9 branch. This installed new jdt.ui, jdt.core, > jdt.debug plugins. > > Now in regular builds these plugins are installed using > "org.eclipse.jdt.feature.group". > > Check for updates always updates "org.eclipse.jdt.feature.group". Now we > have two features offering same plugins(with different versions). > > "org.eclipse.jdt.feature.group" has higher versions (service level is higher) > "org.eclipse.jdt.java9patch.feature.group" has lower versions. > > I am wondering why the higher version plugins are not getting loaded into > eclipse instead of plugins from "org.eclipse.jdt.java9patch.feature.group". "Higher" is misleading, especially when it comes to features. I THINK what might be happening is that the version range for the patch feature's requirement of org.eclipse.jdt is currently specified as very wide: <versionRangeForPatch>[3.13.0.v20170531-2000,3.14.0.v20171115-0230)</versionRangeForPatch> Hence the patch feature is deemed as "still relevant" as long as the version of org.eclispe.jdt matches that range and therefore the patch feature's plugins are still used. I'm guessing. What I'm suggesting is to produce a "released" patch, that exactly matches the released version of org.eclipse.jdt: <versionRangeForPatch>[3.13.1.v20171009-0410,3.13.1.v20171009-0410)</versionRangeForPatch> And of course, the patch feature itself needs a higher version that it has had before, such as "1.2.0.qualifier". And for the best results, the released version of the patch should not build the plugins it includes, but simply "hard code" to the exact version of those released and then pulled from the repository that has already been built. (And, this part might take a little build magic to make happen correctly). There would be other mechanical changes to make as well, just to get the build to work, but that's the idea. I sincerely hope this helps to clarify the situation.
(In reply to David Williams from comment #14) > (In reply to Dani Megert from comment #10) > > > > > I think you are not talking about the patch here but about a new version of > > Oxygen 1a. My comment was regarding the Java 9 patch on the Marketplace. > > No, I did mean patch on Marketplace. When the Java 9 patch installed, it > leaves a repository in your "available software sites", right? One of the > P-build locations? If so, then "check for updates" will check it too. (If > not, then never mind my whole discussion! :) > It does seem to work that way. I just tested by installing the "bash editor" from the Marketplace, and it left an update URL is my available sites list: Update Site https://dl.bintray.com/de-jcup/basheditor Enabled
(In reply to Dani Megert from comment #13) > We would have find a fix first, then respin Oxygen 1a and populate the > repository. That would allow users to use "check for updates" and get the > fix. I think to fix via a new release repo, you would have to increase the version of "org.eclipse.jdt" to be higher than that specified in the feature patch's dependency range, which I believe to be 3.14.0.v20171115-0230, based on the value in the parent pom: <versionRangeForPatch>[3.13.0.v20170531-2000,3.14.0.v20171115-0230)</versionRangeForPatch> I say "believe" since I do not have a repo to look at, and am just looking (briefly) at the code that produces the patch build.
(In reply to Dani Megert from comment #13) > (In reply to Stephan Herrmann from comment #12) > > which effectively "removes" the version lock of the original patch feature, > > Where do we have that version lock? feature.xml of the patch feature specifies, e.g.: <plugin id="org.eclipse.jdt.core" download-size="6514" install-size="15035" version="3.13.0.v20170826-0521_BETA_JAVA9" unpack="false"/> This version has precedence over whatever version the feature org.eclipse.jdt specifies. That's what I call a version lock. In the generated content.xml the same will show up in an element <change><from>..</from><to>...</to></change>. Quoted from memory, since unfortunately I don't have a content.xml containing metadata for the jdt java9 patch feature. > OK, it looks like you're in the same wrong boat as David. The Java 9 patch > was never consumed/installed via update software. Check for updates is > useless here. The Java 9 patch has to be manually installed via Marketplace. > That's why I claim this is not useful. I believe David more than Dani in this regard :) I do have experience updating patch features. It works. David has elaborated some clarifications (first part comment 14) to which I agree. > We would have find a fix first, then respin Oxygen 1a and populate the > repository. That would allow users to use "check for updates" and get the > fix. No, not Oxygen.1a, just a new something in updates/P-builds/... But if you are saying: too late for Oxygen.1a then this is hard to deny. Things we should test before we publish our next patch feature: What exactly is the effect of a version range in the patch feature's dependency? I THINK the best a narrow version range can achieve is: signal incompatibility when attempts are made to update the base feature to a version outside the range. Is it possible to update a patch feature to a non-patch feature of the same name? This could solve the issue for the check-for-updates case. Not sure, what happens if the newer version is explicitly installed (without asking for unrelated updates from other sources - like disabled [ ] Contact other sites ...). As one step towards better understanding, I'd appreciate if someone could send / attach the content.xml that was generated for the patch feature.
(In reply to David Williams from comment #15) > > No, I did mean patch on Marketplace. When the Java 9 patch installed, it > > leaves a repository in your "available software sites", right? One of the > > P-build locations? If so, then "check for updates" will check it too. (If > > not, then never mind my whole discussion! :) > > > > It does seem to work that way. I just tested by installing the "bash editor" > from the Marketplace, and it left an update URL is my available sites list: > Update Site https://dl.bintray.com/de-jcup/basheditor Enabled Ah, I didn't know that. Good!
(In reply to Stephan Herrmann from comment #17) > (In reply to Dani Megert from comment #13) > > (In reply to Stephan Herrmann from comment #12) > > > which effectively "removes" the version lock of the original patch feature, > > > > Where do we have that version lock? > > feature.xml of the patch feature specifies, e.g.: > > <plugin > id="org.eclipse.jdt.core" > download-size="6514" > install-size="15035" > version="3.13.0.v20170826-0521_BETA_JAVA9" > unpack="false"/> > > This version has precedence over whatever version the feature > org.eclipse.jdt specifies. That's what I call a version lock. Yes, that "version lock" is with all feature.xmls we have. For Oxygen 1a we have <plugin version="3.13.50.v20171007-0855" id="org.eclipse.jdt.core" unpack="false" install-size="15131" download-size="6554"/> As we can see the version is higher. Also, the version of the feature itself is higher. So, why would it "lock" the old version instead of installing the latest plug-ins? Are we sure that only installing the BETA is causing the problem, i.e. did someone try that upgrading from 4.7 to 4.7.1a works? Maybe that particular build/package has a bundle with strict version on some JDT plug-in(s)? That would result in locking the old version.
(In reply to Dani Megert from comment #19) > So, why would it "lock" the old version instead of installing the > latest plug-ins? Because it is a patch feature that instructs p2 to use the version specified here *instead* of anything the original feature could request. See the <change> element alluded to in comment 17. If you have the corresponding content.xml I can show more details. Updating the original feature normally works, because it replaces the previous version of the same feature. But updating the original feature has no effect on the patch feature which will stay and will still override the newer version just like it did for the older version. The issue originates from having two different features influencing the version of the same plug-in(s). This is the very intended nature of a patch feature. That's why I think, there are only two ways to get out of this version lock: - uninstall the patch feature - upgrade the patch feature The second option could either relax the version constraint on the plug-in(s), or completely remove the constraint (perhaps by upgrading from a patch feature, to a same-named non-patch feature, or a patch feature that no longer includes any plugins). It may be tempting to think that a patch feature simply, blindly copies files over an existing installation - so that an update of the original feature will then overwrite the overwritten. From how understand p2's working, it's not that, but a patch feature adds new constraints (with overriding priority) to the SAT solver, and those constraints will stay until removed :)
(In reply to Stephan Herrmann from comment #17) > As one step towards better understanding, I'd appreciate if someone could > send / attach the content.xml that was generated for the patch feature. I don't have any, but in a cross-project post, Carsten Reckord offered to make some available from their internal mirror. See https://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/msg14935.html So, Carsten, adding you to CC. If you are still willing, I'd suggest zipping up the last 3 or so of those P-directories and attaching them here. The webmasters should also have backups of anything that has been on "downloads", but suspect they are more set up to simply restore things to the original location, which I'm guessing is not desired? (I am not sure why those on downloads were deleted in the first place -- normally a "no-no"). = = = = = Given the pace of working on this, my guess is it will not be fixed. But, it would be good to have the old repositories available for investigation. And, they would certainly need to be available for testing, if/when it is fixed.
Created attachment 271090 [details] JDT 4.7 P-Builds metadata Thanks for the cc David. I've attached a zip with the metadata of latest P-build sites.
All good points, but again, are we sure that only installing the BETA is causing the problem for a specific EPP, i.e. did someone try that upgrading from 4.7 to 4.7.1a works, but doesn't work with the BETA patch installed? I haven't heard that confirmation yet.
I'm not a p2 expert but I heard that one option could be to ship a new version of org.eclipse.jdt.java9patch.feature.group (the feature itself) that removes the plugins entirely - make it just a shell.
(In reply to Carsten Reckord from comment #22) > Created attachment 271090 [details] > JDT 4.7 P-Builds metadata > > Thanks for the cc David. I've attached a zip with the metadata of latest > P-build sites. Thanks, in the latest content.xml of these we find this detail of the patch feature: ----------------------- <changes> ... <change> <from> <required namespace="org.eclipse.equinox.p2.iu" name="org.eclipse.jdt.core" range="0.0.0"/> </from> <to> <required namespace="org.eclipse.equinox.p2.iu" name="org.eclipse.jdt.core" range="[3.13.0.v20170919-1301_BETA_JAVA9,3.13.0.v20170919-1301_BETA_JAVA9]"/> </to> </change> ... </changes> ----------------------- saying: look for o.e.jdt.core and whatever version (range="0.0.0") of this plugin you find in your installation, change that to version 3.13.0.v20170919-1301_BETA_JAVA9 (the same is repeated for sevaral other plugins). This just illustrates with a bit more detail, what I was trying to say before. Additionally: ------------- <required namespace="org.eclipse.equinox.p2.iu" name="org.eclipse.jdt.feature.group" range="[3.13.0.v20170531-2000,3.14.0.v20171115-0230)"/> ------------- confirms previous assumptions that the patch feature itself declares to be applicable to too wide a range of the original feature.
(In reply to Dani Megert from comment #23) > All good points, but again, are we sure that only installing the BETA is > causing the problem for a specific EPP, i.e. did someone try that upgrading > from 4.7 to 4.7.1a works, but doesn't work with the BETA patch installed? I > haven't heard that confirmation yet. anybody can test that. Result of 4.7 Java IDE package + Check for updates: Installed Software: Buildship: Eclipse Plug-ins for Gradle 2.1.2.v20170807-1324 org.eclipse.buildship.feature.group Eclipse Buildship Code Recommenders for Java Developers 2.4.10.v20170911-1410 org.eclipse.recommenders.rcp.feature.feature.group Eclipse Code Recommenders Code Recommenders Mylyn Integration 2.4.10.v20170911-1410 org.eclipse.recommenders.mylyn.rcp.feature.feature.group Eclipse Code Recommenders Code Recommenders Snipmatch 2.4.10.v20170911-1410 org.eclipse.recommenders.snipmatch.rcp.feature.feature.group Eclipse Code Recommenders EclEmma Java Code Coverage 3.0.0.201706140232 org.eclipse.eclemma.feature.feature.group Eclipse EclEmma Eclipse IDE for Java Developers 4.7.1.20171009-0410 epp.package.java Eclipse Packaging Project Eclipse Java Development Tools 3.13.1.v20171009-0410 org.eclipse.jdt.feature.group Eclipse.org Eclipse XML Editors and Tools 3.9.1.v201707252002 org.eclipse.wst.xml_ui.feature.feature.group Eclipse Web Tools Platform Git integration for Eclipse 4.8.0.201706111038-r org.eclipse.egit.feature.group Eclipse EGit Git integration for Eclipse - Task focused interface 4.8.0.201706111038-r org.eclipse.egit.mylyn.feature.group Eclipse EGit Java implementation of Git 4.8.0.201706111038-r org.eclipse.jgit.feature.group Eclipse JGit m2e - Maven Integration for Eclipse (includes Incubating components) 1.8.2.20171007-0217 org.eclipse.m2e.feature.feature.group Eclipse.org - m2e m2e - slf4j over logback logging (Optional) 1.8.2.20171007-0217 org.eclipse.m2e.logback.feature.feature.group Eclipse.org - m2e Mylyn Builds Connector: Hudson/Jenkins 1.15.0.v20170411-2141 org.eclipse.mylyn.hudson.feature.group Eclipse Mylyn Mylyn Context Connector: Eclipse IDE 3.23.0.v20170411-2108 org.eclipse.mylyn.ide_feature.feature.group Eclipse Mylyn Mylyn Context Connector: Java Development 3.23.0.v20170411-2108 org.eclipse.mylyn.java_feature.feature.group Eclipse Mylyn Mylyn Task List 3.23.1.v20170623-0008 org.eclipse.mylyn_feature.feature.group Eclipse Mylyn Mylyn Task-Focused Interface 3.23.0.v20170414-0629 org.eclipse.mylyn.context_feature.feature.group Eclipse Mylyn Mylyn Tasks Connector: Bugzilla 3.23.1.v20170623-0008 org.eclipse.mylyn.bugzilla_feature.feature.group Eclipse Mylyn Mylyn Versions Connector: Git 1.15.0.v20170411-2003 org.eclipse.mylyn.git.feature.group Eclipse Mylyn Mylyn WikiText 3.0.6.201703111926 org.eclipse.mylyn.wikitext_feature.feature.group Eclipse Mylyn In particular these Plug-ins are installed: org.eclipse.jdt (3.13.1.v20171009-0410) "Eclipse Java Development Tools" [Resolved] org.eclipse.jdt.annotation (2.1.100.v20170511-1408) "JDT Annotations for Enhanced Null Analysis" [Resolved] org.eclipse.jdt.annotation (1.1.100.v20160418-1457) "JDT Annotations for Enhanced Null Analysis" [Resolved] org.eclipse.jdt.apt.core (3.5.50.v20170920-0950) "Java Annotation Processing Core" [Starting] org.eclipse.jdt.apt.pluggable.core (1.2.0.v20170322-1054) "Java Compiler Apt IDE" [Starting] org.eclipse.jdt.apt.ui (3.5.0.v20170505-1107) "Java Annotation Processing UI" [Starting] org.eclipse.jdt.compiler.apt (1.3.50.v20170920-0950) "Java Compiler Apt" [Resolved] org.eclipse.jdt.compiler.tool (1.2.50.v20170920-0950) "Java Compiler Tool Support" [Resolved] org.eclipse.jdt.core (3.13.50.v20171007-0855) "Java Development Tools Core" [Active] org.eclipse.jdt.core.manipulation (1.9.50.v20170920-1015) "Java Code Manipulation Functionality" [Active] org.eclipse.jdt.debug (3.11.50.v20170920-1717) "JDI Debug Model" [Starting] org.eclipse.jdt.debug.ui (3.8.50.v20170928-1211) "JDI Debug UI" [Starting] org.eclipse.jdt.doc.user (3.13.50.v20171004-1030) "Eclipse Java development user guide" [Resolved] org.eclipse.jdt.junit (3.10.50.v20171004-1157) "Java Development Tools JUnit support" [Starting] org.eclipse.jdt.junit.core (3.9.50.v20170927-1941) "Java Development Tools JUnit core support" [Starting] org.eclipse.jdt.junit.runtime (3.4.650.v20170920-1015) "Java Development Tools JUnit Runtime Support" [Resolved] org.eclipse.jdt.junit4.runtime (1.1.650.v20170920-1015) "Java Development Tools JUnit4 Runtime Support" [Resolved] org.eclipse.jdt.junit5.runtime (1.0.0.v20171006-0854) "Java Development Tools JUnit5 Runtime Support" [Resolved] org.eclipse.jdt.launching (3.9.50.v20171009-0349) "Java Development Tools Launching Support" [Starting] org.eclipse.jdt.ui (3.13.50.v20170929-1653) "Java Development Tools UI" [Active] => No patch = no trouble.
Created attachment 271100 [details] patch neutralizer feature (In reply to Dani Megert from comment #24) > I'm not a p2 expert but I heard that one option could be to ship a new > version of org.eclipse.jdt.java9patch.feature.group (the feature itself) > that removes the plugins entirely - make it just a shell. Here you go
Created attachment 271101 [details] same feature as installable repo Install this feature into a broken Eclipse to "repair" it. Works. Would need some more metadata & perhaps a nice message explaining that this feature is now obsolete and can be deinstalled etc.pp.
Final checks confirm that: The Neutralizer feature can also be found via Check for Updates, if its repo is known in software sites. Furthermore, if this feature is found already at the time of updating to oxygen.1a then no broken state can ever be observed, i.e., update goes directly from pre .1a patched state, to exact .1a state with no effect of the patch. If too late for now, this is how all future patch features should go EOL.
(In reply to Stephan Herrmann from comment #29) > Final checks confirm that: > > The Neutralizer feature can also be found via Check for Updates, if its repo > is known in software sites. > > Furthermore, if this feature is found already at the time of updating to > oxygen.1a then no broken state can ever be observed, i.e., update goes > directly from pre .1a patched state, to exact .1a state with no effect of > the patch. > > If too late for now, this is how all future patch features should go EOL. Maybe we can put it into the Oxygen repo? Mickael?
Hi, I'm currently copying releases/oxygen and will add the "neutralizer" to it for testing.
To be clearer, I would like to add the neutralizer" repo to the composite list of releases/oxygen, i.e. almost everyone will see its o.e.jdt.java9patch feature as an update. However, the few people who reference the exact .X release repo (e.g. releases/oxygen/201706161000) won't see it. AFAIK, neither EPP nor platform SDK reference the child repos.
Please give a try to http://build.eclipse.org/cbi/oxygen-with-neutralizer/ This is the exact copy of oxygen, with the "neutralizer" repo added. If it works as expected, who should give a +1 for this to go live? Planning Council?
(In reply to Mikaël Barbero from comment #33) > Please give a try to http://build.eclipse.org/cbi/oxygen-with-neutralizer/ > > This is the exact copy of oxygen, with the "neutralizer" repo added. > > If it works as expected, who should give a +1 for this to go live? Planning > Council? Just a reminder that this experimental feature still has things like [Enter Feature Description here.] [Enter License Description here.] [Enter Copyright Description here.] :)
(In reply to Mikaël Barbero from comment #33) > Please give a try to http://build.eclipse.org/cbi/oxygen-with-neutralizer/ Can more people test this and report back? Thanks.
(In reply to Dani Megert from comment #35) > (In reply to Mikaël Barbero from comment #33) > > Please give a try to http://build.eclipse.org/cbi/oxygen-with-neutralizer/ > > Can more people test this and report back? Thanks. I have not tested it. Kind of hard to without a "patch repository" to apply first, right? Or have I missed that? [And, that's not the only reason, time is squeezed.] But, I will comment on the theory and practice: A. It is a clever solution that will probably accommodate the main error case you are worried about. B. But, it is not correct in terms of "feature patches" and p2. - If you look closely at the content.xml file, you'll see it will "apply anywhere, for any version". While no one, perhaps, has to (or should) remain on an older version, in this case, that is not always true for patch features. Plus, I think it will still apply to future versions -- i.e. assuming jdt changes for Oxygen.2 then the patch will still "apply" and cause things to be back level. [I suspect this could be tested by applying the proposed patch to Oxygen.1a, then updating to a 4.8 milestone. I'm not sure the code will "break", as before, but you could see what features/plugins were active. So best if you learn how to handle these the right way. Unless I have missed where is exists, As a first step to properly address this problem, I suggest the "4.7-P repository" [1] be restored from backup BUT NOT tied to "marketplace". (And, perhaps, even, the high level composite disconnected from the child repos, until a fix was ready). [I should note, the attachment kindly provided by Carsten was the 'content.xml' files only ... not the full child repositories. That was helpful, but is not sufficient to "install the patch" to reproduce the error.] Mikaël, can you restore backups? [1] On the file system, that would be the directory (and children) previously under: /home/data/httpd/download.eclipse.org/eclipse/updates/4.7-P-builds
(In reply to David Williams from comment #36) > (In reply to Dani Megert from comment #35) > > (In reply to Mikaël Barbero from comment #33) > > > Please give a try to http://build.eclipse.org/cbi/oxygen-with-neutralizer/ > > > > Can more people test this and report back? Thanks. > > I have not tested it. Kind of hard to without a "patch repository" to apply > first, right? Or have I missed that? Yes, please see comment 33: "This is the exact copy of oxygen, with the "neutralizer" repo added. "
(In reply to Dani Megert from comment #37) > (In reply to David Williams from comment #36) > > (In reply to Dani Megert from comment #35) > > > (In reply to Mikaël Barbero from comment #33) > > > > Please give a try to http://build.eclipse.org/cbi/oxygen-with-neutralizer/ > > > > > > Can more people test this and report back? Thanks. > > > > I have not tested it. Kind of hard to without a "patch repository" to apply > > first, right? Or have I missed that? > > Yes, please see comment 33: > > "This is the exact copy of oxygen, with the "neutralizer" repo added. " OK, I see you don't have a broken install and need to install the P-build first.
Could this bug be closed? I'm planning to remove test repo http://build.eclipse.org/cbi/oxygen-with-neutralizer/ shortly. Please speak if you still want to use it. Thanks.
(In reply to Mikaël Barbero from comment #39) > Could this bug be closed? > > I'm planning to remove test repo > http://build.eclipse.org/cbi/oxygen-with-neutralizer/ shortly. Please speak > if you still want to use it. Thanks. Do we have a story for Java 10, which is sure not to repeat this problem?
Any confirmation from anybody who tested the proposed fix of neutralizer repo?
(In reply to Jay Arthanareeswaran from comment #41) > Any confirmation from anybody who tested the proposed fix of neutralizer > repo? Of course I tried my proposed solution from comment 27 / comment 28 :) but that's obviously not enough testing. OTOH, it should be easy to update the "neutralizer" for the Java 10 EA patch and test from there. The one open question I see: via which repo should the neutralizer be published (eventually)? It should be a repo automatically known to Eclipse after installing the Java 10 EA patch feature, so perhaps the patch should announce a special repo dedicate just to the neutralizer, rather then scattering the neutralizer into all future release repos ...
Adjusting milestone and severity. I think this needs cooperation between - JDT (we can provide the neutralizer feature if desired) - releng (to provide a release strategy for the same) - and community (testing!).
(In reply to Stephan Herrmann from comment #43) > Adjusting milestone and severity. > > I think this needs cooperation between > - JDT (we can provide the neutralizer feature if desired) > - releng (to provide a release strategy for the same) > - and community (testing!). Do we have a proposed solution? Currently our capacity is very low. In the meantime we could add a big red disclaimer that this is not supposed to be installed in a "real" dev environment and only be used for testing until 4.7.3a is out on April 11.
(In reply to Dani Megert from comment #44) > (In reply to Stephan Herrmann from comment #43) > > Adjusting milestone and severity. > > > > I think this needs cooperation between > > - JDT (we can provide the neutralizer feature if desired) > > - releng (to provide a release strategy for the same) > > - and community (testing!). > > Do we have a proposed solution? For the technical part I proposed a neutralizer feature a la attachment 271100 [details] What's missing is a commitment to make such feature part of the upcoming releases 4.7.3a and 4.8.0 (i.e., part of all repos to which users may want to update starting from Oxygen + Java 10 patch). > In the meantime we could add a big red disclaimer that this is not supposed > to be installed in a "real" dev environment and only be used for testing > until 4.7.3a is out on April 11. Sounds like a good start, but from experience not many users actually read the text of the Market Place entry. OTOH, if we can provide a smooth updating strategy this would be much nicer message to the community, wouldn't it?
(In reply to Stephan Herrmann from comment #45) > What's missing is a commitment to make such feature part of the upcoming > releases 4.7.3a and 4.8.0 (i.e., part of all repos to which users may want > to update starting from Oxygen + Java 10 patch). Alternatively, we could create a separate update site for the neutralize IFF the Java 10 patch contributes this site to Available Software Sites. Given that the patch feature already exists out in the wild, it may, however, be too late for this.
No solution has happened for 4.7.3a. Let's hope for the best.
I had promised to restest the corresponding situation vis-a-vis the Java 11 Beta patch. Here are my results: Updating from 4.9 + Java 11 patch works with one glitch: After updating to 4.10 one patch feature is still present: - Eclipse PDE Patch with Java 11 support ... This is confirmed by still finding: - org.eclipse.pde.api.tools_1.1.400.v20180925-1121_BETA_JAVA11 I could reproduce the same result in different scenarios: Scenario 1: Original Installation: - Eclipse SDK 4.9.0.I20180906-0745 - Marketplace Client - Eclipse JDT (Java development Tools) Patch with Java 11 ... 1.1.1.v20180926-1315_BETA_JAVA11 - Eclipse PDE Patch with Java 11 support ... 1.1.1.v20180926-0819_BETA_JAVA11 Update from http://download.eclipse.org/eclipse/updates/4.10 using "Install New Software" Scenario 2: Original Installation: - Eclipse Java EE IDE for Web Developers 2018-09 (4.9.0) (20180917-1800) - Java 11 patch features - jdt 1.1.1.v20181010-1216_BETA_JAVA11 - pde 1.1.1.v20181008-0927_BETA_JAVA11 Update from http://download.eclipse.org/releases/latest using "Check for Updates" I don't know what has been fixed to make the update over the JDT patch feature work as expected. Perhaps the same solution was missed for the PDE patch?
(In reply to Stephan Herrmann from comment #48) > I had promised to restest the corresponding situation vis-a-vis the Java 11 > Beta patch. Here are my results: > > Updating from 4.9 + Java 11 patch works with one glitch: After updating to > 4.10 one patch feature is still present: > - Eclipse PDE Patch with Java 11 support ... > This is confirmed by still finding: > - org.eclipse.pde.api.tools_1.1.400.v20180925-1121_BETA_JAVA11 > > > I could reproduce the same result in different scenarios: > > Scenario 1: > Original Installation: > - Eclipse SDK 4.9.0.I20180906-0745 > - Marketplace Client > - Eclipse JDT (Java development Tools) Patch with Java 11 ... > 1.1.1.v20180926-1315_BETA_JAVA11 > - Eclipse PDE Patch with Java 11 support ... > 1.1.1.v20180926-0819_BETA_JAVA11 > Update from http://download.eclipse.org/eclipse/updates/4.10 using "Install > New Software" > > Scenario 2: > Original Installation: > - Eclipse Java EE IDE for Web Developers 2018-09 (4.9.0) (20180917-1800) > - Java 11 patch features > - jdt 1.1.1.v20181010-1216_BETA_JAVA11 > - pde 1.1.1.v20181008-0927_BETA_JAVA11 > Update from http://download.eclipse.org/releases/latest using "Check for > Updates" > > > I don't know what has been fixed to make the update over the JDT patch > feature work as expected. Perhaps the same solution was missed for the PDE > patch? This plugin is part of pde feature. the difference between jdt and pde is jdt increased minor version and pde increased service version. I am under the impression that increasing service version should be good enough for updating to the latest feature level. May be some p2 expert can comment here. Do you see org.eclipse.pde.api.tools with version 1.1.500 in your installation? actually this plugin is supposed to be replaced with the 1.1.500 version
the patch had 1.1.400 that version is supposed to be replaced with 1.1.500. Sorry for the confusion
After the upgrade to 4.10 one should see org.eclipse.pde.api.tools_1.1.400.v20180925-1121_BETA_JAVA11 replaced with org.eclipse.pde.api.tools_1.1.500 Can you please confirm whether you see a bundle with 1.1.500 version?
(In reply to Sravan Kumar Lakkimsetti from comment #51) > After the upgrade to 4.10 one should see > org.eclipse.pde.api.tools_1.1.400.v20180925-1121_BETA_JAVA11 > replaced with > org.eclipse.pde.api.tools_1.1.500 > > Can you please confirm whether you see a bundle with 1.1.500 version? org.eclipse.pde.api.tools is still at 1.1.400.v20180925-1121_BETA_JAVA11. Interestingly org.eclipse.pde.api.tools.ui is 1.1.500.v20181024-1052
(In reply to Stephan Herrmann from comment #52) > (In reply to Sravan Kumar Lakkimsetti from comment #51) > > After the upgrade to 4.10 one should see > > org.eclipse.pde.api.tools_1.1.400.v20180925-1121_BETA_JAVA11 > > replaced with > > org.eclipse.pde.api.tools_1.1.500 > > > > Can you please confirm whether you see a bundle with 1.1.500 version? > > org.eclipse.pde.api.tools is still at 1.1.400.v20180925-1121_BETA_JAVA11. > > Interestingly org.eclipse.pde.api.tools.ui is 1.1.500.v20181024-1052 I had a chance to dig deeper into this problem. Normally patches are created with a version range for the feature. We normally set version range as <major>.<minor> to <major>.<minor+1>. In this case the minor version is not incremented for pde feature. So the patch is still applicable. We will need a neutraliser similar to one done earlier (see comment 28) to rectify this
