Re: [cross-project-issues-dev] Pseudo-singleton for Guava in RC3

[David M Williams <david_williams@xxxxxxxxxx>]

> 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 <ed@xxxxxxxxxxxxx>
To:      
 Cross project issues
<cross-project-issues-dev@xxxxxxxxxxx>, 
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-bounces@xxxxxxxxxxx

---

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 <ed@xxxxxxxxxxxxx>
To:        Cross
project issues <cross-project-issues-dev@xxxxxxxxxxx>,
Date:        06/03/2014
02:23 AM 
Subject:        [cross-project-issues-dev]
Pseudo-singleton for Guava in RC3 
Sent by:        cross-project-issues-dev-bounces@xxxxxxxxxxx

---

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@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: 2014.0.4592 / Virus Database: 3955/7615 - Release Date: 06/03/14

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