Hi
UML 4.0.0M2 is available and I've managed an interactive M2 install
by excluding the UML extras for Xpand.
Perhaps the easiest thing for M2 is just to change all our UML2
dependencies to [3.0.0, 5.0.0) while we find out what the UML 4
change is and while we discuss whether we need a major change or
not; Ed Merks suggests not.
My guess is that the UML change is to support UML 2.4 and so in
principle if anything changes, then it affects us too.
I'll commit a bug/358558 branch, since I developed it this morning,
but refrain from pushing to master.
Adolfo: please fix the builds to use 4.2 and M2 wherever possible.
I'll widen the UML dependency bounds.
Regards
Ed
On 22/09/2011 11:11, Adolfo Sánchez-Barbudo Herrera wrote:
Ed,
I'm also seizing the opportunity to set Eclipse 4.2 as our Eclipse
target platform. I have the following errors when checking the
target platfform via buckminster (simulating an N-build)
WARNING [0004] : Component request
org.eclipse.emf.common:eclipse.feature/[2.7.0.v20110425-0906,2.7.0.v20110425-0906]
is inconflict with request
org.eclipse.emf.common:eclipse.feature/[2.7.0.v20110916-1359,2.7.0.v20110916-1359]
WARNING [0004] : Component request
org.eclipse.emf.ecore:eclipse.feature/[2.7.0.v20110425-0906,2.7.0.v20110425-0906]
is inconflict with request
org.eclipse.emf.ecore:eclipse.feature/[2.8.0.v20110916-1359,2.8.0.v20110916-1359]
ERROR [0115] : No suitable provider for component
org.eclipse.emf.common:eclipse.feature/[2.7.0.v20110916-1359,2.7.0.v20110916-1359]
was found in resourceMap
ERROR [0115] : No suitable provider for component
org.eclipse.emf.common:eclipse.feature/[2.7.0.v20110916-1359,2.7.0.v20110916-1359]
was found in searchPath emf
ERROR [0115] : Rejecting provider
p2({0}/modeling/emf/emf/updates/2.8-I-builds[http://download.eclipse.org/modeling/emf/emf/updates/2.8-I-builds]):
No component match was found
ERROR [0115] : No suitable provider for component
org.eclipse.emf.ecore:eclipse.feature/[2.8.0.v20110916-1359,2.8.0.v20110916-1359]
was found in resourceMap file
ERROR [0115] : No suitable provider for component
org.eclipse.emf.ecore:eclipse.feature/[2.8.0.v20110916-1359,2.8.0.v20110916-1359]
was found in searchPath emf
ERROR [0115] : Rejecting provider
p2({0}/modeling/emf/emf/updates/2.8-I-builds[http://download.eclipse.org/modeling/emf/emf/updates/2.8-I-builds]):
No component match was found
Looking into this, I've found some curiosities
I'm trying to do an N-build, so "nightly" repositories for Eclipse
Platform 4.2[1] and EMF 3.8[2] are used
However those emf features requirements are not resolved (with an
strict version requirement:
[2.7.0.v20110425-0906,2.7.0.v20110425-0906]). The point is that
those features reside in the EMF "milestones" repository.... It
looks like the last Eclipse 4.2 Platform nightly/interim build
used the EMF milestones repository.... So we can't simply do an
N-build using [1] and [2]... Curiously the target platform is
successfully resolved when configuring an S-build, that is, using
milestones repositories...
Now I'll try to check OCL against the target platform, but as you
comment we will have problems due to the new UML 4.0.0 version ...
Could you please fix our dependencies versions in our plugins
(remember to increase our plugins and features versions, although
API tooling should help here)...
On the other hand, will we require any kind of change due to UML
API change ? .... BTW, Kenn could we have some kind of information
about this UML major version increase ¿?
P.S: Ooopssss... I've just discovered that UML2 now have new
repositories [4] and [5] >.< .... I think that I'll have a
lot of fun until our M2+1... and I don't really have time for this
...let's see what I can do :\ ... Please, make our source code to
work in your workspace, and I'll try to make our build work.
[1] http://download.eclipse.org/eclipse/updates/4.2-I-builds
[2] http://download.eclipse.org/modeling/emf/emf/updates/2.8-I-builds
[3] http://download.eclipse.org/modeling/emf/emf/updates/2.8milestones
[4] http://download.eclipse.org/modeling/mdt/uml2/updates/4.0-I-builds
[5] http://download.eclipse.org/modeling/mdt/uml2/updates/4.0milestones
Best Regards,
Adolfo.
El 22/09/2011 7:24, Ed Willink escribió:
Hi Adolfo
We could be part of a problem here.
Let's plan to contribute an M2 this evening against Platform/EMF
M2, UML 4.0Ixxxxxx, etc Ixxxx and expect to respin M2a, M2b etc
as other projects catch up. If necessary we contribute without
examples initially. Better to have OCL without examples than no
OCL at all.
I'm just downloading UML2 now. We will probably need to remove
the 4.0 upper bound for M2, but retain the lowerbound at 3.0
temporarily.
If UML2 has a major version then we should too!!! and if
everyone who uses UML2 has got to adjust once then it would help
if our major version change was for M2.
Perhaps we contribute 3.1M2 today and 4.0M2 as soon as UML2
4.0M2 is out.
Alex: A major change gives us more discretion about what we do
for Juno. We still want practical compatibility, but perhaps not
totally paranoid compatibility.
Regards
Ed Willink
-------- Original Message --------
Well, no, probably not ... but,
it will take a lot of attention to get it done on time.
First greatest thanks to Kenn
Hussey for making (or fixing) an "early" contribution
repository [1] for EMF core (or, "base", I think they are now
calling the platform-shared parts.
This allows Eclipse 4.2 M2 and
EMF M2 to both be installed from repository sites. (For full
issues, and longer term improvements, you can follow bug
356644).
Now the problem is that the new
version of EMF (and maybe Eclipse M2?), apparently, breaks
numerous other contributions, apparently due to increased
minor version numbers (combined with narrow ranges?).
To aggregate, at the moment, I
would have to disable about 20 of the b3aggrcon files in
org.eclipse.juno.build.
I can (and may) do some
disabling, .... but, thought it would be a good time to review
the process and timing of making contributions to an
aggregation build:
you do not have to wait until
your +n day to make a contribution. You can make a "warm-up"
contribution at any time ... especially if it is needed to
allow the aggregation to succeed. In other words, your +n day
is the last possible day to make a contribution ... not the
first day you may make one.
Many of the current problems
are "ripple effects" from a few low level, commonly used
bundles or features (in modeling projects, it appears) so,
maybe with only a few fixes we'll be on the right path again,
but, I ask that teams try to respond as quickly as possible to
fix any "aggregation errors" they get notified about ...
please do not think you can wait until your final contribution
next week ... and even if you have not been notified yet, if
you use EMF, please "peek ahead" with the M2 versions of
Eclipse and EMF base and prepare an early version, even if you
re-contribute your final version during the (final) window
next week. After all, if we had to do a true "iteration"
waiting for each of 20 project to fix their builds
sequentially before the next one fixes theirs, then we will
not finish in time.
Thanks, for your attention, let
us know if questions or issues.
[1] http://download.eclipse.org/modeling/emf/emf/updates/2.8milestones
[2] https://bugs.eclipse.org/bugs/show_bug.cgi?id=356644
_______________________________________________
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
No virus found in
this message.
Checked by AVG - www.avg.com
Version: 10.0.1410 / Virus Database: 1520/3911 - Release Date:
09/21/11
|
