Hi Team,
To confirm, on the modeling pmc list GMF, QVTo and EMF Validation said
they were moving to OCL 3.0.0 for M4, so OCL 3.0.0 on the Helios
release train is it.
EMF Validation in particular has already committed their changes
requiring OCL 3.0.0 to HEAD for Helios.
Cheers...
Anthony
--
Anthony Hunter mailto:anthonyh@xxxxxxxxxx
Software Development Manager
IBM Rational Software: Aurora / Modeling Tools
Phone: 613-270-4613
Inactive hide details for Alexander Igdalov ---2009/12/08 10:55:14
AM---Hi All, The easiest seems to be fixing the 1.4.0 build Alexander
Igdalov ---2009/12/08 10:55:14 AM---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 w
From:
Alexander Igdalov <alexander.igdalov@xxxxxxxxx>
To:
Kenn Hussey <kenn.hussey@xxxxxxxxx>, MDT OCL mailing list
<mdt-ocl.dev@xxxxxxxxxxx>
Cc:
Ed Merks <ed.merks@xxxxxxxxx>, "Willink, Ed" <ed.willink@xxxxxxxxxxxxxxx>
Date:
2009/12/08 10:55 AM
Subject:
[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@gmail.com_
<mailto: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@thalesgroup.com_
<mailto: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@xxxxxx.com_
<mailto:david_williams@xxxxxxxxxx>>, Ed Willink
<_ed@xxxxxxxxxx.uk_ <mailto:ed@xxxxxxxxxxxxx>>
Cc: _aigdalov@borland.com_ <mailto:aigdalov@xxxxxxxxxxx>,
"Willink, Ed" <_Ed.Willink@thalesgroup.com_
<mailto:Ed.Willink@xxxxxxxxxxxxxxx>>, James Bruck
<_jbruck@xxxxxx.com_ <mailto:jbruck@xxxxxxxxxx>>,
_kenn.hussey@gmail.com_ <mailto:kenn.hussey@xxxxxxxxx>, Ed Merks
<_merks@xxxxxx.com_ <mailto:merks@xxxxxxxxxx>>, Anthony Hunter
<_anthonyh@xxxxxx.com_ <mailto:anthonyh@xxxxxxxxxx>>,
_cross-project-issues-dev@eclipse.org_
<mailto: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
------------------------------------------------------------------------
*From:* David M Williams [mailto:_david_williams@xxxxxx.com_
<mailto:david_williams@xxxxxxxxxx>] *
Sent:* 08 December 2009 08:10*
To:* Ed Willink*
Cc:* _aigdalov@borland.com_ <mailto:aigdalov@xxxxxxxxxxx>;
Willink, Ed; James Bruck; _kenn.hussey@gmail.com_
<mailto:kenn.hussey@xxxxxxxxx>; Ed Merks; Anthony Hunter;
_cross-project-issues-dev@eclipse.org_
<mailto:cross-project-issues-dev@xxxxxxxxxxx>
*
Subject:* Re: [Helios] Failed for build 2009-12-06_13-54-12
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,
From: Ed Willink <_ed@xxxxxxxxxx.uk_ <mailto:ed@xxxxxxxxxxxxx>>
To: David M Williams/Raleigh/IBM@IBMUS
Cc: _aigdalov@borland.com_ <mailto:aigdalov@xxxxxxxxxxx>,
"Willink, Ed" <_Ed.Willink@thalesgroup.com_
<mailto:Ed.Willink@xxxxxxxxxxxxxxx>>, James Bruck
<_jbruck@xxxxxx.com_ <mailto:jbruck@xxxxxxxxxx>>,
_kenn.hussey@gmail.com_ <mailto:kenn.hussey@xxxxxxxxx>
Date: 12/08/2009 01:54 AM
Subject: Re: [Helios] Failed for build 2009-12-06_13-54-12
------------------------------------------------------------------------
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,
From: Ed Willink _<ed@xxxxxxxxxxxxx>_ <mailto:ed@xxxxxxxxxxxxx>
To: James Bruck _<jbruck@xxxxxxxxxx>_ <mailto:jbruck@xxxxxxxxxx>
Cc: "Willink, Ed" _<Ed.Willink@xxxxxxxxxxxxxxx>_
<mailto:Ed.Willink@xxxxxxxxxxxxxxx>, _aigdalov@borland.com_
<mailto:aigdalov@xxxxxxxxxxx>, David M
Williams/Raleigh/IBM@IBMUS, _kenn.hussey@gmail.com_
<mailto:kenn.hussey@xxxxxxxxx>
Date: 12/07/2009 03:53 PM
Subject: Re: [Helios] Failed for build 2009-12-06_13-54-12
------------------------------------------------------------------------
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.
From: "Willink, Ed" _<Ed.Willink@xxxxxxxxxxxxxxx>_
<mailto:Ed.Willink@xxxxxxxxxxxxxxx>
To: James Bruck/Ottawa/IBM@IBMCA, David Williams
_<david_williams@xxxxxxxxxx>_ <mailto:david_williams@xxxxxxxxxx>
Cc: "Willink, Ed" _<Ed.Willink@xxxxxxxxxxxxxxx>_
<mailto:Ed.Willink@xxxxxxxxxxxxxxx>, _aigdalov@borland.com_
<mailto:aigdalov@xxxxxxxxxxx>, _kenn.hussey@gmail.com_
<mailto:kenn.hussey@xxxxxxxxx>, "Ed. Willink (_ed@xxxxxxxxxx.uk_
<mailto:ed@xxxxxxxxxxxxx>)" _<ed@xxxxxxxxxxxxx>_
<mailto:ed@xxxxxxxxxxxxx>
Date: 07/12/2009 10:21 AM
Subject: RE: [Helios] Failed for build 2009-12-06_13-54-12
------------------------------------------------------------------------
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@xxxxxx.com_] *
Sent:* 07 December 2009 15:09*
To:* David Williams*
Cc:* _ed.willink@thalesgroup.com_
<mailto:ed.willink@xxxxxxxxxxxxxxx>; _aigdalov@borland.com_
<mailto:aigdalov@xxxxxxxxxxx>; _kenn.hussey@gmail.com_
<mailto: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.
From: David Williams _<david_williams@xxxxxxxxxx>_
<mailto:david_williams@xxxxxxxxxx>
To: James Bruck/Ottawa/IBM@IBMCA
Cc: David Williams _<david_williams@xxxxxxxxxx>_
<mailto:david_williams@xxxxxxxxxx>
Date: 06/12/2009 03:54 PM
Subject: [Helios] Failed for build 2009-12-06_13-54-12
------------------------------------------------------------------------
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_ <http://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_ <http://www.avg.com/>
Version: 9.0.709 / Virus Database: 270.14.97/2550 - Release
Date: 12/07/09 07:33:00
_______________________________________________
mdt-ocl.dev mailing list
mdt-ocl.dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/mdt-ocl.dev
------------------------------------------------------------------------
_______________________________________________
mdt-ocl.dev mailing list
mdt-ocl.dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/mdt-ocl.dev
