Hi,
Looking in releases/mars/201505221000/plugins/ I see only Guava 15. If I
understand the process correctly, each project updating to Guava 18 would
have to file a CQ, and the deadline to do so for Mars was in February, so I
guess we're sticking with Guava 15 for Mars?
Cheers,
Sam
--
Sam
Hi,
I am not sure if this actually is a problem, but it might be something to
watch: If I interpret the latest unique version repo reports
(http://download.eclipse.org/releases/staging/buildInfo/reporeports/reports/nonUniqueVersions.txt
Hi guys,
I’ve filled a bug over RCPTT to update guava to at least 15:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=466770.
Best regards,
Andrey.
On 8 мая 2015 г., at 0:06, Alexander Nyßen nys...@itemis.de wrote:
Should we raise a bug against RCPTT then? As we know from past experience,
Should we raise a bug against RCPTT then? As we know from past experience,
mixing different Guava versions might be harmful.
Cheers
Alexander
Von meinem iPhone gesendet
Am 07.05.2015 um 12:35 schrieb Pierre-Charles David
pierre-charles.da...@obeo.fr:
Le 07/05/2015 09:16, Alexander
Le 07/05/2015 09:16, Alexander Nyßen a écrit :
Hi,
I am not sure if this actually is a problem, but it might be something
to watch: If I interpret the latest unique version repo reports
(http://download.eclipse.org/releases/staging/buildInfo/reporeports/reports/nonUniqueVersions.txt)
Hi Ed, hi Wayne,
See https://bugs.eclipse.org/bugs/show_bug.cgi?id=437107
in that bug report I frankly miss a clear analysis as to *why* different
Guava bundles are a problem.
Agreed, incorrect metadata is always a problem in OSGi, such as bundles
exporting com.google.common packages without
Hi Ed,
The analysis is indeed unclear because nobody has invested the time to
debug the problem or solution.
My best theory seems to be all that there is:
The problem seems to arise for a project that integrates the Guava-based
facilities of A and the Guava-based facilities of B, and
Hi
The analysis is indeed unclear because nobody has invested the time to
debug the problem or solution.
My best theory seems to be all that there is:
The problem seems to arise for a project that integrates the Guava-based
facilities of A and the Guava-based facilities of B, and when a
HI
On 25/03/2015 10:24, Andreas Sewe wrote:
Possibly, but being open to third-party plugins, we cannot prevent the
presence of multiple Guava versions in general.
Anyway, I think the burden is on the developers of integration bundles
C. You *can* shield yourself from this problem (A and B both
Hi Ed,
On 25/03/2015 10:24, Andreas Sewe wrote:
Possibly, but being open to third-party plugins, we cannot prevent the
presence of multiple Guava versions in general.
Anyway, I think the burden is on the developers of integration bundles
C. You *can* shield yourself from this problem (A and
Just to clarify, m2e is quite happy with guava 15 included in sim rel
and we will need to validate if guava 18 breaks anything. m2e does plan
to ship separate guava 18 as part of embedded maven runtime, but this
copy is not exported to OSGi and should not interfere with guava
used by other OSGi
Hi Wayne
See https://bugs.eclipse.org/bugs/show_bug.cgi?id=437107
The Luna experience was that in the absence of tooling, all projects
MUST use the same Guava, which should be the latest in Orbit.
Mixed Guava is a disaster. So far nobody seems to have moved for Mars.
If we are to move, I
12 matches
Mail list logo
