Bugzilla – Full Text Bug Listing
| Summary: | Update the parent poms from 4.4.0 to 4.5.0 | ||
|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Paul Webster <pwebster> |
| Component: | Releng | Assignee: | David Williams <david_williams> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | akurtakov, arunkumar.thondapu, curtis.windatt.public, daniel_megert, david_williams, lshanmug, markus.kell.r, Michael_Rennie, pascal, sarika.sinha, sptaszkiewicz, thanh.ha, tjwatson, Vikas.Chandra |
| Version: | 4.4 | ||
| Target Milestone: | 4.5 M1 | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Bug Depends on: | |||
| Bug Blocks: | 436736 | ||
|
Description
Paul Webster
Paul, I assume all the builds failed for these gerrit reviews because the coordination needed to update the parent: [FATAL] Non-resolvable parent POM: Could not find artifact org.eclipse:eclipse-platform-parent:pom:4.5.0-SNAPSHOT in eclipse-hosted (In reply to Thomas Watson from comment #1) > Paul, I assume all the builds failed for these gerrit reviews because the > coordination needed to update the parent: > > [FATAL] Non-resolvable parent POM: Could not find artifact > org.eclipse:eclipse-platform-parent:pom:4.5.0-SNAPSHOT in eclipse-hosted The aggregator should be updated first and then a deploy job is run to push the parent pom to repo.eclipse.org. That should allow the sub-repo Gerrit reviews to pass. I've pushed a 4.5.0-SNAPSHOT parent pom to repo.eclipse.org. I retriggered the platform.ui job it passed. PW I've pushed the 4.5 parent pom to a temporary dev branch and set up https://hudson.eclipse.org/platform/job/deploy-eclipse-platform-parent-pom-4.5/ to publish it to repo.eclipse.org from there for now. When we make the changes, we can change that job to be the correct publish from master. PW I suggest we use the same "planned dates" for this mass upgrade, as we do for tagging: 6/25 to 6/27 (assuming we officially release on morning of 6/25). It's probably most natural to tag first, and then upgrade parent pom's, though technically the order doesn't matter, I guess? But will the current Gerrit commits have to be "rebased" first, if tagging is done first? At any rate, that would mean "first thing" Wednesday (6/25), we'd have to do aggregator and push parent pom ... though, the more I think about it, the more I think a "Gerrit build" won't work until everyone's done it and we have a new, valid I-build pushed up to our p2 repo. This depends, of course if/how many of the Gerrit confirmation builds "build everything" vs. those that "depend on latest I-build" ... which is not clear to me. But, that should not prevent any of our components from pushing the fix into repo (i.e. don't need to get a successful Gerrit build, to commit). Then we'll plan on "doing our first I-build" on Tuesday, 8 AM (usual time), on July 1. (By which time, everyone must have updated, for things to work ... as I understand it). Which I guess means N-builds could start Friday 6/25, at 8 PM -- some of initial ones would not work well, until all updates have been made. Perhaps as a "best practice" teams should wait until we get one good I-build, based on new parent pom versions, first, before merging in other (large) changes? Just to make sure we are chasing one tiger at a time? [As usual, the SWT team will need to remember to update master, AND their integration branch.] Another thing not clear to me if if/which features have to be "touched" to make sure they included "updated" artifacts? I hope the answer is "none" ... but ... thought I'd mention it as a question, in case anyone know? (In reply to David Williams from comment #5) > It's probably most natural to tag first, and then upgrade parent pom's, > though technically the order doesn't matter, I guess? But will the current > Gerrit commits have to be "rebased" first, if tagging is done first? > No, rebasing shouldn't be necessary as long as there are no new commits pushed. Tags and Branches are just pointers to a commit hash, the difference is a tag is permanent pointer and a branch is temporary because a branch can move to a child commit when a new commit is pushed. eclipse.jdt.debug https://git.eclipse.org/r/28764 eclipse.pde https://git.eclipse.org/r/28767 eclipse.pde.build https://git.eclipse.org/r/28768 eclipse.pde.ui https://git.eclipse.org/r/28769 eclipse.platform.debug https://git.eclipse.org/r/28772 These have been merged with master after tagging. I released: eclipse.platform https://git.eclipse.org/r/28770 http://git.eclipse.org/c/platform/eclipse.platform.git/commit/?id=2717982cf9e5188a563173f324e0713eaf6e89f6 eclipse.platform.common https://git.eclipse.org/r/28771 http://git.eclipse.org/c/platform/eclipse.platform.common.git/commit/?id=313727cc8df301125e22739a9625ce5dbbe2e96d eclipse.platform.runtime https://git.eclipse.org/r/ http://git.eclipse.org/c/platform/eclipse.platform.runtime.git/commit/?id=24a00a40a514794527d7c95bb7cf73602b2d4bc3 eclipse.platform.ua https://git.eclipse.org/r/28780 http://git.eclipse.org/c/platform/eclipse.platform.ua.git/commit/?id=aba3896fc9fab7728cb9da3262075fe4b9b0be5c eclipse.platform.ui https://git.eclipse.org/r/28781 http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=5a2f4b1058df288d4fb37f57f45d3254ffd272f9 PW I've done these two: eclipse.platform.releng https://git.eclipse.org/r/28773 eclipse.platform.releng.aggregator https://git.eclipse.org/r/28785 I released: https://git.eclipse.org/r/28782/ http://git.eclipse.org/c/equinox/rt.equinox.bundles.git/commit/?id=64ee606790cc65da288a0265829e454ac5fda8e6 https://git.eclipse.org/r/28783/ http://git.eclipse.org/c/equinox/rt.equinox.framework.git/commit/?id=cc01d9849b99361da1166571e69036a1ad1ea872 https://git.eclipse.org/r/28784/ http://git.eclipse.org/c/equinox/rt.equinox.p2.git/commit/?id=c3a68791a332e6cb68958bb7691617bc574fca8e Done: > eclipse.jdt https://git.eclipse.org/r/28761 > eclipse.jdt.core https://git.eclipse.org/r/28762 > eclipse.jdt.core.binaries https://git.eclipse.org/r/28763 > eclipse.jdt.ui https://git.eclipse.org/r/28765 > eclipse.platform.text https://git.eclipse.org/r/28779 > eclipse.platform.swt https://git.eclipse.org/r/28776 Done by Arun: > eclipse.platform.swt.binaries https://git.eclipse.org/r/28777 FYI, tonight's (6/25) N-build failed, with the message below ... which to the untrained eye, might look like I forgot to update something ... which was of course my first fear. :) But it's actually because the 'team' repository has not had it's parent poms updated to 4.5 yet, so it is still getting/using the 4.4 parent pom, where the appropriate p2 repository is "4.4" (though, even there, we'll soon have to update to the "released" repo). It just so happens org.eclipse.core.net is the first bundle to outright fail due to lack of parent updates ... I'm sure there will be others. = = = = = = = = = [ERROR] Failed to execute goal org.eclipse.tycho.extras:tycho-eclipserun-plugin:0.20.0:eclipse-run (default) on project org.eclipse.core.net: Execution default of goal org.eclipse.tycho.extras:tycho-eclipserun-plugin:0.20.0:eclipse-run failed: Failed to load p2 repository with ID 'eclipse' from location http://download.eclipse.org/eclipse/updates/4.4milestones/S-4.4RC3-201405282000/: No repository found at http://download.eclipse.org/eclipse/updates/4.4milestones/S-4.4RC3-201405282000. -> [Help1] I released eclipse.platform.resources (https://git.eclipse.org/r/28774) as http://git.eclipse.org/c/platform/eclipse.platform.resources.git/commit/?id=fbe4f1be34923a63af378fedc4ab54f2ec759751 and eclipse.platform.team (https://git.eclipse.org/r/28778) as http://git.eclipse.org/c/platform/eclipse.platform.team.git/commit/?id=6060c0970756abc529c572f57b4301f7e4cb260e (In reply to Szymon Ptaszkiewicz from comment #13) > I released eclipse.platform.resources (https://git.eclipse.org/r/28774) as > > http://git.eclipse.org/c/platform/eclipse.platform.resources.git/commit/ > ?id=fbe4f1be34923a63af378fedc4ab54f2ec759751 > > and eclipse.platform.team (https://git.eclipse.org/r/28778) as > > http://git.eclipse.org/c/platform/eclipse.platform.team.git/commit/ > ?id=6060c0970756abc529c572f57b4301f7e4cb260e Thanks Szymon, I tried a local test build and this fix allowed a "N-build" to complete. Next I tried a local test I-build and it failed on SWT. SWT appears to have the changes applied to "master", but not yet "integration". Arun, can you "merge" master to integration, so I can do a proper "test build"? Just to make sure we're good to go for next Tuesday. (That is, do a merge now, even if there did happen to be other changes/merges by next Tuesday). Thanks, I've pushed master to integration for eclipse.platform.swt and *.swt.binaries. Arun/Lakshmi: You may want to create/release SWT version v4500 for the I-build on Tuesday. For N-builds, the current v4427 should be good enough. Thanks Markus for the SWT "integration" fix ... and just so every knows, my local machine test builds now complete I-builds as well as N-builds. (And, not saying it's producing the right stuff ... just that the build completes :) I do not know of any easy way to confirm that all the parent poms have been changed to "4.5" ... in theory a build could still complete and some have been "missed"? Paul, did you created the original patches using XSLT Transform, looking specifically for /parent/version[text] (or similar)? If so, if you "re-ran" that script, say against recent N-build repo (or, your own clone, I guess) ... that would spot any that had not been changed yet, right? And if none found, we could close this as fixed. (In reply to Markus Keller from comment #15) > I've pushed master to integration for eclipse.platform.swt and > *.swt.binaries. > > Arun/Lakshmi: You may want to create/release SWT version v4500 for the > I-build on Tuesday. For N-builds, the current v4427 should be good enough. Thanks Markus! The new version/tag v4500 is created and pushed to both master and integration branches now. http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=42be8d7760d51e4bf576b213d73eb7e3f992f36e http://git.eclipse.org/c/platform/eclipse.platform.swt.binaries.git/commit/?id=b5b5e17c50136642c4a6e9327d8cc46839ad9596 (In reply to David Williams from comment #16) > Paul, did you created the original patches using XSLT Transform, looking > specifically for /parent/version[text] (or similar)? If so, if you "re-ran" > that script, say against recent N-build repo (or, your own clone, I guess) > ... that would spot any that had not been changed yet, right? Yes, I use http://git.eclipse.org/c/platform/eclipse.platform.releng.aggregator.git/tree/scripts/xsl/xslUpVersion.sh to update the scripts. I'll try running it again on the repo. The other thing I think that needs to be done is eclipse.platform.releng.aggregator/eclipse.platform.releng.prereqs.sdk/pom.xml needs to be updated from 4.4 to 4.5 before we change the target platform contents. PW (In reply to Paul Webster from comment #18) > > Yes, I use > http://git.eclipse.org/c/platform/eclipse.platform.releng.aggregator.git/ > tree/scripts/xsl/xslUpVersion.sh to update the scripts. I'll try running it > again on the repo. I ran my script again against master on every repo, and no pom.xml files changed. PW > The other thing I think that needs to be done is
> eclipse.platform.releng.aggregator/eclipse.platform.releng.prereqs.sdk/pom.
> xml needs to be updated from 4.4 to 4.5 before we change the target platform
> contents.
Not sure if this is required .... but don't see what it'd hurt ... so I sent ahead and bumped it, and we'll count this as fixed.
|