Community
Participate
Working Groups
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.
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?
(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.
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
But javax.inject is not directly used by any clients.
(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.
We decided on sticking with require bundle. but it Xtext has been migrated to Guice 3 and Guava 10, which should solve the problem.
Closing all bugs that were set to RESOLVED before Neon.0
