Community
Participate
Working Groups
I wanted to capture the finishing touches in this ticket, so we don't goof up and miss something in the last stages. This is to be taken up post RC2 (March 7th 2014) Here is the list I came up with: Core + APT: 1. Remove JCP disclaimer from all files. 2. Update @since 3.9 BETA_JAVA8 tags with appropriate values. 3. Does bundle versions/qualifier need change ? 4. Check if batch compiler version strings need to bumped up. 5. Build state identifier needs bump up ? 6. Make BETA_JAVA8 the master branch. UI: 7. Do what is applicable from 1-6. 8. Change compliance string from 1.8_BETA to 1.8 9. Remove JCP disclaimer from dialog boxes. 10. Open up a bottle of champagne :)
Olivier, since you handled this by yourself for past releases, appreciate your taking a moment to call out any errors of omission/commission from the laundry list of last minute chores from comment#0. Others on CC:, please also look through, thanks!
> This is to be taken up post RC2 (March 7th 2014) IMPORTANT: No changes must end up in 'master' or 'BETA_JAVA8' unless the corresponding builds are halted until Java 8 goes GA on March 18. However, the work can be prepared in other branches (allowing hidden test builds) that we then just rename. > 6. Make BETA_JAVA8 the master branch. *** WARNING *** You must not immediately convert/modify the existing 'BETA_JAVA8' to *be* 'master' since we will need a branch that allows to build 4.3.2+Java8 and the official feature patch for 4.3.2. Either you merge the code back to 'master' or copy 'BETA_JAVA8' before you convert it to 'master'. Basically, 'BETA_JAVA8' will become 'R4_3_maintenance_Java8'. > 3. Does bundle versions/qualifier need change ? Yes: - For 'master' the version follows the version guidelines [1] as usual. - For 4.3.2+Java8, we will set the service segment to 50. [1] http://wiki.eclipse.org/Version_Numbering > 2. Update @since 3.9 BETA_JAVA8 tags with appropriate values. For 4.3.2+Java8 we use the same @since tag as in 4.4.
(In reply to Dani Megert from comment #2) > > 6. Make BETA_JAVA8 the master branch. > > *** WARNING *** > > You must not immediately convert/modify the existing 'BETA_JAVA8' to *be* > 'master' since we will need a branch that allows to build 4.3.2+Java8 and > the official feature patch for 4.3.2. Either you merge the code back to > 'master' or copy 'BETA_JAVA8' before you convert it to 'master'. Basically, > 'BETA_JAVA8' will become 'R4_3_maintenance_Java8'. I don't want to interfere if steps have been decided. Nevertheless I'm curious about that branch "4.3.2+Java8". In my understanding we will have one point in time where "4.3.2+Java8" and "master" point to the same commit, which would be when the content for J8 GA is created. Right? After that, we may have to branch again to keep a slow branch as "R4_3_maintenance_Java8" and normal operation on "master". How does "copying" the branch come into the picture? Will we be required to actively develop in two parallel branches after RC2?
(In reply to Stephan Herrmann from comment #3) > (In reply to Dani Megert from comment #2) > > > 6. Make BETA_JAVA8 the master branch. > > > > *** WARNING *** > > > > You must not immediately convert/modify the existing 'BETA_JAVA8' to *be* > > 'master' since we will need a branch that allows to build 4.3.2+Java8 and > > the official feature patch for 4.3.2. Either you merge the code back to > > 'master' or copy 'BETA_JAVA8' before you convert it to 'master'. Basically, > > 'BETA_JAVA8' will become 'R4_3_maintenance_Java8'. > > I don't want to interfere if steps have been decided. Nevertheless I'm > curious about that branch "4.3.2+Java8". In my understanding we will have > one point in time where "4.3.2+Java8" and "master" point to the same commit, > which would be when the content for J8 GA is created. Right? Not that is not right. The feature patch for 4.3.2 and master must have different bundle versions, hence it can't be the same commit. > Will we be required to actively develop in two parallel branches after RC2? Focus will be 'master' unless we detect a severe issue that justifies the rebuild of the feature patch.
(In reply to Srikanth Sankaran from comment #0) > Core + APT: > > 1. Remove JCP disclaimer from all files. > 2. Update @since 3.9 BETA_JAVA8 tags with appropriate values. > 3. Does bundle versions/qualifier need change ? > 4. Check if batch compiler version strings need to bumped up. > 5. Build state identifier needs bump up ? > 6. Make BETA_JAVA8 the master branch. > > UI: > > 7. Do what is applicable from 1-6. > 8. Change compliance string from 1.8_BETA to 1.8 > 9. Remove JCP disclaimer from dialog boxes. > > 10. Open up a bottle of champagne :) The list looks good to me. For 3, versions have to match the versions of bundles in the right branch. We had different versions for jdt core bundle for 3.6.2+Java 7 vs 3.8. Same thing might apply for (4). The batch compiler needs to return a different version in both streams. (5) you only need to bump it up if that change requires to rebuild everything. For example, this should be bump up if you have a severe bug in code generation that cannot be discovered at compile time or if the format of the resulting .class files might be different. Once you deliver Java 8, I agree that Java 8 branch should become the master branch. This also means that all fixes delivered to previous master branch have been delivered as well in Java 8. Impressive work from you guys! Kudos to the whole JDT team (Core, UI, ...)!
9.5: Run Jay's script to make sure everything from master has been cherry picked into BETA_JAVA8.
Appears just couple of commits made since last time. Will do it once the RC1 testing is over (early next week).
Jay, just a nag reminder to get started on this on a branch. TIA,
Adding other component leads for similar finishing touches to their respective components. Please start preparing for release. See Dani's comment#2 however.
(In reply to Dani Megert from comment #2) > You must not immediately convert/modify the existing 'BETA_JAVA8' to *be* > 'master' since we will need a branch that allows to build 4.3.2+Java8 and > the official feature patch for 4.3.2. Either you merge the code back to > 'master' or copy 'BETA_JAVA8' before you convert it to 'master'. Basically, > 'BETA_JAVA8' will become 'R4_3_maintenance_Java8'. Merging BETA_JAVA8 will be painful and we don't want to go there, so we can take the other option. Thankfully, with git, we don't have to copy the BETA_JAVA8 branch. I guess we can simply create 'R4_3_maintenance_Java8' from the particular commit. It wouldn't matter whether we do it before renaming it to master or after. (In reply to Dani Megert from comment #2) > > This is to be taken up post RC2 (March 7th 2014) > > IMPORTANT: No changes must end up in 'master' or 'BETA_JAVA8' unless the > corresponding builds are halted until Java 8 goes GA on March 18. However, > the work can be prepared in other branches (allowing hidden test builds) > that we then just rename. How soon after GA are we expecting to make these public? From Srikanth's list in comment #0, only 1 and 2 seem time-consuming, if any. On the other hand, If we aren't looking at lot of incoming bugs in BETA_JAVA8 after RC2, as Dani suggested, we could do this in a separate branch and keep merging with BETA_JAVA8 or cherry-pick commits.
(In reply to Jayaprakash Arthanareeswaran from comment #10) > How soon after GA are we expecting to make these public? Not after. On GA i.e. Tuesday's I-build must contain the Java 8 work and a feature patch for Kepler SR2 also needs to be available (with correct bundle version numbers).
Are the changes that Srikanth mentions in his first comment being done somewhere right now? In which branch? We would like to build our Spring Tool Suite release build with the final Java8 support in it - to be released after Java8 comes out (not before). Ideally we want to include the final artifacts in our release build, but it isn't clear where we can get those from.
Since we have just about a week left, we should get started, if you haven't already done so. Let me start with the branch names: BETA_JAVA8_LUNA [1] (thanks for the name, David!) and R4_3_maintenance_Java8 [2] And here are the steps. This may or may not work for other components. In any case, if you find something wrong/missing, please let me now. 1. Create branch BETA_JAVA8_LUNA from BETA_JAVA8 2. In branch BETA_JAVA8_LUNA, update bundle versions, remove JCP disclaimer and update @since tags 3. Create branch R4_3_maintenance_Java8 from BETA_JAVA8_LUNA HEAD. 4. Update bundle versions in R4_3_maintenance_Java8. This should be enough to get started on the 'private' trial builds for 4.3.2+Java8 and Luna. Biggest issue will be, any Java 8 fix would have to make it to all three branches. To alleviate some pain, we can delay the R4_3_maintenance_Java8 branching and the trial runs for 4.3.2+Java8 a bit. 5. On GA, rename BETA_JAVA8_LUNA to 'master' and get I build with Java 8 support 6. On GA, David to set up official 4.3.2+Java8 feature patches off R4_3_maintenance_Java8
(In reply to Jayaprakash Arthanareeswaran from comment #13) > This should be enough to get started on the 'private' trial builds for > 4.3.2+Java8 and Luna. Biggest issue will be, any Java 8 fix would have to > make it to all three branches. To alleviate some pain, we can delay the > R4_3_maintenance_Java8 branching and the trial runs for 4.3.2+Java8 a bit. I vote for paranoia - i.e doing it sooner than later.
(In reply to Jayaprakash Arthanareeswaran from comment #13) > Since we have just about a week left, we should get started, if you haven't > already done so. Let me start with the branch names: BETA_JAVA8_LUNA [1] > (thanks for the name, David!) and R4_3_maintenance_Java8 [2] > Actually, I just got name that from PDE's branching. In case it's not obvious, what has been our "Y-builds" will become the pre-I-builds ... building what's currently in I-bulds, except for the 5 repositories that need a BETA_JAVA8_LUNA branch. What has been our "P-builds" and "X-builds" will be using your R4_3_maintenance_Java8 branches ... so if teams would document here when they've created/renamed/whatever their BETA_JAVA8_LUNA branch and R4_3_maintenance_Java8 branch, I'll update the "aggregator" to use those names/branches instead of what they are currently using. Side note, since I'm the only one who "uses" aggregator, and since it will be very short lived, I think I'll just use a topic branch "david_williams/BETA_JAVA8_LUNA" which is what will be used in "Y-builds" (and once we stop doing Y-builds, I will essentially delete that topic branch, and we'll simply continue using "master" of aggregator to continue normal N and I builds after you all have renamed/merged to your 'master' versions. But since R4_3_maintenance_Java8 may have a "long life", I'll rename current BETA_JAVA8 of aggregator to R4_3_maintenance_Java8. So, let me know when you have your branches ready, so I can update. I suggest doing 2 "Y-builds" per day as we transition ... let's say 7 AM and 7 PM Eastern? ... since I would expect there will be a bit of churn around version numbers, etc. (Don't forget to update MANIFEST.MF and POM files.) And still daily P-builds at 4 PM (Eastern time). Let me know if anyone needs anything else.
(In reply to David Williams from comment #15) > So, let me know when you have your branches ready, so I can update. API Tools BETA_JAVA8_LUNA is ready (one nagging issue with our inner jar creation), though our current test environment consists of a mix of bundles from master and BETA_JAVA8. As JDT creates their Luna branches we will test against them.
> (In reply to David Williams from comment #15) > > So, let me know when you have your branches ready, so I can update. > JDT Debug is done
(In reply to Jayaprakash Arthanareeswaran from comment #13) > 5. On GA, rename BETA_JAVA8_LUNA to 'master' and get I build with Java 8 > support There is no "rename branch" in Git. You can force a non-FF push of BETA_JAVA8_LUNA's HEAD to master, but that breaks *all* existing forks of the master branch and is very disruptive. There's a reason why non-FF pushes need special permissions. I think the right solution is to check out the BETA_JAVA8 branch and then execute this on the command line: $ git merge -s ours origin/master Then - checkout master, and - merge BETA_JAVA8 into master (which is effectively a simple Fast Forward now) I tried this with jdt.core, and the results look very good. The resulting master branch has the same content as BETA_JAVA8, but it doesn't break any private branches that were forked from master, and e.g. Show Annotations still works. BTW: I saw that commit c0b5895abd09ac3472890c9dbd43d2aa66a43571 didn't make it into BETA_JAVA8.
(In reply to Markus Keller from comment #18) > BTW: I saw that commit c0b5895abd09ac3472890c9dbd43d2aa66a43571 didn't make > it into BETA_JAVA8. Thanks Markus, this is now in BETA_JAVA8. Just so that people are not concerned about the process, this was a human error (read my mistake). I had some questions about this when I was cherry-picking and was meant to check with Shankha and release it later, but somehow fell through the cracks.
FYI, I've delayed the "Y-build" scheduled for 1 PM Eastern to 3 PM Eastern to try and get started with new branch of aggregator (to be named david_williams/BETA_JAVA8_LUNA) Not to mention I-build was delayed, etc.
(In reply to Curtis Windatt from comment #16) > (In reply to David Williams from comment #15) > > So, let me know when you have your branches ready, so I can update. > > API Tools BETA_JAVA8_LUNA is ready (one nagging issue with our inner jar > creation), though our current test environment consists of a mix of bundles > from master and BETA_JAVA8. As JDT creates their Luna branches we will test > against them. Assume you mean "eclipse.pde.ui", just to be technical. From that I've "heard" on this list, and see from a quick glance at repo, only eclipse.pde.ui and eclipse.jdt.debug have created BETA_JAVA8_LUNA branches. I think I'll go ahead and start using those in the "Y-build", even though that may "break badly" ... I think there's nothing like a broken build to get everyone lines up. :) Here's a link to "what Y-builds will use" http://git.eclipse.org/c/platform/eclipse.platform.releng.aggregator.git/tree/streams/repositories.txt?h=david_williams/BETA_JAVA8_LUNA As a reminder ... just because I suspect Dani would normally do it ... we will also need the tiny "eclipse.jdt" repo branched to BETA_JAVA8_LUNA ... so hope another JDT committer can do that one. (We need the new feature definition that's in BETA_JAVA8 ... I've not looked at version numbers, etc, but the feature definition is what's critical (to pick up both versions of jdt.annotation). Thanks,
I have created BETA_JAVA8_LUNA for eclipse.jdt.core.git, but haven't created one for eclipse.jdt.core.binaries.git as I think it has not changed.
Note, I have branched eclipse.platform.releng.aggregator, to R4_3_maintenance_Java8 ... BUT, for today's patch build will leave "contributions" at BETA_JAVA8 (since I've not seen any renamed/newly branched yet). = = = = I did update jdt.core to use BETA_JAVA8_LUNA in our "transition master" ... And, you are right, anything that's "not changed" should not be branched. I believe there are only 5 repos that need to be branched: eclipse.jdt eclipse.jdt.core eclipse.jdt.debug eclipse.jdt.ui eclipse.pde.ui So, so far, we have 3 out of the 5. http://git.eclipse.org/c/platform/eclipse.platform.releng.aggregator.git/tree/streams/repositories.txt?h=david_williams/BETA_JAVA8_LUNA (If you get confused, you can always look at the 4.3.2 BETA JAVA8 streams (now R4_3_maintenance_Java8): http://git.eclipse.org/c/platform/eclipse.platform.releng.aggregator.git/tree/streams/repositories.txt?h=R4_3_maintenance_Java8
Not surprisingly, there were a number of "build failures" with the attempt at 3 PM Y-build ... things related to "parent poms", etc. I believe all related to "jdt.core"? http://build.eclipse.org/eclipse/builds/4Y/siteDir/eclipse/downloads/drops4/Y20140311-1500/buildFailed-pom-version-updater
(In reply to David Williams from comment #24) > http://build.eclipse.org/eclipse/builds/4Y/siteDir/eclipse/downloads/drops4/ > Y20140311-1500/buildFailed-pom-version-updater These all are the same issue. I have fixed and we are ready for another spin.
(In reply to Jayaprakash Arthanareeswaran from comment #25) > ... and we are ready for another spin. scheduled one for 0030 AM (Eastern) (i.e. in a few minutes). Plus, I have updated cron jobs so there will be one at 7 AM and 7 PM every day ... for as long as we need that many.
(In reply to David Williams from comment #26) > (In reply to Jayaprakash Arthanareeswaran from comment #25) > > ... and we are ready for another spin. > > scheduled one for 0030 AM (Eastern) (i.e. in a few minutes). > > Plus, I have updated cron jobs so there will be one at 7 AM and 7 PM every > day ... for as long as we need that many. Next ... :) http://build.eclipse.org/eclipse/builds/4Y/siteDir/eclipse/downloads/drops4/Y20140312-0030/buildFailed-pom-version-updater
(In reply to David Williams from comment #27) > http://build.eclipse.org/eclipse/builds/4Y/siteDir/eclipse/downloads/drops4/ > Y20140312-0030/buildFailed-pom-version-updater I didn't even know we had a parent test pom in each repo. I should have paid more attention. Sorry about it. Fixed it now.
(In reply to David Williams from comment #21) > As a reminder ... just because I suspect Dani would normally do it ... we > will also need the tiny "eclipse.jdt" repo branched to BETA_JAVA8_LUNA ... > so hope another JDT committer can do that one. (We need the new feature > definition that's in BETA_JAVA8 ... I've not looked at version numbers, etc, > but the feature definition is what's critical (to pick up both versions of > jdt.annotation). I've pushed BETA_JAVA8_LUNA of eclipse.jdt Essential difference to master: http://git.eclipse.org/c/jdt/eclipse.jdt.git/diff/org.eclipse.jdt-feature/feature.xml?h=BETA_JAVA8_LUNA&id=78d076310248d81ffdc7226757176ca0b74fa2ed
(In reply to Markus Keller from comment #29) > (In reply to David Williams from comment #21) > > As a reminder ... just because I suspect Dani would normally do it ... we > > will also need the tiny "eclipse.jdt" repo branched to BETA_JAVA8_LUNA ... > > so hope another JDT committer can do that one. (We need the new feature > > definition that's in BETA_JAVA8 ... I've not looked at version numbers, etc, > > but the feature definition is what's critical (to pick up both versions of > > jdt.annotation). > > I've pushed BETA_JAVA8_LUNA of eclipse.jdt > > Essential difference to master: > http://git.eclipse.org/c/jdt/eclipse.jdt.git/diff/org.eclipse.jdt-feature/ > feature.xml?h=BETA_JAVA8_LUNA&id=78d076310248d81ffdc7226757176ca0b74fa2ed Thank you. And, I've specified in repositories.txt ... http://git.eclipse.org/c/platform/eclipse.platform.releng.aggregator.git/commit/?h=david_williams/BETA_JAVA8_LUNA&id=d5b4fa6fc090d2a0cfd1f4f572f39703d59264e6 I believe that leaves only "jdt.ui"?
(In reply to Markus Keller from comment #29) > I've pushed BETA_JAVA8_LUNA of eclipse.jdt > > Essential difference to master: > http://git.eclipse.org/c/jdt/eclipse.jdt.git/diff/org.eclipse.jdt-feature/ > feature.xml?h=BETA_JAVA8_LUNA&id=78d076310248d81ffdc7226757176ca0b74fa2ed Did we have more builds after this commit went in? The last build had issues and this would have fixed it. Now that we have very few days left, perhaps, we should just pick the remaining one from BETA_JAVA8 and proceed with next build if that makes sense? I am keen to have one working build with test results.
(In reply to Jayaprakash Arthanareeswaran from comment #31) > Now that we have very few days left, perhaps, we should just pick the > remaining one from BETA_JAVA8 and proceed with next build if that makes > sense? I am keen to have one working build with test results. Yep. Quite a few committers are likely away on long flights to ECNA and the sooner we hear of any problems, the better we can respond.
What? You haven't book marked http://build.eclipse.org/eclipse/builds/4Y/siteDir/eclipse/downloads/drops4/ :) Tests from this morning are not finished yet, http://build.eclipse.org/eclipse/builds/4Y/siteDir/eclipse/downloads/drops4/Y20140313-0700/ but change was in last night, and it's DL page is http://build.eclipse.org/eclipse/builds/4Y/siteDir/eclipse/downloads/drops4/Y20140312-1900/
(In reply to David Williams from comment #33) > What? You haven't book marked > http://build.eclipse.org/eclipse/builds/4Y/siteDir/eclipse/downloads/drops4/ > > :) Sorry, but I am having trouble understanding the 'private' trial builds. I didn't think it will just substitute the Y builds. I know you did mention about updating the 'Y' build's aggregator. But wasn't sure then. Anyway, thanks.
FYI, I started an "on demand" Y-build at 2:15 PM (Eastern) to test out some of the changes required for moving up to org.objectweb.asm version 5.
And ... it failed already. The reason has nothing to do with Java 8, but the fact that I changed several "pre-reqs" from Orbit ... which in turn requires some "features" need to be "touched" to pick up the new change ... just a quick of our "automatic qualifier" heuristic. So, for Y-builds (only), I'll back out all those orbit changes EXCEPT for org.objectweb.asm as I'm assuming that feature will have to be touched anyway? Or, if hasn't been yet (relative to last I-build) then, you'll have to.
(In reply to David Williams from comment #36) > And ... it failed already. > > The reason has nothing to do with Java 8, but the fact that I changed > several "pre-reqs" from Orbit ... which in turn requires some "features" > need to be "touched" to pick up the new change ... just a quick of our > "automatic qualifier" heuristic. > > So, for Y-builds (only), I'll back out all those orbit changes EXCEPT for > org.objectweb.asm as I'm assuming that feature will have to be touched > anyway? Or, if hasn't been yet (relative to last I-build) then, you'll have > to. I think we've got all the orbit issues resolved ... but, build did not get started till 4:30 ... so, if not done by 7 PM, will postpone that 7 PM one till 8 or 9. Sorry for the churn.
(In reply to David Williams from comment #37) > I think we've got all the orbit issues resolved ... but, build did not get > started till 4:30 ... so, if not done by 7 PM, will postpone that 7 PM one > till 8 or 9. Sorry for the churn. The job from 4:30 just finished, but, I'd already change the cron job to wait a fer more hours till the next one (it will start at 9 PM (Eastern) ... so even though other job is done now, I'll leave it delayed those few hours, in case anyone is around to take a real quick look at it, and fix anything that's obviously not quite right. Then maybe some chance of fixing it by 9. http://build.eclipse.org/eclipse/builds/4Y/siteDir/eclipse/downloads/drops4/Y20140313-1630/ Thanks,
In a monster-commit, I've merged master of eclipse.jdt.ui into BETA_JAVA8 (but without changing the bundle versions). Should have done this a long time ago... > I believe that leaves only "jdt.ui"? Pushed BETA_JAVA8_LUNA of eclipse.jdt.ui. Ready to go!
(In reply to Markus Keller from comment #39) > In a monster-commit, I've merged master of eclipse.jdt.ui into BETA_JAVA8 > (but without changing the bundle versions). Should have done this a long > time ago... > > > I believe that leaves only "jdt.ui"? > > Pushed BETA_JAVA8_LUNA of eclipse.jdt.ui. Ready to go! I did't see this until until 9:15, so have killed the 9:00 job, and rescheduled it for 9:30 PM (Eastern).
I have created R4_3_maintenance_Java8 for eclipse.jdt.core repo. David, I have a question: Will the build set up be similar to our M build or I builds with respect to the tests-pom changes? Right now the pom files in this new branch are similar to the ones in master (except the versions, of course). Please let me know if this will be alright or these should be aligned with R4_3_maintenance branch.
(In reply to Jayaprakash Arthanareeswaran from comment #41) > I have created R4_3_maintenance_Java8 for eclipse.jdt.core repo. > > David, I have a question: Will the build set up be similar to our M build or > I builds with respect to the tests-pom changes? Right now the pom files in > this new branch are similar to the ones in master (except the versions, of > course). Please let me know if this will be alright or these should be > aligned with R4_3_maintenance branch. They need to be aligned with R4_3_maintenance, not master. (And, I should say, there might be ways to do it differently, but would mean basically "backporting" any and all changes related to that "tests-pom" change.)
(In reply to Jayaprakash Arthanareeswaran from comment #41) > I have created R4_3_maintenance_Java8 for eclipse.jdt.core repo. > I've changed 'aggregator' to use for X and P builds ... http://git.eclipse.org/c/platform/eclipse.platform.releng.aggregator.git/commit/?h=R4_3_maintenance_Java8&id=5153e596792bacd0d3fd174599601acd56ddc0f7 and next X-build is scheduled for Monday at 1 PM. I'm expecting we won't need "X-builds" that much longer? (i.e. they were just sort of a sanity check and easy way to run unit tests with "patched code").
(In reply to Jayaprakash Arthanareeswaran from comment #41) > I have created R4_3_maintenance_Java8 for eclipse.jdt.core repo. > I created the R4_3_maintenance_Java8 branches for jdt.debug and pde.ui.
(In reply to Michael Rennie from comment #44) > (In reply to Jayaprakash Arthanareeswaran from comment #41) > > I have created R4_3_maintenance_Java8 for eclipse.jdt.core repo. > > > > I created the R4_3_maintenance_Java8 branches for jdt.debug and pde.ui. Updated: http://git.eclipse.org/c/platform/eclipse.platform.releng.aggregator.git/commit/?h=R4_3_maintenance_Java8&id=c8badc4414bc62eba05eb1586c2d5cfc7030b569 That leaves just eclipse.jdt: BETA_JAVA8 eclipse.jdt.ui: BETA_JAVA8
Just to make sure we're all on the same track: In R4_3_maintenance_Java8, we have version numbers based on R4_3_maintenance, but the service segment of bundles that changed for Java8 are set to *** 50 ***. E.g. org.eclipse.jdt.core was 3.9.2.qualifier in R4_3_maintenance, so it will be bumped to 3.9.50.qualifier in R4_3_maintenance_Java8 Jay, this is currently at 3.9.3 and needs to be adjusted. The parent POM in R4_3_maintenance_Java8 stays at 4.3.0-SNAPSHOT. (In reply to David Williams from comment #43) > and next X-build is scheduled for Monday at 1 PM. > > I'm expecting we won't need "X-builds" that much longer? > (i.e. they were just sort of a sanity check and easy way to run unit tests > with "patched code"). After GA, we won't need regular X-builds any more, but we should get the R4_3_maintenance_Java8 branches in shape with green tests, so that we're confident we didn't break anything, and so that we can do rebuilds of the Java8 feature patch in case we detect stop-shippers, or if someone wants to pay us for shipping full Java 8 support on top of 4.3.2 (which will just use the 4.4 code, but that's our secret...). BETA_JAVA8_LUNA can just be merged into master as-is (see comment 18 for how to achieve this in jdt.core, where BETA_JAVA8_LUNA and master diverged at the point BETA_JAVA8 was created; ping me if you have questions). BETA_JAVA8_LUNA was a temporary branch that can be deleted after the swirl is over and we're all safe.
(In reply to Markus Keller from comment #46) > In R4_3_maintenance_Java8, we have version numbers based on > R4_3_maintenance, but the service segment of bundles that changed for Java8 > are set to *** 50 ***. Actually "... are set to the next x50": E.g. org.eclipse.jdt.junit was 3.7.200 in R4_3_maintenance and will be 3.7.250 in R4_3_maintenance_Java8
(In reply to Markus Keller from comment #46) > E.g. org.eclipse.jdt.core was 3.9.2.qualifier in R4_3_maintenance, > so it will be bumped to 3.9.50.qualifier in R4_3_maintenance_Java8 > > Jay, this is currently at 3.9.3 and needs to be adjusted. Actually, I was a bit skeptical about that particular bundle. We had already used up 3.9.3 in master (prior to the JAVA 8 merger). So, used 3.9.3. You will see other bundles using x.y.z50 format. Can we still use 3.9.50 or should it be 3.9.250?
(In reply to Markus Keller from comment #18) > I think the right solution is to check out the BETA_JAVA8 branch and then > execute this on the command line: > > $ git merge -s ours origin/master > > Then > - checkout master, and > - merge BETA_JAVA8 into master (which is effectively a simple Fast Forward > now) Markus, this worked very well for jdt.core repo. Thanks!
(In reply to Jayaprakash Arthanareeswaran from comment #48) > Actually, I was a bit skeptical about that particular bundle. We had already > used up 3.9.3 in master (prior to the JAVA 8 merger). So, used 3.9.3. You > will see other bundles using x.y.z50 format. Can we still use 3.9.50 or > should it be 3.9.250? That doesn't sound right, does it? I think I will update it to 3.9.250 then.
org.eclipse.jdt.core should be 3.9.50 in R4_3_maintenance_Java8 The first 3 segments of the version number are actual numbers, not strings composed of digits. The "50" is an adaptation of this rule: https://wiki.eclipse.org/Version_Numbering#When_to_change_the_service_segment The special case here is that R4_3_maintenance_Java8 is something between a real release (would bump to the next complete 100) and a service release (would bump by +1). To acknowledge this "in-between" status, we bump to the next complete 50.
(In reply to Jayaprakash Arthanareeswaran from comment #41) > I have created R4_3_maintenance_Java8 for eclipse.jdt.core repo. > > David, I have a question: Will the build set up be similar to our M build or > I builds with respect to the tests-pom changes? Right now the pom files in > this new branch are similar to the ones in master (except the versions, of > course). Please let me know if this will be alright or these should be > aligned with R4_3_maintenance branch. The "X-build" failed: http://download.eclipse.org/eclipse/downloads/drops4/X20140317-1300/buildFailed-pom-version-updater Appears "the parent" settings are off? (should "match" R4_3_maintenance). = = = = = = = = [ERROR] The project org.eclipse.jdt:org.eclipse.jdt.annotation:1.1.0.qualifier (/opt/public/eclipse/builds/4X/gitCache/eclipse.platform.releng.aggregator/eclipse.jdt.core/org.eclipse.jdt.annotation_v1/pom.xml) has 1 error [ERROR] Non-resolvable parent POM: Could not find artifact eclipse.jdt.core:eclipse.jdt.core:pom:4.4.0-SNAPSHOT and 'parent.relativePath' points at wrong local POM @ line 15, column 11
(In reply to David Williams from comment #52) > Appears "the parent" settings are off? (should "match" R4_3_maintenance). This has been fixed along with the service segment fixes I just mentioned: http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?h=R4_3_maintenance_Java8&id=379207a88e1eb5a4b0cfcaf7a1081221805f81f0
(In reply to David Williams from comment #45) > That leaves just > > eclipse.jdt: BETA_JAVA8 > eclipse.jdt.ui: BETA_JAVA8 R4_3_maintenance_Java8 have been created for those as well. I glanced at the other repos, and I'd say we're ready for the next try.
(In reply to Srikanth Sankaran from comment #0) > I wanted to capture the finishing touches in this ticket, so we don't > goof up and miss something in the last stages. This is to be taken up > post RC2 (March 7th 2014) ... > 9. Remove JCP disclaimer from dialog boxes. > 10. Open up a bottle of champagne :) Before (10) shouldn't there be an announcement in eclipse.org about Java 8 support? Please note, I am not asking for one, just wondering. For Java 7, we had this: http://eclipse.org/org/press-release/20110929_indigosr1.php
(In reply to Markus Keller from comment #54) > (In reply to David Williams from comment #45) > > That leaves just > > > > eclipse.jdt: BETA_JAVA8 > > eclipse.jdt.ui: BETA_JAVA8 > > R4_3_maintenance_Java8 have been created for those as well. I glanced at the > other repos, and I'd say we're ready for the next try. next try at 2:45. That won't finish before the patch build starts, scheduled for 4:00 PM (Eastern). But they should not interfere with each other, and if anything goes wrong, we can re-do the patch build easily enough.
David, I think you should do a search for "JCP" and "BETA" in R4_3_maintenance_Java8 of eclipse.platform.releng.aggregator and remove the disclaimers. In the feature patch name/description, I'd replace "BETA" with "Kepler", to make it clear for which base version the patch is intended.
As another "finishing touch", I plan to move to the "Java 8 compiler" for our N- and I-builds, and plan to use the most recent one from our "Y-builds". One implication of this is that version of the compiler will go into the Eclipse Foundation's "eclipse-staging" maven repo. I think that's desirable, in case others want to try it in their builds, etc., but just wanted the whole team to be aware. See bug 430549 for more details or voice any discussion there. (The "eclipse-staging" repo is, by design, not quite as permanent as other repos, and we do have the ability to remove compilers from there ... such as once we come out with Luna release.) = = = = And as to Markus comment, yes, that's planned. ... been a busy day!
(In reply to Jayaprakash Arthanareeswaran from comment #55) > Before (10) shouldn't there be an announcement in eclipse.org about Java 8 > support? Please note, I am not asking for one, just wondering. For Java 7, > we had this: > > http://eclipse.org/org/press-release/20110929_indigosr1.php Dani, please advise. If required, - Eclipse compiler implements all the new Java 8 language enhancements. - Significant features like incremental builder, code assist, indexing and search, formatter, code reconciler, AST APIs etc have been updated to support Java 8. could be the cut for JDT/Core. Markus can supply the wordings for UI and Micheal for Debug.
This is our "candidate" final patch. http://download.eclipse.org/eclipse/downloads/drops4/P20140317-1600/ I know there is not much time to "test", but hopefully some can give some quick sanity checks and make sure nothing is lost ... I just noticed the main "zipped repository" was missing! (bug 430561).
(In reply to Srikanth Sankaran from comment #59) > Dani, please advise. If required, > > - Eclipse compiler implements all the new Java 8 language enhancements. > - Significant features like incremental builder, code assist, indexing > and > search, formatter, code reconciler, AST APIs etc have been updated to > support Java 8. > > could be the cut for JDT/Core. Markus can supply the wordings for UI and > Micheal for Debug. Actually I would go with: - Eclipse compiler implements all the new Java 8 language enhancements. - Significant features like incremental builder, code assist, indexing and search, code formatter, type hierarchy views, code reconciler, AST APIs etc have been updated to support Java 8. - Support for type annotations based static null pointer analysis.
(In reply to David Williams from comment #60) > This is our "candidate" final patch. > > http://download.eclipse.org/eclipse/downloads/drops4/P20140317-1600/ > > I know there is not much time to "test", but hopefully some can give some > quick sanity checks and make sure nothing is lost ... I just noticed the > main "zipped repository" was missing! (bug 430561). Jay, please run some smoke tests on both master and Kepler patch streams. TIA.
(In reply to David Williams from comment #60) > http://download.eclipse.org/eclipse/downloads/drops4/P20140317-1600/ Looks good. The only strange thing I found is in PDE: Bug 390930 seems to be missing in R4_3_maintenance_Java8, so the build still contains org.objectweb.asm_3.3.1.v201105211655.jar. The R4_3_maintenance_Java8 branch has many more differences to master, so maybe that's intended?
(In reply to David Williams from comment #60) > I know there is not much time to "test", but hopefully some can give some > quick sanity checks and make sure nothing is lost ... I just noticed the > main "zipped repository" was missing! (bug 430561). I could install this with Kepler SR2 and verified that the last few fixes we made are available via this update. The command line tool works too. I also looked for one or two UI and debug features and found them to be there. But respective teams can confirm if they see all they expect to see. (In reply to Srikanth Sankaran from comment #62) > Jay, please run some smoke tests on both master and Kepler patch streams. > TIA. I don't understand what you meant by master. This patch is meant for Kepler SR2.
(In reply to Jayaprakash Arthanareeswaran from comment #64) > I don't understand what you meant by master. This patch is meant for Kepler > SR2. Right, I simply meant that when the respective bits become available, they be subjected to some degree of validation.
(In reply to Markus Keller from comment #63) > (In reply to David Williams from comment #60) > > http://download.eclipse.org/eclipse/downloads/drops4/P20140317-1600/ > > Looks good. The only strange thing I found is in PDE: Bug 390930 seems to be > missing in R4_3_maintenance_Java8, so the build still contains > org.objectweb.asm_3.3.1.v201105211655.jar. The R4_3_maintenance_Java8 branch > has many more differences to master, so maybe that's intended? Yes, from what I was told, objectweb.asm_5.x and required changes would not be back ported to 4.3.2 and patch.
(In reply to Markus Keller from comment #63) > (In reply to David Williams from comment #60) > > http://download.eclipse.org/eclipse/downloads/drops4/P20140317-1600/ > > Looks good. The only strange thing I found is in PDE: Bug 390930 seems to be > missing in R4_3_maintenance_Java8, so the build still contains > org.objectweb.asm_3.3.1.v201105211655.jar. The R4_3_maintenance_Java8 branch > has many more differences to master, so maybe that's intended? Yes, we had to make a lot of changes to the bytecode visitor for the ASM 5.x update (new APIs, etc) so we opted to just do it in Luna first to make sure it worked as intended before providing the upgrade to 4.3.x
http://download.eclipse.org/eclipse/downloads/drops4/N20140317-2000/testResults.php I downloaded the IDE and did some smoke testing and found it to be good. But we had a lot of failures in jdt.core tests and all of them failed because the pre Java 8 annotation bundle was not available. Otherwise, the build is good, but we must fix this for the I build so all test finish properly.
(In reply to Jayaprakash Arthanareeswaran from comment #68) > http://download.eclipse.org/eclipse/downloads/drops4/N20140317-2000/ > testResults.php > > I downloaded the IDE and did some smoke testing and found it to be good. > > But we had a lot of failures in jdt.core tests and all of them failed > because the pre Java 8 annotation bundle was not available. Otherwise, the > build is good, but we must fix this for the I build so all test finish > properly. And in case not obvious, 'master' must be "synched up" with BETA_JAVA8_LUNA (i.e. so that master has exact same content). The critical missing part is <plugin id="org.eclipse.jdt.annotation" download-size="0" install-size="0" version="1.1.0.qualifier" unpack="false"/> <plugin id="org.eclipse.jdt.annotation" download-size="0" install-size="0" version="2.0.0.qualifier" unpack="false"/> Dani or Markus ... I (we, me and Jay :) are assuming you'll be around "soon" to make that change before 8 AM (Eastern) I-build?
(In reply to David Williams from comment #69) > Dani or Markus ... I (we, me and Jay :) are assuming you'll be around "soon" > to make that change before 8 AM (Eastern) I-build? I'll take care of this right away!
(In reply to Dani Megert from comment #70) > (In reply to David Williams from comment #69) > > Dani or Markus ... I (we, me and Jay :) are assuming you'll be around "soon" > > to make that change before 8 AM (Eastern) I-build? > > I'll take care of this right away! It's done.
FYI, the following is from our last X-build. I've "turned off" all X, Y, and P builds. The following "test results" are basically what we'd see if Patch applied to 4.3.2. http://build.eclipse.org/eclipse/builds/4X/siteDir/eclipse/downloads/drops4/X20140317-1445/testResults.php I'll wait a day or two, and then cleanup (i.e. remove) all "old builds" from build server. It's all forward from here!
http://download.eclipse.org/eclipse/downloads/drops4/I20140318-0830/ The test results are not yet available, but I did some smoke testing on windows OS and found the build to be good. The annotation bundle that was missing in the N build made it way through in this one. So, I am expecting that the tests on Linux should produce positive results.
Marking as resolved, even though no. 10 in comment #0 is still pending ;)
Removing dependency regarding bug 522750, I think s.o. confused Java 8 and Java 9.
