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
