Community
Participate
Working Groups
See http://download.eclipse.org/eclipse/downloads/drops4/M20130703-0800/buildlogs/comparatorlogs/buildtimeComparatorUnanticipated.log.txt In maintenance branch (as in 44 builds) we have updated to the correct (current) version of PDE's API tools, so during our build the correct .api_description files, BUT, due the comparator heuristics, our distribution still pulls "old" version of bundle, since qualifier has not changed. These are the bundles that need to be "touched" ... I'd suggest by next Wednesday, if there was no other reason they are modified. eclipse.platform.ui/bundles/org.eclipse.e4.ui.model.workbench eclipse.platform.ui/bundles/org.eclipse.e4.ui.services eclipse.platform.ui/bundles/org.eclipse.e4.ui.workbench eclipse.platform.ui/bundles/org.eclipse.ui.ide eclipse.jdt.core/org.eclipse.jdt.core eclipse.platform.team/bundles/org.eclipse.compare rt.equinox.p2/bundles/org.eclipse.equinox.p2.operations
Do we need to update their versions (0.10.0 to 0.10.1 for example)? Or will we accept the qualifier goes up for Kepler SR1 is good enough since the bundles contain no code changes? PW
(In reply to comment #0) > eclipse.jdt.core/org.eclipse.jdt.core I'm not familiar with what exactly this is testing, but is it expected that issues with content of a fragment are reported against the host plugin? Is s.o. simply looking in the wrong place?
(In reply to comment #2) > (In reply to comment #0) > > eclipse.jdt.core/org.eclipse.jdt.core > > I'm not familiar with what exactly this is testing, but is it expected > that issues with content of a fragment are reported against the host plugin? > Is s.o. simply looking in the wrong place? No, nothing to do with hosts/fragments. The .api_description file is a file that "describes" the API of the bundle in such a way that it works with tools in PDE build (in the workbench) so can provide more detailed "warnings" or "errors" if someone is mis-using the methods ... you know, such as how there are some classes that are public, and not final, but should not be subclassed, etc. For the Kepler release, we happened to be be using an "old" version of the tool that produces those .api_description files. Now we've updated that tool and it produces a "new" version (that now "describes" classes/method annotated with "no not reference" annotation. But, since the source code itself didn't change, the qualifier doesn't change, so the "comparator" takes the "old" version from the repo, instead of the "new" version that was just built. Very similar to how sometimes we change the version of the compiler, and different byte codes are produced. Am I close to answering what you were asking? :) I'll attach examples of "old" and "new" .api_description files for jdt.core, and that might help make it more concrete .... if I've not been too wordy already.
Well, instead of attach, I'll just show the difference. You can download, and see the .api_description file in current jdt.core bundle ... that's the one that was produced with the "old" tool. I also downloaded the new version, from build server ..../target which was produced with "new" tool and this is the "diff": diff -r new/.api_description old/.api_description 74a75,77 > <type name="ASTRecoveryPropagator" restrictions="0"> > <method name="<init>" restrictions="8" signature="([Lorg/eclipse/jdt/core/compiler/CategorizedProblem;Lorg/eclipse/jdt/internal/compiler/parser/RecoveryScannerData;)V"/> > </type> Its is that "restrictions="8" (I believe) that means "do not reference" and is the new data produced by the new version of the PDE tool. Now I'm sure it is perfectly clear. :) Bottom line, having the "accurate" .api_description file will produce the correct warnings/errors in workbench. I'm sure others can give more details ... like how this interacts with "filters" ... I'm already over my head. :)
(In reply to comment #1) > Do we need to update their versions (0.10.0 to 0.10.1 for example)? Or will > we accept the qualifier goes up for Kepler SR1 is good enough since the > bundles contain no code changes? > > PW Yes. Even though "java code" didn't change ... contents of the bundle did ... so ... new service version. (In a perfect world, in a "service release" we'd never have any bundle that changed in qualifier only without an increment in service field ... but, admit ... technically all would still work and be fine without it ... but, semantically, I believe any change in contents, requires change in service field).
I've released the ui update as http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?h=R4_3_maintenance&id=3d877f552b33b209a537b9d9e319ff52aadb332a PW
The JDT/Core changes have been released via commit: http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?h=R4_3_maintenance&id=d8347daf466c123d6a0e3c78fc343c4c7bb9a04d
> eclipse.platform.team/bundles/org.eclipse.compare Done. Adding Pascal and Ian for p2.
According to http://download.eclipse.org/eclipse/downloads/drops4/M20130710-0800/buildlogs/comparatorlogs/buildtimeComparatorUnanticipated.log.txt only p2 is left. This also means p2 needs to create an R3_9_maintenance branch (let me know if you need help) and then an update to repositories.txt.
(In reply to comment #8) > Adding Pascal and Ian for p2. Sorry, I've been travelling. I will get to this tomorrow.
I've touched the p2 bundle in the R3_9_Maintenance branch. http://git.eclipse.org/c/equinox/rt.equinox.p2.git/commit/?h=R3_9_maintenance&id=7795cff886b8113af330ccbd6fc92af9a565bcdb
(In reply to comment #11) > I've touched the p2 bundle in the R3_9_Maintenance branch. > > http://git.eclipse.org/c/equinox/rt.equinox.p2.git/commit/ > ?h=R3_9_maintenance&id=7795cff886b8113af330ccbd6fc92af9a565bcdb I've update the repositories.txt file to use R3_9_maintenance for rt.equinox.p2 (Note: lower case 'm' as it should be :) So, I think we are done here.
