Hi All,
Sorry for the delayed response (We had two -bank- holidays in Spain).
Well, quick actions were required and taken, so my opinion is merely
informative.
I'm not obviously being opposite to exclude MDT-OCL 1.4.0, since (as a
pure MDT-OCL committer) I was firstly inclined to only release a
version (3.0.0) focused on the new specification. The sensible point of
backward compatibility of current projects and tools made all of us
agree to maintain the previous MDT-OCL implementation versioned as
MDT-OCL 1.4.0 and focused on the old OMG OCL 2.0 specification and to
mainly work on the new MDT.-OCL 3.0.0 based on the new OCL 2.1
specification. However, this decision was also based in a couple of
principles:
1. It must be possible to make both versions friendly coexist.
2. Maintaining MDT-OCL 1.4.0 should not create any "extra" efforts to
the team.
Since both ideas have been creating problems to us and it's still
currently struggling the project state, I will also +1 to the idea of
the removing MDT-OCL 1.4.0. The lesser extra effort we make to maintain
the old version the better for the improvement of the new one, and
since it has been demonstrated that most of us hardly have time to
invest on the project, I think that we should take up again of simply
focusing on the development of the new one.
I know that Alex has invested time in making both implementation work
at the same time, and maybe Acceleo implementation prefers to keep the
MDT-OCL 1.4.0 to not align with MDT-OCL 3.0.0 and save efforts in that
way, but let's be realistic, who is going to maintain MDT-OCL 1.4.0 now
and in the next future ?. I wouldn't definitely invest time in it, I
would prefer to correct/improve the 3.0.0 one....
Best regards,
Adolfo.
Alexander Igdalov escribió:
Adding to CC other thread participants.
On Tue, Dec 8, 2009 at 8:56 PM, Alexander
Igdalov <alexander.igdalov@xxxxxxxxx>
wrote:
Hi Ed,
Ok, we got results. I will exlude 1.4.0 from Helios train and
include 3.0.0 instead. Moreover, I will not rename the bundles in 3.0.0
M4.
We should now vote whether we will do it after M4. If not we
can erase 1.4.0 and consider it to be a dead end branch. Ed, are you
vetoing 1.4.0 in any form (even apart from Helios train)?
Regards,
- Alex.
On Tue, Dec 8, 2009 at 8:13 PM, Willink,
Ed <Ed.Willink@xxxxxxxxxxxxxxx>
wrote:
Hi Alex
When we have solved all the OclAny and such like
non-compliances, I am happy to consider a 1.4.0 and all the associated
build, co-existence and distribution issues. At the present rate of
progress that may be obsoleted by the availability of Eclipse 5.0.
In a few weeks, I think we will be grateful that
EMF has made a change that Christian actually wanted; it makes us more
OMG-compliant, and it gives us someone else to blame for abandoning
1.4.0.
I should have argued more strongly against this
'commercial case' before. I don't think it really exists. I'm not sure
that a commercial project will move to Eclipse 3.6 without wanting to
take the rest of the release train. The release train was introduced to
remove the chaos that arose from pick-and-mix release selections. If
they want old behaviour they will stay with Eclipse 3.2. If a
commercial project wants to fund us to provide a much more 1.3.0-like
behaviour then we can take their money, but I think the better solution
is behavioural options in the latest version. In my experience it is
much better to have a clean core engine with the nasty fudges round the
outside. In 3.0.0 we are trying to modularize some of the more
pragmatic aspects of the current MDT/OCL run-time type system so that
we handle null, invalid and OclAny consistently.
Bye Bye 1.4.0. Laurent's vote came through while
I wrote this. Please delete as many indications of 1.4.0 as possible,
in particular archive it off the Download page.
Regards
Ed
From: Alexander Igdalov [mailto: alexander.igdalov@xxxxxxxxx]
Sent: 08 December 2009 15:55
To: Kenn Hussey; MDT OCL mailing list
Cc: Willink, Ed; Ed Merks
Subject: 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.
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
Date: Tue, Dec 8, 2009 at 5:32 AM
Subject: RE: [Helios] Failed for build 2009-12-06_13-54-12
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
_______________________________________________
mdt-ocl.dev mailing list
mdt-ocl.dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/mdt-ocl.dev
--
|
Adolfo
Sánchez-Barbudo Herrera
adolfosbh(at)opencanarias(dot)com
C/Elías Ramos González, 4, ofc. 304
38001 SANTA CRUZ DE TENERIFE
Tel.: +34 922 240231 / +34 617 718268 |
|
