> I think that someone with the power to influence the platform needs to review how > we support Guava and other shared non-singletons > so that we avoid repeating this mess in Mars.
Hmmm, I think, Ed, I finally found one thing to disagree with you about :) I think if you (or others) carefully read Bug 427862 you'd find this issue less about "using one version" and more about using correct versions, in correct ways: a) projects should follow "best practices" for componentization (such as, 1) do not "re-export" bundles simply for a convenience, 2) don't make "third party" code part of your own API (unless it's one that's mature, and one that can be well trusted to follow OSGi principles), 3) use proper version ranges when exporting or importing packages, 4) take advantage of "uses clauses", etc.) and b) we need to influence those third parties who are not using OSGi quite right, and encourage them to do so (which has happened, in this case!) It seems all (or many) of those things have happened for Guava, I assume partially due to your efforts, so I do not think there is a problem for "the platform" to solve ... and think that we all need to learn more about correct componentization, following OSGi guidelines and best practices. (And, I know, that's not easy .... but, do believe that's the best solution). Almost anything that is solved by "having only one version" is simply "building one application" ... not "building components". Not to mention, this painful experience has shown the importance of the "Simultaneous Release Train" ... it would have taken years to sort this out, if everyone was on their own, unrelated, schedule. In short, I don't think you give yourself enough credit on how much you've improved things ... not because we use "one version", but because we use a "proper version" in the "the correct way". Perhaps I am over simplifying, or not aware of still-lurking problems? Or, perhaps you simply mean we need better tools; such as warning people if they re-export foreign bundles (or, if they use a bundle that does that questionable practice) ... or don't properly use versions when exporting/importing packages (the former, I think might be valid enhancement request, the latter I believe is implemented, but defaults to "off"?) But most of all, I want to say thanks to you, and everyone else who has worked hard to get past this particular issue, and am sure we all would respect concrete requests to improve tools ... but, naturally, making the request is not the same as "getting it done" and I hope everyone knows we can't always rely on a "nebulous platform" to solve problems, but ask ourselves, "what can I implement". Thanks again for your (continued) efforts, From: Ed Willink <e...@willink.me.uk> To: Cross project issues <cross-project-issues-dev@eclipse.org>, Date: 06/04/2014 04:33 AM Subject: Re: [cross-project-issues-dev] Pseudo-singleton for Guava in RC3 Sent by: cross-project-issues-dev-boun...@eclipse.org Hi Papyrus is 12, skipped RC2, but I think should be ok for RC3. https://bugs.eclipse.org/bugs/show_bug.cgi?id=422745 Further to my earlier, 10, then 15 then 12 observations. When I then install Mylyn Wikitext, 15 came back again, 12 stayed. Hopefully a de facto 15-only policy will hide the problems, until users add third party non-15 contributions. I think that someone with the power to influence the platform needs to review how we support Guava and other shared non-singletons so that we avoid repeating this mess in Mars. Regards Ed Willink On 04/06/2014 01:44, David M Williams wrote: Ed, Guess you know now it's not related to bug 436418, given the discussion and diagnosis given there. https://bugs.eclipse.org/bugs/show_bug.cgi?id=436418 Ordinarily, it's hard to infer much by "what's in the directory and what's not" ... at least, as I understand it ... the exact point that bundles/features are "cleaned up" after multiple installs is an "implementation detail" of when p2 does "garbage collection" and, from my memory, is not that predictable. Unfortunately, I'm not sure "how to tell" what's current .... what's in "bundle info" file or "artifacts xml" ... perhaps a p2 committer will see this and say. In any case, in the latest repo report, http://build.eclipse.org/simrel/luna/reporeports/reports/nonUniqueVersions.txt it seems we are down to 2 versions in Sim. Release repo: 12 and 15. I've not looked at log, but am curious who will requires "12" and if that's a hard requirement, an oversight, or perhaps a mistake in the way constraints are specified? Hope RC is better ... at least in terms of what gets in EPP packages, if nothing else. I hope you'll continue your investigations and keep us all posted. Thanks, From: Ed Willink <e...@willink.me.uk> To: Cross project issues <cross-project-issues-dev@eclipse.org>, Date: 06/03/2014 02:23 AM Subject: [cross-project-issues-dev] Pseudo-singleton for Guava in RC3 Sent by: cross-project-issues-dev-boun...@eclipse.org Hi I'm not sure if the following is an RC3 regression or an improvement; it's certainly surprising. Up until RC2 multiple Guava's could accumulate in the plugins directory. While incrementally building another RC3 installation from ZIPs to observe the plugins directory, I saw Installation of Platform, EMF, GEF - no com.google.guava Installation of MWE 2.6.0 - com.google.guava 10.0 (Bug 436420 raised) Installation of Xtend from M2T/Xpand RC1 - no change Installation of Xtext 2.6.0 - com.google.guava 10.0 is removed - com.google.guava 15.0 is added - com.google.guava.source 15.0 is added .... Installation of Papyrus 1.0.0 RC1 - com.google.guava 15.0 is removed - com.google.guava.source 15.0 remains - com.google.guava 12.0 is added The removals above are new to RC3 and are perhaps beneficially enforcing a pseudo-singleton. Was this really intended? Is it related to: https://bugs.eclipse.org/bugs/show_bug.cgi?id=436418 in which the Plugin registry no longer has dependents. Regards Ed Willink _______________________________________________ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev _______________________________________________ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev No virus found in this message. Checked by AVG - www.avg.com Version: 2014.0.4592 / Virus Database: 3955/7615 - Release Date: 06/03/14 _______________________________________________ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
