[
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?
|
> Wouldn't it be
better if features were release and SR-named not version numbered?
Sure seems like it, doesn't it ... but
then we really would be locked in to making sure the yearly named lexically
increased in a nice orderly fashion. And, I'm sure there'd be other complications
of have a string where an integer used to be. If you mean this for "self
documenting clarity" I know there used to be an old feature enhancement
request to add a human friendly "description" of the version,
sometime called "marketingString" (see Bug 115482)
... but, alas, seems there was not enough motivation for anyone to actually
work on it. Feel free to open a new enhancement request in p2 (and/or search
for a new one open already, I didn't see it, but I didn't look very hard).
And, don't forget, it gets complicated when people have off-cycle releases
... occasionally people make a "major change" for their adopters,
say, in December, that is not part of any (current) Simultaneous Release,
so I think a mere descriptive name, to improve self documentation, is the
best that could ever be hoped for.
Now, back to my selfish interests :) ... I'm guessing
there will be a new contribution soon (at least a "warmup" build)
where the OCL contribution fits in ... or, should I start mass exclusions
today?
Much thanks,
From:
Ed Willink <ed@xxxxxxxxxxxxx>
To:
Cross project issues
<cross-project-issues-dev@xxxxxxxxxxx>
Date:
09/23/2011 05:59 AM
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 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_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev