Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [mdt-ocl.dev] Fwd: [cross-project-issues-dev] Juno M2 aggregation -- will it be the worst milestone ever?

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.

Note that the M2 build of UML2 has been posted.

Kenn

2011/9/22 Adolfo Sánchez-Barbudo Herrera <adolfosbh@xxxxxxxxxxxxxxxx>
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 --------
Subject: [cross-project-issues-dev] Juno M2 aggregation -- will it be the worst milestone ever?
Date: Wed, 21 Sep 2011 22:54:15 -0400
From: David M Williams <david_williams@xxxxxxxxxx>
Reply-To: Cross project issues <cross-project-issues-dev@xxxxxxxxxxx>
To: cross-project-issues-dev@xxxxxxxxxxx


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

--
Open Canarias, S.L.
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

_______________________________________________
mdt-ocl.dev mailing list
mdt-ocl.dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/mdt-ocl.dev



Back to the top