Skip to main content

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

Hi David

Sorry my bad; too engrossed in one problem to heed advice on the next step.

I think I have overinterpreted the versioning rules. We only a need a major increment for UML-related plugins and almost all features. This should be friendly downstream where consumers just reference by feature name and mostly use non-UML plugins; consumers will just need to get their platform, EMF, UML repos right.

This seems to align with advice in http://wiki.eclipse.org/Version_Numbering#Require_features which points out that feature versions are brittle. It seems we will have over 90% of the project at 3.2 but a small part at 4.0 and so almost all features at 4.0.

Wouldn't it be better if features were release and SR-named not version numbered? i.e. org.eclipse.ocl.master_Juno.0.v20120606.

    Regards

        Ed Willink



On 23/09/2011 02:45, David M Williams wrote:
[I saw Kenn's reply, just before pressing "send" ... he says it all ... but, if you like long wordy, detailed explanations, here's my version.]


Here's my understanding (little as that is) ... of the EMF and platform situation for M2.

If you use EMF (common, or ecore features) you must use

http://download.eclipse.org/modeling/emf/emf/updates/2.8milestones

as it is the one that has the two features:

org.eclipse.emf.common_2.7.0.v20110916-1359
org.eclipse.emf.ecore_2.8.0.v20110916-1359

And, those are the two features that the Eclipse M2 repository _also_ provides, in

http://download.eclipse.org/eclipse/updates/4.2milestones/S-4.2M2-201109161615

And ... at least some of the bundles in there are singletons, so only one can be installed at a time. And, currently,
the platform does an "include" instead of a "require" which tightens the constraints even further (which is the subject of bug 356644).  

Sort of a perfect storm.

The b3 aggregator (and, likely the buckminster build, the output of which included in note below) checks to make sure "all is installable together" (That is, after all, one of the main reason of using the aggregator, it does not do a blind mirror of bundles and features (if it did, sure, the mirroring might succeed, but the results would not be installable ... a "build time error" detection rather than a waiting to find a "runtime error").

Oh, and, I should have said, EMF's I-build location (in the output below) does not have that "most recent" EMF features that the platform and EMF's milestone site includes ... I am not sure what the EMF team's typical practice is in this regard, but know that for this milestone they did "jump through hoops" to work around this include/require issue at the same time building _for_ the platform, as well as _against_ the platform. (And, it is appreciated).

Is your head spinning yet? I know mine is :) ... but, I hope this helps explain the current situation. Things should be better for M3, but until then, there is this tight requirement that everyone use exactly these versions of emf.common and emf.ecore -- well, if you do any sort of 'include' and/or if your build process requires a correct and consistent target. [And, teams involved, feel free to correct me where I've erred].








From:        Ed Willink <ed@xxxxxxxxxxxxx>
To:        Cross project issues <cross-project-issues-dev@xxxxxxxxxxx>
Date:        09/22/2011 03:04 PM
Subject:        Re: [cross-project-issues-dev] Juno M2 aggregation -- will it be the worst milestone ever?
Sent by:        cross-project-issues-dev-bounces@xxxxxxxxxxx




Hi

For MDT/OCL
> We plan to commit a dependency change to [4,5) shortly that should
> allow other downstream projects to build, provided that they too
> change to UML [4,5). This should be available perhaps within 12 hours
> if Hudson and other factors are co-operative.
We are trying to build a candidate, but get
(
https://hudson.eclipse.org/hudson/job/buckminster-mdt-ocl-core-3.2-master/440/console)

WARNING [0004] : Component request org.eclipse.emf.common:eclipse.feature/[2.7.0.v20110912-1000,2.7.0.v20110912-1000] 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.8.0.v20110912-1000,2.8.0.v20110912-1000] is inconflict with request org.eclipse.emf.ecore:eclipse.feature/[2.8.0.v20110916-1359,2.8.0.v20110916-1359]
ERROR   [0113] : 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 file:/opt/users/hudsonbuild/workspace/buckminster-mdt-ocl-core-3.2-master/org.eclipse.ocl.git/releng/org.eclipse.ocl.releng.buckminster/releng/ocl-platform.rmap
  ERROR   [0113] : 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   [0113] : Rejecting provider p2({0}/modeling/emf/emf/updates/2.8-I-builds[file:/home/data/httpd/download.eclipse.org/modeling/emf/emf/updates/2.8-I-builds]): No component match was found
ERROR   [0113] : 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:/opt/users/hudsonbuild/workspace/buckminster-mdt-ocl-core-3.2-master/org.eclipse.ocl.git/releng/org.eclipse.ocl.releng.buckminster/releng/ocl-platform.rmap
  ERROR   [0113] : 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   [0113] : Rejecting provider p2({0}/modeling/emf/emf/updates/2.8-I-builds[file:/home/data/httpd/download.eclipse.org/modeling/emf/emf/updates/2.8-I-builds]): No component match was found
INFO:  TAG-ID 0004 = Query for org.eclipse.ocl.releng.buckminster:buckminster, path: org.eclipse.ocl.releng.buckminster:buckminster$0.1.0.qualifier ->  org.eclipse.emf:eclipse.feature$2.8.0.v20110913-1544
TAG-ID 0113 = Query for org.eclipse.ocl.releng.buckminster:buckminster, path: org.eclipse.ocl.releng.buckminster:buckminster$0.1.0.qualifier ->  org.eclipse.platform:eclipse.feature$4.1.0.v20110612-1800-9JF70HDuFo6EMhMISblH-cp6WYcpnVwlmX9L-0_CgNLen ->  org.eclipse.rcp:eclipse.feature$4.1.0.v20110822-9-CVG2DFlt5xpcTFqQa2DE2YQl6C ->  org.eclipse.e4.rcp:eclipse.feature$1.1.0.v20110712-1859-7HAN6FTy21UwAsXPk5BIP

Are there conflicting EMF repositories?

                Regards

                                 Ed Willink


_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev




_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev


No virus found in this message.
Checked by AVG - www.avg.com
Version: 10.0.1410 / Virus Database: 1520/3912 - Release Date: 09/22/11


Back to the top