Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 358865

Summary:	[dependencies] use package imports for google guice and collections
Product:	[Modeling] TMF	Reporter:	Knut Wannheden <knut.wannheden>
Component:	Xtext	Assignee:	Project Inbox <tmf.xtext-inbox>
Status:	CLOSED WONTFIX	QA Contact:
Severity:	enhancement
Priority:	P3	CC:	dennis.huebner, sebastian.zarnekow, sven.efftinge
Version:	2.0.1	Flags:	sven.efftinge: juno+
Target Milestone:	M4
Hardware:	PC
OS:	Mac OS X - Carbon (unsup.)
Whiteboard:
Bug Depends on:
Bug Blocks:	363632

Description Knut Wannheden

2011-09-26 06:50:38 EDT

I think it would make sense if the Xtext bundles would use package imports instead of declaring required bundles for dependencies on Google Guice and Google Collections. This would allow users to use Guava instead of Google Collections and possibly also Guice 3.0.

Comment 1 Sebastian Zarnekow

2011-09-26 06:52:24 EDT

I generally like the idea but since package imports cannot be reexported, we have to find a backwards compatible solution, e.g. a mandatory package import and an optional, re-exported require-bundle?

Comment 2 Knut Wannheden

2011-09-26 09:22:59 EDT

(In reply to comment #1)
> I generally like the idea but since package imports cannot be reexported, we
> have to find a backwards compatible solution, e.g. a mandatory package import
> and an optional, re-exported require-bundle?

Good point. I hadn't thought about that. AFAICT the following bundles either reexport com.google.inject, com.google.collect, or both: org.eclipse.xtext, org.eclipse.xtext.util, org.eclipse.xtext.xbase.lib, org.eclipse.xtext.xtend2.lib.

As an alternative to solving the backwards compatibility issue it would maybe be acceptable if the user would be required to rerun the generator workflow when upgrading. The implicit fragments could then generate package imports into the manifest.

Comment 3 Dennis Huebner

2011-11-28 15:55:44 EST

A another point is that com.google.inject 3.0 (alias guice no_aop) defines a package import
Import-Package: javax.inject;version="1.0.0"
This means that all the clients switched to google Guice have to add a package import for javax.inject

Comment 4 Sven Efftinge

2011-11-29 02:31:54 EST

But javax.inject is not directly used by any clients.

Comment 5 Sebastian Zarnekow

2011-11-29 02:53:35 EST

(In reply to comment #4)
> But javax.inject is not directly used by any clients.

My client code complained about inconsistent type hierarchy for google.inject.Provider since it inherits from javax.inject.Provider. I think it would help to update the 'uses' clause on the exported package in google.inject but I'm not sure about it.

Comment 6 Sven Efftinge

2011-11-29 05:45:11 EST

We decided on sticking with require bundle. but it Xtext has been migrated to Guice 3 and Guava 10, which should solve the problem.

Comment 7 Karsten Thoms

2017-09-19 17:50:47 EDT

Closing all bugs that were set to RESOLVED before Neon.0

Comment 8 Karsten Thoms

2017-09-19 18:01:36 EDT

Closing all bugs that were set to RESOLVED before Neon.0