Bugzilla – Full Text Bug Listing
| Summary: | Update to latest JUnit (4.10) | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | Markus Keller <markus.kell.r> | ||||||
| Component: | UI | Assignee: | Markus Keller <markus.kell.r> | ||||||
| Status: | VERIFIED FIXED | QA Contact: | |||||||
| Severity: | normal | ||||||||
| Priority: | P3 | CC: | daniel_megert, david_williams, john.arthorne, markus.kell.r, remy.suen | ||||||
| Version: | 3.8 | ||||||||
| Target Milestone: | 3.8 M7 | ||||||||
| Hardware: | All | ||||||||
| OS: | All | ||||||||
| Whiteboard: | |||||||||
| Bug Depends on: | 356028, 377672 | ||||||||
| Bug Blocks: | |||||||||
| Attachments: |
|
||||||||
|
Description
Markus Keller
CQ for JUnit 4.10: https://dev.eclipse.org/ipzilla/show_bug.cgi?id=5958 David, how does the updating of the orbit.map file work? We'd like to replace JUnit 4.8.2 with the new 4.10.0 ASAP. Can I just take the JUnit 4.10.0 map file entry from here and release it into orbit.map? Do I also have to update R4_HEAD? http://download.eclipse.org/tools/orbit/downloads/drops/I20120427154656/orbitBundles-I20120427154656.p2.map Or can you take care of this? We don't have any dependencies that would need parallel updating. Yes, I was thinking I'd do this along with all the Orbit M7 entries (bug 377672).
I have updated the map files, but we are not done here. For the moment, I've left in the "4.8.2" entry and added the "4.10.0" entry (for code and source, for master and R4_HEAD).
BUT ... you say
> We don't have any dependencies that would need parallel updating.
But, I see some feature.xml files and build.property files, and various other files that refer to 4.8.2 (or 4.8.1?!) explicitly. And, that's just with what I happen to have loaded in my workspace, by no means complete.
And, it may well be that the places I see it are obsolete, and not really used, but figured safer to leave both to avoid build break.
Some of the features I see it mentioned explicitly are
feature.xml - org.eclipse.pde.junit.runtime.addon
feature.xml - org.eclipse.pde.junit.runtime.standalone
More importantly, I see it mentioned explicitly in
build.properties - org.eclipse.sdk (feature)
as part of the "source feature" generation.
So ... I think some follow on work is needed somewhere?
If any of that stuff really is obsolete, and no longer used, it'd be nice to delete it ... it will be there in SCM if its needed in future :)
Me leaving both in map files _should_ be safe since it is quite fine to have "extra" things in map files that are not used.
But, not completely safe. If someplace specified "0.0.0" meaning "get latest" and some other corresponding part that was supposed to match specified "4.8.2" explicitly, then they will "mismatch" and results will be unpredictable (but almost certainly wrong). If this "mismatch" problem does happen, then that probably means the "0.0.0" one should not be open ended, but should "match" the part that specifies "4.8.2".
FWIW, in WTP, we included the whole and complete orbit.map file as produced by the orbit map build, so if someone did not want "latest" they'd have to manage that in their features/properties. (And, naturally, all the "unused" stuff didn't really hurt anything). Not sure why the platform has decided to restrict the orbit.map file? (It is more work for the releng! :)
Created attachment 214773 [details] eclipse.platform.releng.patch Thanks for checking, David! I only looked for references in JDT, but I forgot about the features and the build process. The last time we updated JUnit was bug 336740, and that bug contains the same references you found. I didn't find any more references and no other Git commits that refer to 336740, so I think this and the next patch should be it. I think all the references are still necessary. The problem is that JUnit 4 is not fully backwards compatible (e.g. contains class files in 1.5 format), so we need to keep 3.8.2 and 4.x in parallel and references need to specify what exact version they mean. Unfortunately, I can't release the eclipse.platform.releng patch. Can you release it for the build? Probably into master and R4_HEAD, right? Created attachment 214774 [details]
eclipse.jdt.patch
This goes to master branch, and the integration branch needs to be forwarded for the build input.
I can release this, but you (David) can also do it when you release the other patch if you want.
(In reply to comment #5) > Created attachment 214773 [details] > eclipse.platform.releng.patch > > > Unfortunately, I can't release the eclipse.platform.releng patch. Can you > release it for the build? Probably into master and R4_HEAD, right? Ok, I put the change in to master and R4_HEAD. But, when I went to "fast forward" master to integration, things didn't look right. I created the integration branch (didn't have one yet), checked it out, from repo view selected 'master' and said to "merge" (with rebase). At this point it said there were two changes to merge, the ones I just did, and another from several months ago, from Kim, where the comment said "upgrade to ant 1.8.3" in some build.properties file. I figured that was ok, and the change was just never merged to integration (probably just effects Java Doc generation, or something?) But, when going back to my Java view, it says there are 10 outgoing changes to push. 10? Where'd did that many come from? And, I've even tried to "reset hard" but still tells me there are 10 outgoing? So, I am leaving things alone from there, and hope I didn't screw up the branches again? Also, I did remove ant 4.8.2 from maps (thinking we'd be all set). So, things might "blow up" for 12:30 rebuild? I've pushed the eclipse.jdt patch to master and integration: http://git.eclipse.org/c/jdt/eclipse.jdt.ui.git/commit/?id=39bd7ce26366aa340307ce4c6f8718e450cf4a2e (In reply to comment #7) > I created the integration branch (didn't have one yet) That sounds wrong. If the repo didn't have an integration branch, then it was most probably doesn't need one. Either because it auto-tags from master and/or R4_HEAD, or because auto-tagging is not enabled, and build inputs have to be done manually by tagging the repo and updating the map file. The eclipse.platform.releng repo looks fine for me, and if the auto-tagging works, then I think we're done. I'll go for dinner now -- back in about 1h. (In reply to comment #8) > I've pushed the eclipse.jdt patch to master and integration: > http://git.eclipse.org/c/jdt/eclipse.jdt.ui.git/commit/?id=39bd7ce26366aa340307ce4c6f8718e450cf4a2e > > (In reply to comment #7) > > I created the integration branch (didn't have one yet) > > That sounds wrong. If the repo didn't have an integration branch, then it was > most probably doesn't need one. > I mean I created my "local" clone of integration branch, it did already exist in "remote" repo. > Either because it auto-tags from master and/or R4_HEAD, or because auto-tagging > is not enabled, and build inputs have to be done manually by tagging the repo > and updating the map file. > I checked, and the auto-tagging does work off integration. (Sort of wish is didn't :) ... seems like an extra step to me ... especially after getting used to working "directly" with R4_HEAD). > The eclipse.platform.releng repo looks fine for me, and if the auto-tagging > works, then I think we're done. > I did take the brave step of looking what it would push if I said "push", and actually all 10 things looked like they should be pushed. Some were earlier changes by me such as to fix up some unused equinox "master features", some from Thomas fixing up (or reverting) "copyright checker" changes to releng tool. So ... our 3.8 build have probably been "different" for a while (and none of these issue would have been effecting 4.2 builds, from R4_HEAD) ... hopefully tonight's "final" warmup build will have 3.8 and 4.2 "in sync" the way they should be. ... though, it highlights how much I don't understand what egit is telling me! As an aside, I did notice some copyright date differences between 4.2 (R4_HEAD) and 3.8 (master) such as in eclipse sdk feature that I suspect should be the same and both ore recent (one said 2009, the other 2011) ... but, guess people have been wait for the copyright tool? :) And a separate issue, I meant to say, and ask for my eduction, that I could not apply your patches directly. Apparently you have checked out eclipse.platform.releng project as "general project" so you have "features" and "bundles" subdirectories in one project (whereas I have them all as "top level" projects). Is that common (best?) practice among the team? Or ... does everyone do it their own way as a matter of personal preference? (In reply to comment #9) OK, thanks. So it looks like the next builds will be fine. > And a separate issue, I meant to say, and ask for my eduction, that I could not > apply your patches directly. Sorry about that. I should have created a "Workspace" patch (brand-new, see bug 367735). > Apparently you have checked out > eclipse.platform.releng project as "general project" so you have "features" and > "bundles" subdirectories in one project (whereas I have them all as "top level" > projects). Is that common (best?) practice among the team? Or ... does everyone > do it their own way as a matter of personal preference? Nope, I have the individual features and bundles as separate projects, and that's the only sane way (otherwise, you couldn't use any PDE tooling). I originally wanted to create a workspace patch containing the eclipse.jdt change as well, but then the Create Patch... action was disabled (bug 376414). Then I backed off and just selected the changes from the eclipse.platform.releng repo and created a normal patch (format "None"). Apparently, this creates a patch that is not fully applicable any more, not even when you set "Ignore leading path segments" to 2. The problem is that the org.eclipse.sdk feature project is stored in eclipse.platform.releng/features/org.eclipse.sdk, but its .project file says <name>org.eclipse.sdk (feature)</name>. This is necessary because there's an equally-named /eclipse.platform/platform/org.eclipse.sdk project. In the end, the Apply Patch... wizard can't know how the project is called in the workspace, and it takes the wrong one. "Workspace" patches solve this problem. Looks good in I20120429-1245 (4.2). Verified in 3.8-I20120429-2000 and 4.2-I20120429-1800. |