[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [cross-project-issues-dev] MORE Issues !!! ... Re: Is it acceptable to have two com.google.common.collect providers?
|
> 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 <adolfosbh@xxxxxxxxxxxxxxxx>
To: cross-project-issues-dev@xxxxxxxxxxx,
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: cross-project-issues-dev-bounces@xxxxxxxxxxx
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
<adolfosbh@xxxxxxxxxxxxxxxx>
To: cross-project-issues-dev@xxxxxxxxxxx,
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: cross-project-issues-dev-bounces@xxxxxxxxxxx
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
cross-project-issues-dev@xxxxxxxxxxx
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
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
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
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
