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
