Hi David
I see that we're still having difficulties.
The latest buckybuild log #249 suggests to me that the problem is that
EMFT EcoreTools is using org.eclipse.emf.ocl which was deprecated 3
releases ago and has now been removed. The log indicates that they have
been notified. I'll raise a Bugzilla on them; their project page list
no mailing lists or active committers or project lead.
org.eclipse.ocl 3.0.0.v200912091300 which is what we want to have in
the build is listed as an option, so we just need to lose the
references to anything else.
If I'm not mistaken this indicates that no action is required by
MDT/OCL.
Regards
Ed Willink
David M Williams wrote:
Yes, hiccough's all the time ... but
doubt there's too many processes that milestone deadlines and PMCs
could
help with (Well, M6 is consider the end of version changes). The best
way
to address this is that suppliers and consumers communicate often, and
if there's something controversial, to have meetings and discussions
until
its resolved. And in the worst case, do what Ed says. :)
But, I do agree with what I think
you
are saying, that each project should have one primary release for the
Yearly
release, and if they have clients that need some previous release, that
would be handled "on the side" and not to try and have both in
Helios. That might not always work, but to do otherwise takes a lot of
skillful effort.
Ed, it appears this is a Modeling
internal
issue that needs to be resolved (quick). Let me know if there's
anything
I can do to help. Likewise, let me know if I should just remove the
components
so it will no longer block the build from completing. For example, if
it
can't be resolved by, say Thursday, then I think they should be removed
until the issue it resolved. I'm not sure what else that would "drag
along", but fear it would be a lot ... such as GMF?! We are getting
down to the wire on M4, with the platform finishing this Friday, and
after
that time, I'm sure we'll have our hands full with details, and this
high
level problem should be resolved by then ... or, at least, some
resolution
that allows M4 to complete. Perhaps other things could be done after
M4,
if there were other things to do.
Since Ed Willink didn't take me up
on
the cross-project posting, I'll CC that list with this note, so
everyone
knows the issue is being worked, but no clear resolution yet.
Let us know what you decide.
Thanks,
Hi David
My recollection is that every year at about this time there is a major
version number hiccough as projects catch up with each other. Is this
any
different? Perhaps Eclipse needs a policy that any major version
increment
after M1 needs PMC approval to get versions in place promptly. We
should
not be trying to guess where the problem is. Helios should 'know' that
UML2 is 3.1.0, OCL is 3.0.0 and any build for any release train project
that uses other than those should be identified, the offending
reference
can then be corrected promptly by the 'offender' without impacting
everyone
else.
Looking at the log file again, we don't need to guess:
[exec] Contains: Cannot satisfy dependency:
[exec] Contains: From: all.contributed.content.feature.group 1.0.0
[exec] Contains: To: org.eclipse.ocl.all.sdk.feature.group
[1.4.0.v200908201900-787D8aA3QRRgQbeUhZhdeHk89tD-]
The problem is that
all.contributed.content.feature.group
is using OCL 1.4.0M1b, even though OCL 1.4.0M2 is available. I think
OCL
3.0.0M3 should fix the problem. Who is responsible for maintaining
all.contributed.content.feature.group
and what project does it belong to?
Regarding a cross-project posting, I'm afraid that I've done as much as
I can at this point.
I'm not the project leader, I do not have releng access so cannot
promote
Sunday's stable OCL build that works with EMF's fixed I-build (MDT/OCL
3.0.0M3 is ok). I do not want to change project policy unilaterally.
While Ed Merks (https://bugs.eclipse.org/bugs/show_bug.cgi?id=293605#c35)
has come very close to instructing us to abandon 1.4.0 so that 3.0.0 is
the only choice, and while I have never been enthusiastic about a 1.4.0
release, the rest of the OCL team was clearly in favour of a concurrent
1.4.0 release. Ed's comment was six days ago. Until at least one other
member of the team indicates how they want to follow Ed's direction, I
cannot reasonably issue cross-project statements that 1.4.0 is dead and
3.0.0 mandated, I can only indicate that as far as I'm concerned 1.4.0
is dead.
Regards
Ed
David M Williams wrote:
So, what's next?
I suggest you post to cross-project list for two reasons. 1. Keep
everyone
informed. 2. Someone might be able to help solve the problem.
Thanks,
Hi James
I'm not sure what 'feature.group' is. I assume it's a p2-ism.
org.eclipse.ocl.uml-feature 3.0.0.qualifier has
<import plugin="org.eclipse.uml2.uml" version="3.0.0"
match="compatible"/>
which is [3.0.0,4.0.0).
I suspect that someone is trying to use OCL 1.3 or 1.4.
Regards
Ed
James Bruck wrote:
Hi Ed,
The error seems to indicate the following:
Cannot satisfy dependency: org.eclipse.ocl.uml.feature.group
2.0.0.v200901271800-3--7w311A19272741
depends on: org.eclipse.uml2.uml [3.0.0,3.1.0)
I think the problem is in the feature itself, not a plugin.
Regards,
- James.
Hi James
I'm not 'at my desk' right now so cannot check which OCL plug-in has a
[3.0.0, 3.1.0) rather than [3.0.0,
4.0.0).
Assuming there is such a plug-in, I will do a CVS change to force a
rebuild
at 15:10ish EST with the changed range.
I don't have full releng privileges, so Alex may be able to do one
sooner.
Do you actually need a build; surely it's just CVS you need updating?
Which
build of OCL are you using?
Regards
Ed Willink
From: James Bruck [mailto:jbruck@xxxxxxxxxx]
Sent: 07 December 2009 15:09
To: David Williams
Cc: ed.willink@xxxxxxxxxxxxxxx;
aigdalov@xxxxxxxxxxx;
kenn.hussey@xxxxxxxxx
Subject: Re: [Helios] Failed for build 2009-12-06_13-54-12
Hi Dave,
This has to do with UML2 moving up a minor version number for the first
time in the release. I believe that OCL has a version dependency
on [3.0.0, 3.1.0) (not inclusive) of UML but we are now at version
3.1.0.
I believe the OCL component would need to respond by changing the
version
range check.
I could temporarily back out those changes so Helios is fixed but I
think
the proper way to address this is for OCL to create another build with
updated version range checking.
Cheers,
- James.
The following errors occured when building Helios:
Software being installed: all.contributed.content.feature.group 1.0.0
Only one of the following can be installed at once:
[org.eclipse.uml2.uml
3.0.0.v20081007-1910, org.eclipse.uml2.uml 2.2.2.v200811051031,
org.eclipse.uml2.uml
2.0.4.v200707131442, org.eclipse.uml2.uml 2.1.1.v200707311200,
org.eclipse.uml2.uml
3.0.0.v200904241430, org.eclipse.uml2.uml 2.2.100.v200808270930,
org.eclipse.uml2.uml
3.0.100.v200909221515, org.eclipse.uml2.uml 3.0.1.v200908281330,
org.eclipse.uml2.uml
2.2.0.v200804231435, org.eclipse.uml2.uml 2.2.0.v200805051730,
org.eclipse.uml2.uml
2.2.0.v200805141133, org.eclipse.uml2.uml 3.0.0.v200905151700,
org.eclipse.uml2.uml
2.2.1.v200808251630, org.eclipse.uml2.uml 3.1.0.v200912041155,
org.eclipse.uml2.uml
2.2.0.v200804291636, org.eclipse.uml2.uml 3.0.0.v20090407-1910,
org.eclipse.uml2.uml
2.2.1.v200808191500, org.eclipse.uml2.uml 2.0.5.v200802262248]
Cannot satisfy dependency: all.contributed.content.feature.group 1.0.0
depends on: org.eclipse.ocl.all.sdk.feature.group
[1.4.0.v200908201900-787D8aA3QRRgQbeUhZhdeHk89tD-]
Cannot satisfy dependency: all.contributed.content.feature.group 1.0.0
depends on: org.eclipse.uml2.sdk.feature.group [3.1.0.v200912041155]
Cannot satisfy dependency: org.eclipse.ocl.all.feature.group
1.4.0.v200908201900-548_7EBJlGqKCLkKdLaMfM9
depends on: org.eclipse.ocl.uml.feature.group
[2.0.0.v200901271800-3--7w311A19272741]
Cannot satisfy dependency: org.eclipse.ocl.all.sdk.feature.group
1.4.0.v200908201900-787D8aA3QRRgQbeUhZhdeHk89tD-
depends on: org.eclipse.ocl.all.feature.group
[1.4.0.v200908201900-548_7EBJlGqKCLkKdLaMfM9]
Cannot satisfy dependency: org.eclipse.ocl.uml.feature.group
2.0.0.v200901271800-3--7w311A19272741
depends on: org.eclipse.uml2.uml [3.0.0,3.1.0)
Cannot satisfy dependency: org.eclipse.uml2.feature.group
3.1.0.v200912041155
depends on: org.eclipse.uml2.uml [3.1.0.v200912041155]
Cannot satisfy dependency: org.eclipse.uml2.sdk.feature.group
3.1.0.v200912041155
depends on: org.eclipse.uml2.feature.group [3.1.0.v200912041155]
Check the log file for more information: https://build.eclipse.org/hudson/view/Repository%20Aggregation/job/helios.runBuckyBuild/235/console
****************************************************************************
Please consider the environment
before
printing this email.
****************************************************************************
Thales Research and Technology
(UK)
Limited DISCLAIMER: The information
contained in this e-mail is
confidential.
It may also be legally
privileged. It is intended only
for
the stated addressee(s) and access to
it by any other person is
unauthorised.
If you are not an addressee, you
must not disclose, copy,
circulate or
in any other way use or rely on the
information contained herein.
Such unauthorised
use may be unlawful. We
may monitor all e-mail
communications
through our networks. If you have
received this e-mail in error,
please
inform us immediately on +44 (0)1293
575987 and delete it and all
copies
from your system. We accept no
responsibility for changes to
any e-mail
which occur after it has been sent.
Attachments to this e-mail may
contain
software viruses which could damage
your system. We therefore
recommend
you virus-check all attachments before
opening. The registered office
of Thales
Research and Technology (UK)
Limited is at: 2 Dashwood Lang
Road,
The Bourne Business Park, Addlestone,
Weybridge, Surrey KT15 2NX.
Registered
in England No. 774298.
****************************************************************************
No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 9.0.709 / Virus Database: 270.14.97/2550 - Release Date:
12/07/09
07:33:00
No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 9.0.709 / Virus Database: 270.14.97/2550 - Release Date:
12/07/09
07:33:00
No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 9.0.709 / Virus Database: 270.14.97/2550 - Release Date: 12/07/09 07:33:00
|
