Discussion:
Tycho seems to not pull guice-multibinders properly… possibly because it's a fragment? (Was: Re: Guice and multibinders OSGI versioning and metadata)
(too old to reply)
Christian Edward Gruber
2012-06-04 20:26:28 UTC
Permalink
[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.
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.
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>
done.

Christian.
Igor Fedorenko
2012-06-04 21:43:34 UTC
Permalink
What is exact error message do you get from command line build? Can you
paste bundle manifest (snippet) that you believe should bring required
dependency?

--
Regards,
Igor
Post by Christian Edward Gruber
[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.
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.
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>
done.
Christian.
_______________________________________________
tycho-user mailing list
https://dev.eclipse.org/mailman/listinfo/tycho-user
Christian Edward Gruber
2012-06-04 22:09:58 UTC
Permalink
If I use Import-package: com.google.inject.multibinders then I get the following on the command-line:

Missing requirement: com.google.my.eclipse.thingy 1.0.0.qualifier requires 'package com.google.inject.multibinders 0.0.0' but it could not be found

and in eclipse it's unsatisfied and I get no jar on my class path, and the following error (in the message of a RTE stack trace):

"Unable to satisfy dependency from com.google.my.eclipse.thingy 1.0.0.qualifier to bundle com.google.inject.multibinders 0.0.0."

If I make it a Require-bundle, it fails (presumably because it's not a bundle, it's a fragment) in the following way:

Bundle 'com.google.inject.multibinders' cannot be resolved

in eclipse with tycho/m2e, and on the command line, it's

Missing requirement: com.google.my.eclipse.thingy 1.0.0.qualifier requires 'bundle com.google.inject.multibinders 0.0.0' but it could not be found

followed by the familiar:

"Unable to satisfy dependency from com.google.my.eclipse.thingy 1.0.0.qualifier to bundle com.google.inject.multibinders 0.0.0."

This is with the aforementioned pom, and this (abbreviated) MANIFEST.MF:

Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-Name: [censored for your pleasure]
Bundle-SymbolicName: com.google.my.eclipse.thingy;singleton:=true
Bundle-Version: 1.0.0.qualifier
Bundle-Activator: com.google.some.plugin.class.SomePlugin
Require-Bundle:
com.google.my.eclipse.abundle; bundle-version="[1.0.0,2.0.0)",
com.google.my.eclipse.bbundle; bundle-version="[1.0.0,2.0.0)",
com.google.my.eclipse.cbundle; bundle-version="[1.0.0,2.0.0)",
com.google.my.eclipse.dbundle; bundle-version="[1.0.0,2.0.0)",
com.google.inject,
org.eclipse.ui,
org.eclipse.core.runtime,
org.eclipse.core.resources,
org.eclipse.jdt.core,
org.eclipse.ui.editors,
org.eclipse.ui.ide,
org.eclipse.jdt.ui,
org.eclipse.wst.jsdt.core,
org.eclipse.jface.text,
org.eclipse.wst.jsdt.ui,
org.eclipse.ui.workbench.texteditor,
org.eclipse.ltk.ui.refactoring,
org.eclipse.ltk.core.refactoring,
org.eclipse.search
Import-Package:
com.google.common.base,
com.google.common.collect,
com.google.inject.multibinders,
com.google.protobuf
Bundle-ActivationPolicy: lazy
Bundle-RequiredExecutionEnvironment: JavaSE-1.6
Bundle-ClassPath: .
Bundle-Vendor: Google Inc.
Export-Package:
com.google.my.eclipse.thingy



cheers,
Christian
Post by Igor Fedorenko
What is exact error message do you get from command line build? Can you
paste bundle manifest (snippet) that you believe should bring required
dependency?
--
Regards,
Igor
Post by Christian Edward Gruber
[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.
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.
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>
done.
Christian.
_______________________________________________
tycho-user mailing list
https://dev.eclipse.org/mailman/listinfo/tycho-user
_______________________________________________
tycho-user mailing list
https://dev.eclipse.org/mailman/listinfo/tycho-user
Igor Fedorenko
2012-06-05 00:41:24 UTC
Permalink
I think you have a typo in the bundle manifest. It should be
Import-Package 'com.google.inject.multibindings', not
'com.google.inject.multibinders' you have it in your paste.
I attached a working example just in case.

Also, beware that both eclipse juno and orbit p2 repositories contain
orbit versions of com.google.inject and com.google.inject.multibindings.
Orbit uses four-part versions, which are considered "newer" compared to
what's in Central, so Tycho uses Orbit versions. Not sure if this
important or not.

--
Regards,
Igor
Post by Christian Edward Gruber
Missing requirement: com.google.my.eclipse.thingy 1.0.0.qualifier requires 'package com.google.inject.multibinders 0.0.0' but it could not be found
"Unable to satisfy dependency from com.google.my.eclipse.thingy 1.0.0.qualifier to bundle com.google.inject.multibinders 0.0.0."
Bundle 'com.google.inject.multibinders' cannot be resolved
in eclipse with tycho/m2e, and on the command line, it's
Missing requirement: com.google.my.eclipse.thingy 1.0.0.qualifier requires 'bundle com.google.inject.multibinders 0.0.0' but it could not be found
"Unable to satisfy dependency from com.google.my.eclipse.thingy 1.0.0.qualifier to bundle com.google.inject.multibinders 0.0.0."
Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-Name: [censored for your pleasure]
Bundle-SymbolicName: com.google.my.eclipse.thingy;singleton:=true
Bundle-Version: 1.0.0.qualifier
Bundle-Activator: com.google.some.plugin.class.SomePlugin
com.google.my.eclipse.abundle; bundle-version="[1.0.0,2.0.0)",
com.google.my.eclipse.bbundle; bundle-version="[1.0.0,2.0.0)",
com.google.my.eclipse.cbundle; bundle-version="[1.0.0,2.0.0)",
com.google.my.eclipse.dbundle; bundle-version="[1.0.0,2.0.0)",
com.google.inject,
org.eclipse.ui,
org.eclipse.core.runtime,
org.eclipse.core.resources,
org.eclipse.jdt.core,
org.eclipse.ui.editors,
org.eclipse.ui.ide,
org.eclipse.jdt.ui,
org.eclipse.wst.jsdt.core,
org.eclipse.jface.text,
org.eclipse.wst.jsdt.ui,
org.eclipse.ui.workbench.texteditor,
org.eclipse.ltk.ui.refactoring,
org.eclipse.ltk.core.refactoring,
org.eclipse.search
com.google.common.base,
com.google.common.collect,
com.google.inject.multibinders,
com.google.protobuf
Bundle-ActivationPolicy: lazy
Bundle-RequiredExecutionEnvironment: JavaSE-1.6
Bundle-ClassPath: .
Bundle-Vendor: Google Inc.
com.google.my.eclipse.thingy
cheers,
Christian
Post by Igor Fedorenko
What is exact error message do you get from command line build? Can you
paste bundle manifest (snippet) that you believe should bring required
dependency?
--
Regards,
Igor
Post by Christian Edward Gruber
[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.
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.
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>
done.
Christian.
_______________________________________________
tycho-user mailing list
https://dev.eclipse.org/mailman/listinfo/tycho-user
_______________________________________________
tycho-user mailing list
https://dev.eclipse.org/mailman/listinfo/tycho-user
_______________________________________________
tycho-user mailing list
https://dev.eclipse.org/mailman/listinfo/tycho-user
Christian Gruber
2012-06-05 01:46:23 UTC
Permalink
Sorry - it's multibindings. I was on another screen than my mail, so I
typed that out (sigh). In real life, I cut the package and bundle
respectively from the published MANIFEST.MF of guice-multibindings and
pasted them into the MANIFEST.MF of my project.

Christian.
Post by Igor Fedorenko
I think you have a typo in the bundle manifest. It should be
Import-Package 'com.google.inject.**multibindings', not
'com.google.inject.**multibinders' you have it in your paste.
I attached a working example just in case.
Also, beware that both eclipse juno and orbit p2 repositories contain
orbit versions of com.google.inject and com.google.inject.**multibindings.
Orbit uses four-part versions, which are considered "newer" compared to
what's in Central, so Tycho uses Orbit versions. Not sure if this
important or not.
--
Regards,
Igor
Post by Christian Edward Gruber
If I use Import-package: com.google.inject.multibinders then I get the
Missing requirement: com.google.my.eclipse.thingy 1.0.0.qualifier
requires 'package com.google.inject.multibinders 0.0.0' but it could not be
found
and in eclipse it's unsatisfied and I get no jar on my class path, and
"Unable to satisfy dependency from com.google.my.eclipse.thingy
1.0.0.qualifier to bundle com.google.inject.multibinders 0.0.0."
If I make it a Require-bundle, it fails (presumably because it's not a
Bundle 'com.google.inject.**multibinders' cannot be resolved
in eclipse with tycho/m2e, and on the command line, it's
Missing requirement: com.google.my.eclipse.thingy 1.0.0.qualifier
requires 'bundle com.google.inject.multibinders 0.0.0' but it could not be
found
"Unable to satisfy dependency from com.google.my.eclipse.thingy
1.0.0.qualifier to bundle com.google.inject.multibinders 0.0.0."
Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-Name: [censored for your pleasure]
Bundle-SymbolicName: com.google.my.eclipse.thingy;**singleton:=true
Bundle-Version: 1.0.0.qualifier
Bundle-Activator: com.google.some.plugin.class.**SomePlugin
com.google.my.eclipse.abundle; bundle-version="[1.0.0,2.0.0)"**,
com.google.my.eclipse.bbundle; bundle-version="[1.0.0,2.0.0)"**,
com.google.my.eclipse.cbundle; bundle-version="[1.0.0,2.0.0)"**,
com.google.my.eclipse.dbundle; bundle-version="[1.0.0,2.0.0)"**,
com.google.inject,
org.eclipse.ui,
org.eclipse.core.runtime,
org.eclipse.core.resources,
org.eclipse.jdt.core,
org.eclipse.ui.editors,
org.eclipse.ui.ide,
org.eclipse.jdt.ui,
org.eclipse.wst.jsdt.core,
org.eclipse.jface.text,
org.eclipse.wst.jsdt.ui,
org.eclipse.ui.workbench.**texteditor,
org.eclipse.ltk.ui.**refactoring,
org.eclipse.ltk.core.**refactoring,
org.eclipse.search
com.google.common.base,
com.google.common.collect,
com.google.inject.**multibinders,
com.google.protobuf
Bundle-ActivationPolicy: lazy
Bundle-**RequiredExecutionEnvironment: JavaSE-1.6
Bundle-ClassPath: .
Bundle-Vendor: Google Inc.
com.google.my.eclipse.thingy
cheers,
Christian
What is exact error message do you get from command line build? Can you
Post by Igor Fedorenko
paste bundle manifest (snippet) that you believe should bring required
dependency?
--
Regards,
Igor
Post by Christian Edward Gruber
[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.
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.
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<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/<http://download.eclipse.org/releases/juno/>
</url>
</repository>
</repositories>
</project>
a better place to discuss this, since it probably involves Tycho-specific
settings/configuration.
done.
Christian.
______________________________**_________________
tycho-user mailing list
https://dev.eclipse.org/**mailman/listinfo/tycho-user<https://dev.eclipse.org/mailman/listinfo/tycho-user>
______________________________**_________________
tycho-user mailing list
https://dev.eclipse.org/**mailman/listinfo/tycho-user<https://dev.eclipse.org/mailman/listinfo/tycho-user>
______________________________**_________________
tycho-user mailing list
https://dev.eclipse.org/**mailman/listinfo/tycho-user<https://dev.eclipse.org/mailman/listinfo/tycho-user>
_______________________________________________
tycho-user mailing list
https://dev.eclipse.org/mailman/listinfo/tycho-user
Christian Gruber
2012-06-05 01:48:06 UTC
Permalink
Post by Igor Fedorenko
I attached a working example just in case.
Awesome, I'll try to rationalize this example with my situation.
Post by Igor Fedorenko
Also, beware that both eclipse juno and orbit p2 repositories contain
orbit versions of com.google.inject and com.google.inject.**multibindings.
Orbit uses four-part versions, which are considered "newer" compared to
what's in Central, so Tycho uses Orbit versions. Not sure if this
important or not.
I'll pay attention to that. At some point, I don't care as long as SOMEONE
is publishing Guice. Our use of Guice isn't so crazy advanced that we even
need the latest and greatest - I just need it to actually be in my build
and runtime.

Christian
Christian Edward Gruber
2012-06-06 15:16:33 UTC
Permalink
Hey Igor,
Post by Igor Fedorenko
I attached a working example just in case.
Ok. Using your test project, I tried several scenarios. Short version is… it works on the command-line, and fails in M2E.

In order for it to work in Tycho, I needed to either use Orbit's version or a local version of 3.0.1 guice that I built that includes mcculls's fix to include "Eclipse-ExtensibleAPI: true" fix. In this case, Tycho seems to be able to find things.

However, in Eclipse, somewhere between Tycho, Tycho-m2e, m2e, and the PDE, there's no love. The com.google.inject.multbindings is not added to the plugin dependencies in the PDE, unless I can get that dependency satisfied from another source, a P2 repository. But if I want it to come from a maven repository, even with <considerPom>true</considerPom> active int he config (which it is in your sample project), no go.

PROBABLY IMPORTANT OBSERVATION: Actually, any maven project (even with OSGI metadata) that isn't open in my eclipse workspace as well is not resolved.

To be even clearer - If I have guice and guice-multibinders projects open and updated in eclipse with m2e, everything resolves, and those projects are in my plugin-dependencies. If the projects are closed, the "cannot resolve" problem in eclipse resumes. This is after having done a "mvn install" on guice to make sure it can resolve from my local cache, which totally works from the CLI.

(Small side note… aopalliance-1.0.jar has no OSGI metadata, so I had to create side artifact with felix to bundle its content with some OSGI metadata and include that too if I wanted to use guice-3.0.1 to satisfy multibinders-test's dependency, unless I used Orbit's p2 repo which also repackages that one.)

Is tycho-user@ the right list to keep talking about the m2e-tycho bridge issues? I'm happy to keep trying to debug this with whoever needs to do it.

Environment Details:
Eclipse 3.8-RC2 and 4.2-RC2 (same issues), on ubuntu and Mac OS X lion
M2E 1.1.0.1020530-0009
-> Tycho Project Configurators - 0.6.0.201112050222
-> PDE 3.8.0.v20120104-1740-blahblahblah
-> Other m2e connectors at 0.15.0.201109282249 (build-helper, mavenarchiver)



cheers,
Christian.
Christian Edward Gruber
2012-06-06 15:54:28 UTC
Permalink
Further painful clarification - the problem I'm describing seems quite specific to fragment resolution, not bundle resolution. Any bundles I had pulled in through maven/tycho/m2e/eclipse seem to resolve just fine.

Christian.
Post by Christian Edward Gruber
Hey Igor,
Post by Igor Fedorenko
I attached a working example just in case.
Ok. Using your test project, I tried several scenarios. Short version is… it works on the command-line, and fails in M2E.
In order for it to work in Tycho, I needed to either use Orbit's version or a local version of 3.0.1 guice that I built that includes mcculls's fix to include "Eclipse-ExtensibleAPI: true" fix. In this case, Tycho seems to be able to find things.
However, in Eclipse, somewhere between Tycho, Tycho-m2e, m2e, and the PDE, there's no love. The com.google.inject.multbindings is not added to the plugin dependencies in the PDE, unless I can get that dependency satisfied from another source, a P2 repository. But if I want it to come from a maven repository, even with <considerPom>true</considerPom> active int he config (which it is in your sample project), no go.
PROBABLY IMPORTANT OBSERVATION: Actually, any maven project (even with OSGI metadata) that isn't open in my eclipse workspace as well is not resolved.
To be even clearer - If I have guice and guice-multibinders projects open and updated in eclipse with m2e, everything resolves, and those projects are in my plugin-dependencies. If the projects are closed, the "cannot resolve" problem in eclipse resumes. This is after having done a "mvn install" on guice to make sure it can resolve from my local cache, which totally works from the CLI.
(Small side note… aopalliance-1.0.jar has no OSGI metadata, so I had to create side artifact with felix to bundle its content with some OSGI metadata and include that too if I wanted to use guice-3.0.1 to satisfy multibinders-test's dependency, unless I used Orbit's p2 repo which also repackages that one.)
Eclipse 3.8-RC2 and 4.2-RC2 (same issues), on ubuntu and Mac OS X lion
M2E 1.1.0.1020530-0009
-> Tycho Project Configurators - 0.6.0.201112050222
-> PDE 3.8.0.v20120104-1740-blahblahblah
-> Other m2e connectors at 0.15.0.201109282249 (build-helper, mavenarchiver)
cheers,
Christian.
Igor Fedorenko
2012-06-06 16:36:21 UTC
Permalink
There is no integration between m2e and pde workspace target platform.
This is due to PDE limitations, nothing we can do to improve the
situation, short of rewriting pde, which is not something high in my
priority list at the moment. As a workaround, you have to setup PDE
target platform manually. Either collect required bundles in local
eclipse-installation-like directory structure or use .target file, if
you don't mind guice bits from orbit.

I did not expect Tycho to honour Eclipse-ExtensibleAPI, so I am
surprised you needed it to make command line build work.

--
Regards,
Igor
Post by Christian Edward Gruber
Hey Igor,
Post by Igor Fedorenko
I attached a working example just in case.
Ok. Using your test project, I tried several scenarios. Short version is… it works on the command-line, and fails in M2E.
In order for it to work in Tycho, I needed to either use Orbit's version or a local version of 3.0.1 guice that I built that includes mcculls's fix to include "Eclipse-ExtensibleAPI: true" fix. In this case, Tycho seems to be able to find things.
However, in Eclipse, somewhere between Tycho, Tycho-m2e, m2e, and the PDE, there's no love. The com.google.inject.multbindings is not added to the plugin dependencies in the PDE, unless I can get that dependency satisfied from another source, a P2 repository. But if I want it to come from a maven repository, even with<considerPom>true</considerPom> active int he config (which it is in your sample project), no go.
PROBABLY IMPORTANT OBSERVATION: Actually, any maven project (even with OSGI metadata) that isn't open in my eclipse workspace as well is not resolved.
To be even clearer - If I have guice and guice-multibinders projects open and updated in eclipse with m2e, everything resolves, and those projects are in my plugin-dependencies. If the projects are closed, the "cannot resolve" problem in eclipse resumes. This is after having done a "mvn install" on guice to make sure it can resolve from my local cache, which totally works from the CLI.
(Small side note… aopalliance-1.0.jar has no OSGI metadata, so I had to create side artifact with felix to bundle its content with some OSGI metadata and include that too if I wanted to use guice-3.0.1 to satisfy multibinders-test's dependency, unless I used Orbit's p2 repo which also repackages that one.)
Eclipse 3.8-RC2 and 4.2-RC2 (same issues), on ubuntu and Mac OS X lion
M2E 1.1.0.1020530-0009
-> Tycho Project Configurators - 0.6.0.201112050222
-> PDE 3.8.0.v20120104-1740-blahblahblah
-> Other m2e connectors at 0.15.0.201109282249 (build-helper, mavenarchiver)
cheers,
Christian.
_______________________________________________
tycho-user mailing list
https://dev.eclipse.org/mailman/listinfo/tycho-user
Christian Edward Gruber
2012-06-06 20:33:11 UTC
Permalink
Post by Igor Fedorenko
There is no integration between m2e and pde workspace target platform.
This is due to PDE limitations, nothing we can do to improve the
situation, short of rewriting pde, which is not something high in my
priority list at the moment. As a workaround, you have to setup PDE
target platform manually. Either collect required bundles in local
eclipse-installation-like directory structure or use .target file, if
you don't mind guice bits from orbit.
Ok, Igor… thanks for bearing with me. IANA OSGI Expert, so how I believe things should be functioning has been blown apart in this process, as I try to piece together maven docs, tycho docs, OSGI specs, and mailing-list/Stack-Overflow output. Your patience is appreciated.

I think I'm starting to see how things work here, and please correct any misunderstandings herein. I was having things in my environment pollute the situation in a way that made it hard to reason about. Let me see if I really understand what you're saying (and what I've been reading).

Tycho pulls from p2 repositories and can consider m2 repositories if the items have OSGI metadata. That's all fine and good, and it'll pull in the bundles to do compilation and other tasks through maven or the p2 resolver. So far so good. yes?

As I understand it, now, Eclipse's PDE has to know about everything through p2 resolution. If i happen to have things kicking around locally, it might resolve those first (open projects, or things pushed into my workspace that satisfy the bundle and fragment dependencies), but the PDE is entirely uninterested in what tycho has produced. This happens to include open PDE projects, which maven-bundle-plugin projects happen also to be, so PDE can satisfy the dependency properly from within the eclipse environment… the maven element is entirely unrelated.

So, if I want to work on things between the command-line and eclipse I have to maintain my dependencies in the pom.xml file, and ALSO have eclipse see the bundles through some other means, which may be a local p2 repository, or something like Orbit. Or keep open PDE projects for all dependencies that aren't in a p2 repo. Correct?

So, three things then:

1. Your project did not work in eclipse. It worked from the command-line, but even with Orbit, in a clean workspace, it didn't pull in the fragment for multibindigs, so I still get no resolution in the PDE.

2. Would it help if we maintained a p2 complaint repository of guice artifacts?

3. Is Sonatype planning on manifesting OSGI-compliant bundles that are held within the central m2 repo? I had read something about Nexus and OSGI p2 repos.
Post by Igor Fedorenko
I did not expect Tycho to honour Eclipse-ExtensibleAPI, so I am
surprised you needed it to make command line build work.
I have gone back and forth so many times and now I'm confused again on this point. I think I had too many variables in my testing and so it seemed this was so. At this point, it seems to not matter - it was co-incident with Eclipse 3.8 caching a copy of guice from orbit into an eclipse38/test/plugins directory and satisfying the p2 dependency from there.

Is there a way that Tycho could have a goal that pulled together a p2 repository locally out of all your m2-satisfied dependencies?

Also, argh.

cheers,
Christian.
Igor Fedorenko
2012-06-07 12:01:03 UTC
Permalink
Post by Christian Edward Gruber
Post by Igor Fedorenko
There is no integration between m2e and pde workspace target
platform. This is due to PDE limitations, nothing we can do to
improve the situation, short of rewriting pde, which is not
something high in my priority list at the moment. As a workaround,
you have to setup PDE target platform manually. Either collect
required bundles in local eclipse-installation-like directory
structure or use .target file, if you don't mind guice bits from
orbit.
Ok, Igor… thanks for bearing with me. IANA OSGI Expert, so how I
believe things should be functioning has been blown apart in this
process, as I try to piece together maven docs, tycho docs, OSGI
specs, and mailing-list/Stack-Overflow output. Your patience is
appreciated.
I think I'm starting to see how things work here, and please correct
any misunderstandings herein. I was having things in my environment
pollute the situation in a way that made it hard to reason about.
Let me see if I really understand what you're saying (and what I've
been reading).
Tycho pulls from p2 repositories and can consider m2 repositories if
the items have OSGI metadata. That's all fine and good, and it'll
pull in the bundles to do compilation and other tasks through maven
or the p2 resolver. So far so good. yes?
This is correct.
Post by Christian Edward Gruber
As I understand it, now, Eclipse's PDE has to know about everything
through p2 resolution. If i happen to have things kicking around
locally, it might resolve those first (open projects, or things
pushed into my workspace that satisfy the bundle and fragment
dependencies), but the PDE is entirely uninterested in what tycho has
produced. This happens to include open PDE projects, which
maven-bundle-plugin projects happen also to be, so PDE can satisfy
the dependency properly from within the eclipse environment… the
maven element is entirely unrelated.
So, if I want to work on things between the command-line and eclipse
I have to maintain my dependencies in the pom.xml file, and ALSO have
eclipse see the bundles through some other means, which may be a
local p2 repository, or something like Orbit. Or keep open PDE
projects for all dependencies that aren't in a p2 repo. Correct?
PDE resolves dependencies from open workspace "plugin" projects and
workspace target platform. Workspace target platform can be configured
through .target file or as local eclipse installation.

If all your dependencies are available from p2 repositories, then it is
possible to configured .target file that will work both for PDE and Tycho.

There is no nice/clean solution that will allow PDE resolve dependencies
from maven2 repositories, but there few possible workarounds

- create p2 repository with dependencies available from maven2
repositories and reference it form .target file used both by tycho and pde.
- create local eclipse installation with all dependencies and use it as
pde workspace target platform
- import maven2 dependencies as workspace projects. this works for
maven-bundle-plugin projects and requires m2e-tycho to "bridge" m-b-p
and pde.
Post by Christian Edward Gruber
1. Your project did not work in eclipse. It worked from the
command-line, but even with Orbit, in a clean workspace, it didn't
pull in the fragment for multibindigs, so I still get no resolution
in the PDE.
PDE workspace target platform needs to include all project dependencies.
Eclipse Help website appears to be down atm, so I can't give you links
to relevant documentation, but search for "eclipse pde target platform"
when it comes back.
Post by Christian Edward Gruber
2. Would it help if we maintained a p2 complaint repository of guice artifacts?
You will also need to setup .target file to use the repository, but yes,
this will work.
Post by Christian Edward Gruber
3. Is Sonatype planning on manifesting OSGI-compliant bundles that
are held within the central m2 repo? I had read something about
Nexus and OSGI p2 repos.
I am not sure I understand the question. If you are asking about
exposing all OSGi bundles deployed to Central as p2 repository, I do not
believe there are immediate plans to do this.
Post by Christian Edward Gruber
Post by Igor Fedorenko
I did not expect Tycho to honour Eclipse-ExtensibleAPI, so I am
surprised you needed it to make command line build work.
I have gone back and forth so many times and now I'm confused again
on this point. I think I had too many variables in my testing and so
it seemed this was so. At this point, it seems to not matter - it
was co-incident with Eclipse 3.8 caching a copy of guice from orbit
into an eclipse38/test/plugins directory and satisfying the p2
dependency from there.
Is there a way that Tycho could have a goal that pulled together a p2
repository locally out of all your m2-satisfied dependencies?
I don't believe this is currently possible and I don't think this is a
good idea either. Lack of PDE support is the problem here, so I believe
PDE is the right place to solve it.

--
Regards,
Igor

Loading...