Until the platform changes the way they consumer EMF (i.e., after M2), you need to build against the specific EMF build that the platform did. The milestone builds of the platform and EMF do line up, do if you use the milestone repos for both (i.e., if you run a stable build) you should be good to go. Running an integration or nightly build probably won't work due to an EMF version mismatch; this won't happen once the platform requires EMF instead of including it.
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.
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 --------
Subject:
[cross-project-issues-dev] Juno M2 aggregation -- will
it be the worst milestone ever?
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.
