[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[tycho-user] Tycho seems to not pull guice-multibinders properly… possibly because it's a fragment? (Was: Re: Guice and multibinders OSGI versioning and metadata)

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

> Have you raised this on tycho-user@xxxxxxxxxxx? I think that would be a better place to discuss this, since it probably involves Tycho-specific settings/configuration.