So it looks like it might be best to not use a composite repository but to specify exactly the one I want to contribute from. I'll also look at the versionRange specification.
Is there any way for me to test what will get picked up by the aggregator without actually running the aggregation? -- David Dykstal, Architect - Rational Developer for Power Systems From: David M Williams/Raleigh/IBM@IBMUS To: Cross project issues <[email protected]>, Date: 01/17/2013 12:44 PM Subject: Re: [cross-project-issues-dev] Concluding SR2 RC1 warm-up repository Sent by: [email protected] What versions were you trying to contribute? I notice your Juno_maintenance version and master version point to different repositories, but each specify the same version of features ... there's nothing wrong with that! ... but, just wondering if that's what you intended? Just going by the file system, I see you specified org.eclipse.rse versionRange="3.4.0" and what's on the ../releases/maintenance file system is org.eclipse.rse_3.4.1.201209191030-7L7IFBY83omx__z0RFpKdWB-r5MS but you have a more recent version in ..../3.4milestones/SR2_RC1a/features/org.eclipse.rse_3.4.1.201301071106.jar There is a couple of ways the aggregator (actually p2) could get the "wrong" version. It is basically just looking for a solution "that satisfies all the constrains". And yes it will try to 'get the highest version' but a) not sure that's guaranteed 100% and (more likely) someone else could say "I want exactly version of XYZ" in which case p2 might well be able to satisfy their requirement, with your "loose" requirement of one repository, that has lots of versions in it, and the only thing you specify is 'higher than 3.4.0'. All of that leads me to my point ... I always recommend people specify _exactly_ what they want in the versionRange attribute, such as one example I saw as versionRange="1.6.0.v20120328-0001-67T-95GFz05DNIrNLOSNK_NPj507" OR, often easier, to me, is to specify a very specific repo that has only one version of that you want to contribute, such as for you ... .../tm/updates/3.4milestones/SR2_RC1a (If that was the one you wanted). Occasionally this might lead to "early warnings", such as the aggregator (p2) will complain "so and so wants exactly version XYZ but was not found" and then everyone knows ... but, without specific constraints, p2 is doing its job of finding "a solution". For builds, you normally want to be sure they are exact, and repeatable. Oh, and there are probably many less interesting things that could be going wrong :) ... but, that's the basics. HTH From: David Dykstal/Rochester/IBM@IBMUS To: Cross project issues <[email protected]>, Date: 01/17/2013 12:14 PM Subject: Re: [cross-project-issues-dev] Concluding SR2 RC1 warm-up repository Sent by: [email protected] I agree. Warmups are good. I really did mean /tm/updates/3.4milestones. I could have created one specifically for SR2, but we have been storing our milestone builds for our service releases in the directory I used. Seemed like the right spot for the repo. The aggregation editor does show the features existing under "available versions" and I am on the Juno_maintenance branch. Is there some sort of filtering going on that is missing that version? -- David Dykstal, Architect - Rational Developer for Power Systems From: David M Williams/Raleigh/IBM@IBMUS To: Cross project issues <[email protected]>, Date: 01/17/2013 10:37 AM Subject: Re: [cross-project-issues-dev] Concluding SR2 RC1 warm-up repository Sent by: [email protected] Well, that's why we do a warmup :) Did you meant to contribute .../tm/updates/3.4 to Juno or ... /tm/updates/3.4milestones? I see the former in 'master' and later in 'Juno_maintenance'. I can't tell by the names, but often XXMilestones implies something older than XX repository? You need to use the Juno_maintenance branch of org.eclipse.simrel.builds project. HTH From: David Dykstal/Rochester/IBM@IBMUS To: Cross project issues <[email protected]>, Date: 01/17/2013 11:19 AM Subject: Re: [cross-project-issues-dev] Concluding SR2 RC1 warm-up repository Sent by: [email protected] It looks like my first attempt at contributing to the aggregation build failed. If I'm reading the reports correctly I see the TM SR1 plugins there rather than the ones from the repository I thought I had contributed. Obviously my understanding of how the contribution files work is incorrect. Can someone give me a hand here and look at tm.b3aggrcon? -- David Dykstal, Architect - Rational Developer for Power Systems From: David M Williams/Raleigh/IBM@IBMUS To: "Cross project issues ([email protected])" <[email protected]>, Date: 01/17/2013 08:39 AM Subject: [cross-project-issues-dev] Concluding SR2 RC1 warm-up repository Sent by: [email protected] Sorry, fell asleep last night :) when I should have been sending out this notice. But, we are done with SR2 RC1 warm-up repo. Remember its "staging" location is http://download.eclipse.org/releases/maintenance/ Besides testing that repo, be sure to check the repository reports ... looks like a few regressions for required files, signed jars, etc. http://build.eclipse.org/simrel/juno/reporeports/ In addition to testing only that single repo, be sure to test it as a "composite", since eventually it will be added to .../releases/juno as a child repository. See http://wiki.eclipse.org/SimRel/Simultaneous_Release_FAQ#Test_staging_as_a_pseudo_composite Don't forget to test "update" scenarios (some of which need to wait for EPP repositories to be ready, if they are not already). Recall that there is no "promotion" of this repo. It will simply be "left alone" for about a week ... until Juno SR2 RC2 +0. http://wiki.eclipse.org/Juno/Simultaneous_Release_Plan#SR2 As a "warm-up", we don't expect this to be a true "release candidate", but please approach RC2, RC3, etc., with the attitude that those will be true "release candidates" suitable for adopter acceptance testing, etc. Thanks, _______________________________________________ cross-project-issues-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev _______________________________________________ cross-project-issues-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev _______________________________________________ cross-project-issues-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev _______________________________________________ cross-project-issues-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev _______________________________________________ cross-project-issues-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________ cross-project-issues-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
