On 4 Jun 2012, at 17:56, Christian Edward Gruber wrote: > Hey all, > > So, I'm using guice and guice-multibinders in an open-source osgi project, > using felix and tycho to build with maven. I'm having a problem, and I see > one resolution, but thought I'd ask on this list because I want to make sure > my solution, which would change the way OSGI metadata is specified for > guice-multibinders doesn't clobber anyone, or to see if there are alternate > ways of doing this. > > I have a maven project Foo which depends on guice and guice-multibinders. > I'm having no problems with tycho having it pull in guice properly (though > all the packages are exported as version 1.3, even though the "bundle > version" is 3.0).
Tycho shouldn't care about package versions being different from the bundle version, if it did then it wouldn't be able to work with most Eclipse plug-ins. > I forced it to pull the 3.0 bundle and that worked. However, multi binders > isn't working. Not working in what way? Compilation error, runtime exception, build failure? > The difference between guice and guice-multbinders is that the latter is > listed as a fragment of the former, not a separate OSGI bundle, so I can't > get tycho to recognize it and pull it in. This sounds like a bug or missing feature in Tycho, especially since fragments are common in Eclipse plug-ins (which is the primary usecase of Tycho) and its project page states that fragments are supported. > So there are three things I want to address: > > 1. Why is guice-multibinders a fragment… it is a separate maven artifact and > in a separate java package, so there's no reason to use OSGI's fragment rules > to make it be part of guice proper. > (a) possibly this is to make sure it's loaded in the same class loader, but > I think it's an overkill approach. Multibinder.java uses code from com.google.inject.internal (specifically the Annotations and Errors classes) and since the internal package is not exported then it has to be a fragment to get access to this package. Exporting com.google.inject.internal is not a good idea, since then clients may start relying on internals which makes it harder to refactor and improve the Guice implementation in the future without breaking those clients. One possibility would be to move Annotations and Errors (or at least some public facing interface to them) to com.google.inject.utils in which case a fragment would not be required, but it feels wrong to be exposing a few internals just to satisfy a particular tool that should really be able to handle fragments (especially when fixing that tool would remove the need to make this change in the first place and help other projects with fragments). > 2. Why is guice and guice-multibinders exporting (in OSGI metadata) packages > at version 1.3, but the bundle at 3.0. Semantic versioning (http://semver.org) - the public API is still effectively binary-compatible with 1.0 from a client perspective, so therefore only the minor component has been bumped as features have been added. The bundle version is set to 3.0 to match the "marketing version" that applies to the full release - several OSGi bundles and Eclipse plug-ins follow this approach, which lets you provide fine-grained semantics about the compatibility of specific packages while still having a global version that applies to the bundle as a whole. > (a) I change any future releases of Guice so that the packages' version > matches the bundle version, would that break anyone. Please don't - there is no reason that packages should be versioned at the same level as the bundle, you would be discarding useful information and forcing clients to guess about compatibility. You would also break existing clients that previously declared version ranges assuming that Guice followed semantic rules for package versions, see http://groups.google.com/group/guice-osgi/browse_thread/thread/816f8a074a7d1241 which shows what happened to various applications when Eclipse Orbit tried to make the same change to their re-bundled copy of Guice 2. > (b) Is there a crucial reason that we need to keep everything versioned at > 1.3 Packages should be versioned according to http://semver.org - ie. only increment the major version if there is a breaking, incompatible change that would force clients to change their code and recompile. Some projects manage each package version separately using tools (such as Eclipse's API tooling) to manage their versions - Guice takes a simpler approach for now and has a shared semantic API version, but this may change in the future to allow individual package versioning. The most important thing is to keep following the semantic versioning scheme, otherwise clients cannot reason or declare anything about version compatibility. > 3. Does anyone using felix or tycho (preferably tycho) use > Guice-multibinders, and if so, how do they specify the dependency so that > multi binders are included I just add it as a dependency - then when my application is assembled it goes in the bundle directory along with other plug-ins/fragments and is installed, resolved, etc. as expected. Have you raised this on tycho-u...@eclipse.org? I think that would be a better place to discuss this, since it probably involves Tycho-specific settings/configuration. > cheers, > Christian. > > -- > You received this message because you are subscribed to the Google Groups > "google-guice" group. > To post to this group, send email to google-guice@googlegroups.com. > To unsubscribe from this group, send email to > google-guice+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/google-guice?hl=en. > -- You received this message because you are subscribed to the Google Groups "google-guice" group. To post to this group, send email to google-guice@googlegroups.com. To unsubscribe from this group, send email to google-guice+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-guice?hl=en.
