has vanished in UML2 4.0.0. Regenerating the OCL models fixes this,
but it proves that UML2 4.0 and 3.x are incompatible. MDT/OCL for
Juno can only be compatible with UML2 3.0 or 4.0 but not both,
unless someone goes to probably unwarranted effort to make the
auto-generated model API compatible.
The [3.0.0,5.0.0) may be flawed but it will at least allow other
projects to build for M2 so long as they don't actually use OCL +
UML.
Regards
Ed
On 22/09/2011 14:27, Kenn Hussey wrote:
Guys,
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.
