Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cross-project-issues-dev] Is it time to update to Guava 18?

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 versions or uses
directives, but at least from Orbit's Guava 12 on this is no longer the
case. This does not prevent non-Eclipse projects from publishing another
Guava bundle with incorrect metadata, of course -- but any
Eclipse-internal policy won't stop them either.

> 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.

I just ran a quick test for Eclipse Code Recommenders to assess the
number of API changes in Guava between version 15 and 18 that would
affect our codebase.

Luckily, the list is very short:

- Files.newInputStreamSupplier(File) gone in Guava 18.0

Of course, you would still need to verify that the *behavior* of the
remaining API didn't change. Just because it compiles doesn't mean it works.

FWIW, if other projects want to do this kind of quick-and-dirty check
("Does it still compile?"), it's surprisingly easy with Tycho:

- Use pomDependencies=consider in your target-platform-configuration [1]
- Add a POM dependency to com.google.guava:guava:18.0 (the artifact in
  Maven central has proper OSGi headers)
- Use seasrch-and-replace to update your Import-Package and Require-
  Bundle headers
- Run "mvn clean install" on the projects in question, possible
  building them one by one with -pl :artifactId, as earlier compile
  errors will prevent latter modules from being build at all

Hope this helps others to get a lower bound on the cost that such a
change would impose on their projects.

> If we are to move, I think we should all aim to move in I-builds
> immediately following M6.
> 
> There may be a maintenance issue. e.g. Xtext 2.8.0 is out,so moving to
> Guava 18 might force a 2.9.0.
> 
> I feel that barely a day before M6 is too late to request this.

Wayne Beaton wrote:
>> More generally, I think that we need a policy for these widely-shared
>> libraries. Intuitively, it makes sense to me that we should try to use
>> the most recent version released in Orbit with the simultaneous release.
>>
>> Thoughts?

The big problem with this policy is that it forces projects to maintain
branches for Luna (using the Guava 15 API) and Mars (using the Guava 18
API). Moreover, it forces users to pick the right update site, e.g.,
updates/luna/stable vs. just updates/stable.

Now, Code Recommenders did maintain a branch before (to account for some
changes to the JDT APIs with Kepler, IIRC) and offered special fragments
for Juno and later versions, respectively, but it complicated our build
and testing quite a bit. Of course, integration with JDT is arguably
core to Code Recommenders, so here branching was indeed a necessity.

For a library, however, which supplies only "trivial" stuff like
Optional and Multimaps, I would like to avoid the maintenance overhead
of branches or fragments *unless* someone can clearly demonstrate and
explain why it is absolutely necessary. IMHO, the discussion in Bug
437107 has so far failed to do that.

Just my 2 cents.

Andreas

[1]
<http://wiki.eclipse.org/Tycho/How_Tos/Dependency_on_pom-first_artifacts>

-- 
Codetrails GmbH
The knowledge transfer company

Robert-Bosch-Str. 7, 64293 Darmstadt
Phone: +49-6151-276-7092
Mobile: +49-170-811-3791
http://www.codetrails.com/

Managing Director: Dr. Marcel Bruch
Handelsregister: Darmstadt HRB 91940


Back to the top