[bccing google-guice, since this is more of a tycho issue] Thanks, Stuart. I was actually about to copy this to you directly. :D
Summary - the versions aren't the issue, they were a surface symptom. Responses inline, and as stated above, upon some conversation I had with Sam Berlin and this reply, this is more of a tycho issue than a guice packaging issue. On Jun 4, 2012, at 1:47 PM, Stuart McCulloch wrote: > On 4 Jun 2012, at 17:56, Christian Edward Gruber wrote: >> 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. No it shouldn't, but when I had an Import-package osgi dependency and used "considerPom" resolution, it wasn't pulling in guice unless I explicitly pulled in com.google.inject bundle using Require-bundle metadata. Actually, when I remove the versions, guice works as well as before, as long as I'm pulling it in as a bundle dependency, not a set of package dependencies. guice-ultibinders, however, don't work either as a Require-bundle or an Import-package dependency. But it seems that the versions was a side-symptom I was mistaking as the problem, because the dependency as a whole wasn't being satisfied, whatever osgi thought the version was. >> 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? Sorry, build failure - from the command-line, and in Eclipse via M2E, I'm getting a dependency "cannot be resolved" error. > >> 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. Maybe so - I'm hoping I'm just failing to specify something. >> 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). Ok - I understand much more clearly (this + some discussion with sberlin) and I can see, but but if an extension to guice is using it, it's not really exactly "internal" in that sense. I'm very happy to move some of these things into a more public space, as public as the SPI, since they're needed to implement the extensions. This is a further discussion to be had in the guice world, but not exactly "util" but some sort of extensions-API/SPI DMZ would be helpful. >> 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. Yep - I get it now. I have, historically, tended to make my marketing versions identical to my semantic versions, but I see that Guice hasn't done so, so I kind of missed it. And we always work from HEAD inside google, so I've apparently gone native and lost some of my finer instincts about versions. :) >> (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. I get it, and I agree. > 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. Heh. War stories. > >> (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. I get it, and I agree, and it's nice to be talking to maven folks about versions. My former thinking is starting to re-surface a bit. > 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. Yeah… that's extremely unlikely to happen in any google project. Guava isn't even going to provide distinct artifacts for com.google.common.* sub packages, and guice is far more "intact". If anything, I could see it for the extensions, but each is in its own artifact already, so there's little distinction there. > >> 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. yeah… guice does so nicely, guice-multibinders, not so much. And I have them both specced in the pom.xml file like so (abbreviated, but cut and pasted). <project ...> … <packaging>eclipse-plugin</packaging <properties> <tycho-version>0.15.0</tycho-version> </properties> ... <dependencies> ... <dependency> <groupId>com.google.inject</groupId> <artifactId>guice</artifactId> <version>3.0</version> </dependency> <dependency> <groupId>com.google.inject.extensions</groupId> <artifactId>guice-multibindings</artifactId> <version>3.0</version> </dependency> </dependencies> <build> <plugins> <plugin> <groupId>org.eclipse.tycho</groupId> <artifactId>tycho-maven-plugin</artifactId> <version>${tycho-version}</version> <extensions>true</extensions> </plugin> <plugin> <groupId>org.eclipse.tycho</groupId> <artifactId>target-platform-configuration</artifactId> <version>${tycho-version}</version> <configuration> <pomDependencies>consider</pomDependencies> <resolver>p2</resolver> </configuration> </plugin> </plugins> </build> <repositories> <repository> <id>p2.eclipse.juno</id> <layout>p2</layout> <url>http://download.eclipse.org/releases/juno/</url> </repository> </repositories> </project> > > Have you raised this on [email protected]? I think that would be a > better place to discuss this, since it probably involves Tycho-specific > settings/configuration. > done. Christian. -- You received this message because you are subscribed to the Google Groups "google-guice" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-guice?hl=en.
