Community
Participate
Working Groups
The removal of the optional dependency in ECF caused unexpected problems for consumers[1]. We have restored the dependency to optional and made it greedy [2]. Platform may pickup the new ECF 3.5.6 build from http://download.eclipse.org/rt/ecf/3.5.6/site.p2/ qualifier: 3.5.6.v20120610-1946 [1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=382179 [2] https://bugs.eclipse.org/bugs/show_bug.cgi?id=382039#c8
*** Bug 382297 has been marked as a duplicate of this bug. ***
FYI, I have confirmed that when the aggregator runs and combine things in /releases/staging, that the Platform's (current) version "wins" ... That is, there is no mention of org.eclipse.equinox.concurrent.future in the "greediness report" (which should list any optional dependency) http://build.eclipse.org/juno/simrel/reporeports/reports/greedyReport.html But, if I run is against ECF's repo it is listed as would be expected: = = = = = = Probable problem. Optional requirements with implicit greedy install (old publisher default) Total Count: 1 Unique Count: 1 org.eclipse.equinox.concurrent.future Number of IUs using optional, but greedy for this case: 1 org.eclipse.ecf = = = = This is simply a matter of the normal p2 behavior similar to an "install" .. by the time it gets ECF's contribution, it has decided it already has a version of org.eclipse.ecf that "satisfies constraints". I'm not sure if this is completely deterministic, or if there is an element of chance here ... just documenting what I see.
(In reply to comment #2) > FYI, I have confirmed that when the aggregator runs and combine things in > /releases/staging, that the Platform's (current) version "wins" ... > > That is, there is no mention of > org.eclipse.equinox.concurrent.future > in the "greediness report" (which should list any optional dependency) > http://build.eclipse.org/juno/simrel/reporeports/reports/greedyReport.html > > But, if I run is against ECF's repo it is listed as would be expected: > = = = = = = > Probable problem. Optional requirements with implicit greedy install (old > publisher default) > > Total Count: 1 > > Unique Count: 1 > > org.eclipse.equinox.concurrent.future > > Number of IUs using optional, but greedy for this case: 1 > org.eclipse.ecf > = = = = Given the markup that's now present...i.e. resolution:-optional;x-installation:-greedy this is what I would expect (the old/original behavior...i.e. greedy for p2 metadata, but optional resolution...this is as it was before all this started. I think this is what's wanted (back to before the original issue). It means that 1) org.eclipse.ecf has an optional dependency on concurrent (which is what the p2 consumers want...so that they can build their products that depend upon p2 and ECF without including concurrent) and 2) Concurrent is installed greedily in the platform...without a required/hard dependency Again...I believe this just restores the situation (for org.eclipse.ecf and concurrent) that we had before this all began with bug 381478. This seems to me to be the most mutually agreeable thing.
The problem is we are now four days past our final build deadline for Juno. We have a frail build and test system that will take at least 24 hours to run and verify there are no new problems. I don't think bug 382179 by itself is severe enough for such a last minute scramble. I am tempted to suggest we live with this current bug, take a deep breath, and carefully decide on a good fix for the ECF/concurrent dependency problem in Juno SR1. Eclipse/Equinox PMC members please chime in with your opinion. Wim/Scott, would it cause further problems for your project if we did *not* pick up this build and stayed with our current RC4 build? Regardless what we decide, thank you for your quick response and offer of a rebuild for bug 382179.
(In reply to comment #4) > The problem is we are now four days past our final build deadline for Juno. We > have a frail build and test system that will take at least 24 hours to run and > verify there are no new problems. I don't think bug 382179 by itself is severe > enough for such a last minute scramble. I am tempted to suggest we live with > this current bug, take a deep breath, and carefully decide on a good fix for > the ECF/concurrent dependency problem in Juno SR1. Eclipse/Equinox PMC members > please chime in with your opinion. > I agree that bug 382179 by itself is not severe enough to do a last minute respin. My concern is what the ECF project is planning to contribute to Juno. No matter what the final decision is I would like all projects involved to contribute the same org.eclipse.ecf artifact to the Juno repository.
(In reply to comment #4) <stuff deleted> > Wim/Scott, would it cause further problems for your project if we did *not* > pick up this build and stayed with our current RC4 build? Regardless what we > decide, thank you for your quick response and offer of a rebuild for bug > 382179. You're welcome. The main issue for us is the one Thomas identified below. > I agree that bug 382179 by itself is not severe enough to do a last minute > respin. My concern is what the ECF project is planning to contribute to Juno. > No matter what the final decision is I would like all projects involved to > contribute the same org.eclipse.ecf artifact to the Juno repository. I agree about the concern of having two versions of ECF in Juno and Eclipse...although I don't think it will cause the platform or Eclipse consumers any difficulty...this has been the way things have operated for a long time now (we've frequently had newer versions of ECF in the SR than in Eclipse). And unfortunately, with our build process it's not a simple/trivial matter for us to go back to a previous release build. I understand about deadlines and such, but it seems to me that to avoid the risk involved for platform consumers (bug 382179), it would be worth a respin. FWIW, other than this meta-data change, there were/are exactly zero differences between our two builds...so its low risk.
(In reply to comment #6) > I understand about deadlines and such, but it seems to me that to avoid the > risk involved for platform consumers (bug 382179), it would be worth a respin. > FWIW, other than this meta-data change, there were/are exactly zero differences > between our two builds...so its low risk. Unfortunately our concern is not about the risk of accepting the new ECF content. As you, I believe the ECF change to be low risk. Our concern is the stability of our builds. With all the recent churn in our build and the move to eclipse infrastructure we are not quite as agile as we have been in the past. If this difference in org.eclipse.ecf artifact is not a stop ship concern for you then I am leaning towards not doing this in post RC4. We can pick this up in SR1.
(In reply to comment #7) > ... Our concern is the stability of our builds. > Exactly. To me the most important question is "Can we get back to steady state quick enough to avoid disrupting the rest of the community?". How about we ping cross-project to see what kind of impact people believe there could be?
I don't consider this a stop ship and hence -1 to rebuild RC4 at this point.
So... in my understanding, bug 382179 has been resolved by ECF reverting the "hard dependency" in bug 382039 thus the most severe issue is gone. There was something said about filetransfer not working without o.e.equinox.concurrent ... looking at the Eclipse Platform SDK RC4 build, is there any limitation to be expected because concurrent is not there ?
(In reply to comment #10) > There was something said about filetransfer not working without > o.e.equinox.concurrent ... looking at the Eclipse Platform SDK RC4 build, is > there any limitation to be expected because concurrent is not there ? org.eclipse.equinox.concurrent is back in the RC4 build. The new problem is that because it is a non-optional dependency, any existing application/feature that contained ECF but didn't already contain concurrent will be broken. I don't know whether presence of equinox.concurrent has any effect on ECF file transfer. The basic p2 operations did work in the one or two builds where concurrent was absent, but there may be other scenarios that would fail.
(In reply to comment #11) > I don't know whether presence of equinox.concurrent has any effect on ECF file > transfer. It does not. Filetransfer will work with or without concurrent present.
(In reply to comment #7) > Our concern is the stability of our builds. This is in no way to be interpreted as a critic on all effort our releng team (thanks David!) has put into the builds. I believe our builds are quite stable, but the tests are not and this is not a reflection of the releng team. If we decide to respin it will take a long time (24 hours or so?) to get the test run complete and confirmation from the teams that we are a go. Plus and respin is high risk at this point.
Ok, so - whoever consumes ECF from Platform has the non-optional dependency, but this looks like a non-issue since Platform also does have concurrent - whoever consumes ECF standalone has the optional greedy dependency - the remaining issue is that there's two versions of ECF in Juno and the Platform one seems to win Sounds like using the Juno Repo one can't build a product without concurrent ? Seems not an issue for Platform, but is it an issue for ECF / Others ? Anything else I'm missing ?
(In reply to comment #14) > Ok, so > > - whoever consumes ECF from Platform has the non-optional dependency, but > this looks like a non-issue since Platform also does have concurrent What you say is true, but my understanding is that it is an issue for some product-based consumers of p2...because if their products currently do not include concurrent, and if they simply update to Eclipse Juno, the new required dependency on concurrent in ECF core will break those products. > > - whoever consumes ECF standalone has the optional greedy dependency What people typically do is consume ECF and Equinox/Eclipse...and so in that case they get the Equinox/Eclipse versions of ECF core...whatever they happen to be. > > - the remaining issue is that there's two versions of ECF in Juno and the > Platform one seems to win Since the platform specifies a specific version of ECF as part of their feature...and the *other* parts of ECF (i.e. not core+filetransfer) don't care what version of these plugins are used...p2 will give them the Eclipse version. > > Sounds like using the Juno Repo one can't build a product without concurrent ? Right...with the build that the platform is using, they will need to include/add concurrent. The reason for this is that the concurrent dep was changed to required, meaning the ECF core plugin (of that version) will not resolve unless concurrent is present. This was changed back to optional (but greedy introduced) as reported by this bug. > Seems not an issue for Platform, but is it an issue for ECF / Others ? > Anything else I'm missing ? I would say that it's primarily an issue for those that have products that use p2+ECF filetransfer, but do not also include concurrent. I don't know how many/who those are.
So, all in all ... ECF is back to what it was pre-RC3, right ? I had been in favor of "don't change things late in the game" when we discussed the removal of equinox.concurrent in Platform RC3, and that still stands. Thus I'm +1 for re-spinning Platform RC4 in order to - re-establish pre-RC3 behavior, and - ensure a consistent Juno. IMO quiet week is there for exactly things like this.
(In reply to comment #16) > So, all in all ... ECF is back to what it was pre-RC3, right ? WRT this particular dependency...yes, that's right.
I have concerns about such a late re-spin. Can we try a build and if something goes horribly awry keep the current submission?
+1 for doing a build and checking it before submitting. I'd assume that thanks to the publisher / comparator, most bundles should remain binary unchanged except the ECF ones - so that would be a good sanity check ?
There is already a -1 vote on this bug, but just to double-check we talked about it again at the PMC call today. The decision was not to do a rebuild. The main considerations are: 1) The impacted team (p2) does not believe it is an urgent bug for Juno. 2) Our automated tests are not currently fully transitioned to Hudson and it is a long and error-prone process to verify and sign-off on a new build. 3) By our own freeze plan rules, post RC4 builds are reserved for only the most severe stop-ship defects. I'll leave this bug open so we can arrive at an answer for Juno SR1.
>There is already a -1 vote on this bug, but just to double-check we talked >about it again at the PMC call today. The decision was not to do a rebuild. It would make sense, I believe, to notify consumers of p2 (perhaps through mailing list...or some other, broader way) about the implications of the choice to not do a Platform rebuild to pick up this update...i.e. that products updating to Juno may now need to add a new bundle (concurrent) to their product builds. Maybe you have this already planned...I just wanted to point it out.
I'm hitting an issue upgrading the target platform of a custom RCP application to Juno. When I upgrade the "Equinox p2 Core Function" feature (which includes ECF bundles) I wind up with this non-optional dependency on o.e.equinox.concurrent. I've gotten around this by adding the "Equinox Core SDK" feature to my target and then adding o.e.equinox.concurrent to one of my own features. Though I don't claim to understand all the build issues discussed here, I think my problem may be related. This will affect all RCP developers who use the p2 Core feature to add headless-update functionality to their applications.
> my problem may be related. This will affect all RCP developers who use the p2 > Core feature to add headless-update functionality to their applications. Yes. It will be fixed with SR1.
concurrent source is here: http://git.eclipse.org/c/equinox/rt.equinox.bundles.git/tree/bundles/org.eclipse.equinox.concurrent
I've updated our maps and other references in all three streams now. I still think for Kepler efforts should be make to avoid these "greedy optional requirements" and instead define contents explicitly with features, since the "hidden" greedy attribute can complicate things such as providing feature patches, not allowing user choice, etc. But, for now at least in sync.
Verified in M20120822-1000 (3.8.1) and M20120822-1200 (4.2.1).
