Community
Participate
Working Groups
Using new patch build from http://build.eclipse.org/eclipse/builds/4P/siteDir/updates/4.3-P-builds the patches seem to install, but do not show up in "about box" ... Oh, I may need to update the version in feature to match "RC4" (which is what I installed "into"). I'll try that first.
Correcting the "required" version of org.eclpse.pde and org.eclipse.jdt to patch did fix the main problem. (patched plugins were installed and "active" on restart. But, I think we may still need to have "Eclipse SDK" as the "root" that holds the other two patched features. The reason I think that is I could not uninstall the patches, once I had installed them. The error was Cannot complete the install because one or more required items could not be found. Software currently installed: Eclipse SDK 4.3.2.M20140212-0800 (org.eclipse.sdk.ide 4.3.2.M20140212-0800) Missing requirement: Eclipse Java Development Tools 3.9.2.v20140212-0800 (org.eclipse.jdt.feature.group 3.9.2.v20140212-0800) requires 'org.eclipse.jdt.core [3.9.2.v20140114-1555]' but it could not be found Cannot satisfy dependency: From: Eclipse Project SDK 4.3.2.v20140212-0800 (org.eclipse.sdk.feature.group 4.3.2.v20140212-0800) To: org.eclipse.jdt.feature.group [3.9.2.v20140212-0800] Cannot satisfy dependency: From: Eclipse SDK 4.3.2.M20140212-0800 (org.eclipse.sdk.ide 4.3.2.M20140212-0800) To: org.eclipse.sdk.feature.group [4.3.2.v20140212-0800] Not sure if this is "working as designed", or a p2 bug? But, it make some conceptual sense to have an Eclipse SDK patch feature, since typically someone needs to install both patches together ... would not make much sense, I'm assuming, to install one, but not the other.
FWIW, I have noticed from "history" view (in About Box) I can "revert" to previous version to effectively uninstall the patches ... not sure what the difference between "revert" and "uninstall" would be. Perhaps related to p2.metatdata ... which we may not be able to control in our patch features?
I don't think we will _need_ this ... as "udpate" seems to work for me, (since I have the P-build repo as one of my software sites, in my P-build test instance only, naturally). Conceptually, it is probably 'more correct' to have it, since I believe if someone is patching the Eclipse SDK, they do need BOTH of of the feature patches we produce ... but I think in practice, people would know to select both so we don't need to "force" them to. The one "hack" I'll mention is that if I use the current feature patches, to "update" my 4.3.2 instance, then org.eclipse.jdt.annotation 1.1.0.<qualifier> is installed into that 4.3.2 SDK, but org.eclipse.jdt.annotation 2.0.0.<qualifier> is not. I have confirmed they are both in the repository: [00:46:50] david_williams@build:/opt/public/eclipse/builds/4P/siteDir/updates/4.3-P-builds/P20140217-1600 $ ll plugins/*jdt.annotation* -rw-rw-r--+ 1 e4Build common 15K Feb 17 16:11 plugins/org.eclipse.jdt.annotation_1.1.0.v20140129-1625.jar -rw-rw-r--+ 1 e4Build common 15K Feb 17 16:11 plugins/org.eclipse.jdt.annotation_2.0.0.v20140213-0613.jar I think the reason is that there is simply nothing that specifically requires it. So, it that ok? I _think_ Srikanth said this particular bundle is "used for tests" only ... so if that's true then I'd say we are fine. BUT if it is required to be "in SDK", one way to (probably) accomplish that is to have an Eclipse SDK patch feature, which included the other two patch features, AND included this "extra bundle". But unless I hear otherwise, I'll assume we don't really need that "version 2" installed into an SDK ... and do not need and Eclipse SDK patch feature ... and we'll work out how to get that version 2 of jdt.annotations into tests, once we get to that point?
Oh, might mention the other reason we MIGHT need "Eclipes SDK patch" is to have better ability to "uninstall" it, once installed. "Uninstall" does not seem to work for the patch features, BUT seems that "restore to previous point in installation history" does work, and accomplished the same thing ... as far as I know.
(In reply to comment #3) > So, it that ok? A simple way to test this is with a test project. Steps to follow: 1) Copy-paste this code into a new project: package annos; public class AnnotatedMain { public static void main(java.lang.@NonNull String... args) {} } 2) Make sure the JRE System Library for the project is set to jdk8, JavaSE-1.8 or equivalent. 3) Find the compile error, activate Quick Fix on it by pressing Ctrl-1 and select 'Copy library with default null annotations to build path'. 4) The error is fixed.
(In reply to Timo Kinnunen from comment #5) > (In reply to comment #3) > > > So, it that ok? > > A simple way to test this is with a test project. Steps to follow: > > 1) Copy-paste this code into a new project: > > package annos; > public class AnnotatedMain { > public static void main(java.lang.@NonNull String... args) {} > } > > 2) Make sure the JRE System Library for the project is set to jdk8, > JavaSE-1.8 or equivalent. > 3) Find the compile error, activate Quick Fix on it by pressing Ctrl-1 and > select 'Copy library with default null annotations to build path'. > 4) The error is fixed. Thanks so much. I've gone through this test case and it does seem that org.eclipse.jdt.annotation_2.0.0.v20140213-0613.jar is required for it to work. I first just installed the patch into Eclipse SDK 4.3.2 (RC4) and added your test case. Saw the error, I was offered several "quick fixes", but none of were "Copy library with default null annotations to build path". I then "manually" downloaded org.eclipse.jdt.annotation_2.0.0.v20140213-0613.jar and put it in the "dropins" folder (of all things) ... restarted, "cleaned" project (just in case) and then quick fix did offer "Copy library with default null annotations to build path" and that did indeed fix the compile error. (To be honest, did not seem to change .classpath file, nor MANIFEST.MF, but did add the bundle to the "required bundles" list.) Before we "hack up" eclipse SDK though, I'll experiment with a few other things -- things that would transfer to Luna stream better.
The "two versions of jdt.annotation" was solved in bug 428099 ... so I think only reason to consider creating patch at "SDK level" is if we feared, or discovered, that many people only picked one of the patch features to install, but not the other ... and, that seems unlikely, to me, so will leave this open, but at "5" priority ... which basically means "no plans to fix", unless others think it would be a problem not to.
I'm closing this as "won't fix", since I don't think its a very useful approach. Its based on people applying the patch to only the SDK, but that would rule out people applying the patch to other EPP packages, such as Java EE package, and most others.
