[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
[mdt-ocl.dev] Re: [Helios] Failed for build 2009-12-06_13-54-12
|
Hi All,
The easiest seems to be fixing the 1.4.0 build - it has an outdated UML2 dependency. After fixing it the build should work.
As regards 3.0.0, we must decide
1) whether to include both 1.4.0 and 3.0.0 into Helios.
2) whether to support coinstallation of both 1.4.0 and 3.0.0 in Eclipse 3.6.
If we support (2) then we need to apply my patch to
https://bugs.eclipse.org/bugs/show_bug.cgi?id=293605 . As I see it, Ed (Merks) is unhappy about renaming the bundles. I do not fully understand why we shouldn't support (2), especially when we have almost completed the work needed to do it. Ed, do you forsee any strong reasons for this?
Moreover, we should decide whether we support (1). I have no personal preferences whether to support it. I think it should be possible for the clients to have a chance to work with 1.4.0 - but I don't think it is important whether 1.4.0 is included into Helios train or not.
As of now we have the following votes for keeping 1.4.0 in Helios train:
Ed Merks (-1)
Ed Willink (0) -- Ed, am I correct?
Me (0)
Adolfo and Laurent, what's your opinion? In case we all agree, I will include 3.0.0 into Helios instead of 1.4.0. In this case the bundle renaming discussion will not be so urgent (though still important).
Regards,
- Alex.
On Tue, Dec 8, 2009 at 6:10 PM, Kenn Hussey
<kenn.hussey@xxxxxxxxx> wrote:
Alex,
Please take the necessary action ASAP to ensure that a build of OCL 3.0 is included on the Helios train. If you have any questions or concerns, please let me know.
Thanks,
Kenn
---------- Forwarded message ----------
From:
Willink, Ed <Ed.Willink@xxxxxxxxxxxxxxx>
Date: Tue, Dec 8, 2009 at 5:32 AM
Subject: RE: [Helios] Failed for build 2009-12-06_13-54-12
To: David M Williams <
david_williams@xxxxxxxxxx>, Ed Willink <
ed@xxxxxxxxxxxxx>
Cc:
aigdalov@xxxxxxxxxxx, "Willink, Ed" <
Ed.Willink@xxxxxxxxxxxxxxx>, James Bruck <
jbruck@xxxxxxxxxx>,
kenn.hussey@xxxxxxxxx, Ed Merks <
merks@xxxxxxxxxx>, Anthony Hunter <
anthonyh@xxxxxxxxxx>,
cross-project-issues-dev@xxxxxxxxxxx
Hi David
There seem to be 3 options.
a) OCL is removed => everyone downstream is
blocked
b) OCL 1.4 is used => build fails, everyone
upstream and downstream is blocked.
(Unless the
OCL 1.4 build can be mended quickly, but since I don't have releng
access,
since I am not aware of what special facilities were
required to try to make OCL 1.4 and 3.0
builds co-exist, and since the 1.4 build has never
succeeded, I have little prospect
of
getting it mended in two days while also doing my day
job.
Alex, if you're there, can you make OCL 1.4 build?)
Even if the build is fixed,
everyone who is already using OCL 3.0 is
blocked.
c) OCL 3.0 is used => everyone downstream still
requesting OCL 1.4 is blocked.
Since c) is the long term solution and enables some things
to work, I think it's worth going with it.
If other projects respond quickly all projects are
ok.
Please accept my apologies for misguidedly not arguing
harder to prevent the forked
development branch being offered at
all.
Regards
Ed Willink
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