> On the other hand, is not there any way to make the aggregator fail in case the bundles which feed it are not signed ?
Well, we could ... but, it'd pretty much always fail until M7 :) A better approach (for you) might be to work the test (and failure) into your own build and promotion procedures. [If there was wide-spread consensus no unsigned bundle should ever go into an aggregated common repo, I'd consider that, but suggest it be widely discussed in a cross-project feature enhancement request first. I think it is always hard to trade off an "always correct repository" (which admittedly would be nice) with the practical aspects of getting the kinks out of builds and releng ... one of the purposes for having milestones ... we typically expect steady progress towards perfection, not perfection every time ... but, if unsigned content was considered so bad or dangerous to avoid at all costs then it'd be worth considering stricter checks.] [One thing on my "it'd be nice todo" list is to provide some examples of how to "run the reports" from your own workspace ... see http://wiki.eclipse.org/SimRel/Simultaneous_Release_Reports_FAQ ... and from there, I'm sure many could/would figure out how to automate their own versions of the tests in their own builds. Thanks for the reminder :) ] From: Adolfo Sánchez-Barbudo Herrera <[email protected]> To: [email protected], Date: 12/15/2011 11:25 AM Subject: Re: [cross-project-issues-dev] MORE Issues !!! ... Re: Is it acceptable to have two com.google.common.collect providers? Sent by: [email protected] David, (Ok, The OCL milestones repository is in order again). Thanks for your tip, I'll identify the plugins which need their qualifier version need increased for M5. On the other hand, is not there any way to make the aggregator fail in case the bundles which feed it are not signed ? Cheers, Adolfo. El 15/12/2011 16:04, David M Williams escribió: Yes, for M4, unsigned content wouldn't justify a respin. Its not a "blocking" problem nor (directly) causes harm. Its not great ... but ... not so bad progress can't continue. One problem, if you have unsigned content, with one version/qualifier, once you get it signed (e.g. next milestone) you'll need to be sure the version/qualifiers all increase or else someone who "picked up" old, unsigned one, might not get new signed one installed into their workbench or product. Just a general principle. And, it seems you are not the only one with unsigned content in M4 :( http://build.eclipse.org/juno/simrel/reports/verifydiroutput/unsigned.txt Tip for all: Even if you do everything exactly right, the signing process can occasionally fail, so its recommended you double check all is signed from your build, especially for milestones and releases. For more information, see http://wiki.eclipse.org/JAR_Signing#Can_the_signing_process_fail.3F Thanks for the care, From: Adolfo Sánchez-Barbudo Herrera <[email protected]> To: [email protected], Date: 12/15/2011 10:21 AM Subject: [cross-project-issues-dev] MORE Issues !!! ... Re: Is it acceptable to have two com.google.common.collect providers? Sent by: [email protected] David, I've detected more problems, which I'm not sure it merits a respin or it doesn't in a milestone. Don't ask me about the reasons (Honestly, I don't know them right know) but as you may check in the attachment that our milestones repository (used to contribute to the simultaneous release) has a corrupted M4 repository: 1. It contains two bundles per source project ( xxx-1639 and xxx-1651). 2. worse, one of them (xxx-1639) is not signed. 3. worse, the bundle caught by the aggregator is the unsigned one :( That means that the M4 staging repository contains unsigned content, which I'm not sure is a strong cause for a respin. In any case, I'm doing a new OCL Core and Tools M4a builds, just in case is necessary for the respin. In any case, we will remove the corrupted OCL Core repository and create a new one for our consumers. More guesses about the cause of this damned milestones repository later. Regards and apologies for the inconveniences, Adolfo. El 15/12/2011 14:25, Ed Willink escribió: Hi In Indigo, the com.google.common.collect package was (and still is) provided by the com.google.collect plugin. It is now also provided by the com.google.guava plugin. For M4, Xtext 2.2.1 switched to Guava and so switched provider, but the old provider is still available in repositories for downstream projects that neglect to update their dependencies accurately. As a consequence, the M4 OCL Tools contribution provides broken editors. Since these are technically 'Examples', a respin is clearly not merited, so MDT/OCL will be providing an M4a. However it seems appropriate to at least warn the community of this hazard, and ask whether this is a serious breach of versioning principles. Regards Ed Willink _______________________________________________ cross-project-issues-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev -- Open Adolfo Sánchez-Barbudo Herrera Canarias, adolfosbh(at)opencanarias(dot)com S.L. C/Elías Ramos González, 4, ofc. 304 38001 SANTA CRUZ DE TENERIFE Tel.: +34 922 240231 [attachment "Snapshot.PNG" deleted by David M Williams/Raleigh/IBM] _______________________________________________ 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 -- Open Adolfo Sánchez-Barbudo Herrera Canarias, adolfosbh(at)opencanarias(dot)com S.L. C/Elías Ramos González, 4, ofc. 304 38001 SANTA CRUZ DE TENERIFE Tel.: +34 922 240231 _______________________________________________ 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
