Re: [equinox-dev] Resolver Problem with guava and e4 (javax.annotation)
David M Williams wrote: I notice in Orbit, all our javax.annotation bundles follow the import what you export pattern that's good, such as *Export-Package*: javax.annotation;/version/=1.2.0, javax.annotation.security;/version/=1.2.0, javax.annotation.sql;/version/=1.2.0 *Import-Package*: javax.annotation;/version/=1.2.0, javax.annotation.security;/version/=1.2.0, javax.annotation.sql;/version/=1.2.0 Is this import what you export best practice for *all* javax.* bundles in Orbit? As far as I can see, some of them don't follow this policy (javax.xml.bind, for example, whose packages are also provided by the system bundle provides at least from Java 7 onwards) and I am wondering whether it's worth opening bugs for this. Best wishes, Andreas -- Codetrails GmbH The knowledge transfer company Robert-Bosch-Str. 7, 64293 Darmstadt Phone: +49-6151-276-7092 Mobile: +49-170-811-3791 http://www.codetrails.com/ Managing Director: Dr. Marcel Bruch Handelsregister: Darmstadt HRB 91940 ___ equinox-dev mailing list equinox-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] Resolver Problem with guava and e4 (javax.annotation)
Importing what you export is only useful when the bundle contains other packages which actually use the exported package. For example, a bundle implements the OSGi Event Admin service. That bundle can export the org.osgi.service.event package and also import it. The bundle is happy to use any (version matching) org.osgi.service.event package. But if the bundle is just a container of packages which it exports for other and does not itself use the packages in anyway, then there is less value in also importing the packages. Say a bundle just contains the org.osgi.service.event package and exports it as well as imports it. If this bundle is resolved to import the package, the bundle is essentially empty. It is not exporting the package and has no other packages. I don't know the make up of the bundles in question here. But is may or may not make sense to import the packages being exported. What the bundle contains will influence the choice. That being said, there is little harm in also importing the packages, so it is a safe (but perhaps of little value) choice. -- BJ Hargrave Senior Technical Staff Member, IBM OSGi Fellow and CTO of the OSGi Alliance hargr...@us.ibm.com office: +1 386 848 1781 mobile: +1 386 848 3788 From: Andreas Sewe andreas.s...@codetrails.com To: equinox-dev@eclipse.org, orbit-...@eclipse.org Date: 2014/07/11 04:38 Subject:Re: [equinox-dev] Resolver Problem with guava and e4 (javax.annotation) Sent by:equinox-dev-boun...@eclipse.org David M Williams wrote: I notice in Orbit, all our javax.annotation bundles follow the import what you export pattern that's good, such as *Export-Package*: javax.annotation;/version/=1.2.0, javax.annotation.security;/version/=1.2.0, javax.annotation.sql;/version/=1.2.0 *Import-Package*: javax.annotation;/version/=1.2.0, javax.annotation.security;/version/=1.2.0, javax.annotation.sql;/version/=1.2.0 Is this import what you export best practice for *all* javax.* bundles in Orbit? As far as I can see, some of them don't follow this policy (javax.xml.bind, for example, whose packages are also provided by the system bundle provides at least from Java 7 onwards) and I am wondering whether it's worth opening bugs for this. Best wishes, Andreas -- Codetrails GmbH The knowledge transfer company Robert-Bosch-Str. 7, 64293 Darmstadt Phone: +49-6151-276-7092 Mobile: +49-170-811-3791 http://www.codetrails.com/ Managing Director: Dr. Marcel Bruch Handelsregister: Darmstadt HRB 91940 ___ equinox-dev mailing list equinox-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/equinox-dev ___ equinox-dev mailing list equinox-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] Resolver Problem with guava and e4 (javax.annotation)
One clarification on import/export. If your bundle X is a container bundle as BJ describes and it imports/exports the packages AND its imports resolve to another bundle then the bundle is effectively empty as BJ describes. But there is one important thing to note about such an empty bundle: Other bundles that happen to require bundle X will now wire to the substituted packages that bundle X wires to which replaced/substituted the packages declared to be exported by bundle X. The other thing to note about this scenario that involves system packages. The framework *still* does not know what version to export the packages included in the VM. For example, the javax.annotation packages below. I imagine (but don't know for certain) that the javax.annotation packages include in java 8 would be at version 1.2 or higher, but the framework does not know that so it just exports them at version 0.0.0. So even though you import/export at version 1.2.0 the package still will not be substituted with the VM package on Java 8. So we will end up with two exporters of the annotations package. Tom From: BJ Hargrave/Austin/IBM@IBMUS To: Equinox development mailing list equinox-dev@eclipse.org Date: 07/11/2014 09:28 AM Subject:Re: [equinox-dev] Resolver Problem with guava and e4 (javax.annotation) Sent by:equinox-dev-boun...@eclipse.org Importing what you export is only useful when the bundle contains other packages which actually use the exported package. For example, a bundle implements the OSGi Event Admin service. That bundle can export the org.osgi.service.event package and also import it. The bundle is happy to use any (version matching) org.osgi.service.event package. But if the bundle is just a container of packages which it exports for other and does not itself use the packages in anyway, then there is less value in also importing the packages. Say a bundle just contains the org.osgi.service.event package and exports it as well as imports it. If this bundle is resolved to import the package, the bundle is essentially empty. It is not exporting the package and has no other packages. I don't know the make up of the bundles in question here. But is may or may not make sense to import the packages being exported. What the bundle contains will influence the choice. That being said, there is little harm in also importing the packages, so it is a safe (but perhaps of little value) choice. -- BJ Hargrave Senior Technical Staff Member, IBM office: +1 386 848 1781 OSGi Fellow and CTO of the OSGi Alliance mobile: +1 386 848 3788 hargr...@us.ibm.com From:Andreas Sewe andreas.s...@codetrails.com To:equinox-dev@eclipse.org, orbit-...@eclipse.org Date:2014/07/11 04:38 Subject:Re: [equinox-dev] Resolver Problem with guava and e4 (javax.annotation) Sent by:equinox-dev-boun...@eclipse.org David M Williams wrote: I notice in Orbit, all our javax.annotation bundles follow the import what you export pattern that's good, such as *Export-Package*: javax.annotation;/version/=1.2.0, javax.annotation.security;/version/=1.2.0, javax.annotation.sql;/version/=1.2.0 *Import-Package*: javax.annotation;/version/=1.2.0, javax.annotation.security;/version/=1.2.0, javax.annotation.sql;/version/=1.2.0 Is this import what you export best practice for *all* javax.* bundles in Orbit? As far as I can see, some of them don't follow this policy (javax.xml.bind, for example, whose packages are also provided by the system bundle provides at least from Java 7 onwards) and I am wondering whether it's worth opening bugs for this. Best wishes, Andreas -- Codetrails GmbH The knowledge transfer company Robert-Bosch-Str. 7, 64293 Darmstadt Phone: +49-6151-276-7092 Mobile: +49-170-811-3791 http://www.codetrails.com/ Managing Director: Dr. Marcel Bruch Handelsregister: Darmstadt HRB 91940 ___ equinox-dev mailing list equinox-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/equinox-dev ___ equinox-dev mailing list equinox-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/equinox-dev ___ equinox-dev mailing list equinox-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] Resolver Problem with guava and e4 (javax.annotation)
That being said, is it not possible to provide a system fragment bundle which attempts to correct that?: Fragment-Host: system.bundle Bundle-RequiredExecutionEnvironment: ?java8[profile]? Export-Package: javax.annotation;version=1.2,javax.blah;version=x.y.z,.. If we could to that, then a fragment bundle specific per java version could come along and correct all the packages exported by the system bundle without having to modify the impl. On Fri, Jul 11, 2014 at 7:49 AM, Thomas Watson tjwat...@us.ibm.com wrote: One clarification on import/export. If your bundle X is a container bundle as BJ describes and it imports/exports the packages AND its imports resolve to another bundle then the bundle is effectively empty as BJ describes. But there is one important thing to note about such an empty bundle: Other bundles that happen to require bundle X will now wire to the substituted packages that bundle X wires to which replaced/substituted the packages declared to be exported by bundle X. The other thing to note about this scenario that involves system packages. The framework *still* does not know what version to export the packages included in the VM. For example, the javax.annotation packages below. I imagine (but don't know for certain) that the javax.annotation packages include in java 8 would be at version 1.2 or higher, but the framework does not know that so it just exports them at version 0.0.0. So even though you import/export at version 1.2.0 the package still will not be substituted with the VM package on Java 8. So we will end up with two exporters of the annotations package. Tom [image: Inactive hide details for BJ Hargrave---07/11/2014 09:28:17 AM---Importing what you export is only useful when the bundle conta]BJ Hargrave---07/11/2014 09:28:17 AM---Importing what you export is only useful when the bundle contains other packages which actually use From: BJ Hargrave/Austin/IBM@IBMUS To: Equinox development mailing list equinox-dev@eclipse.org Date: 07/11/2014 09:28 AM Subject: Re: [equinox-dev] Resolver Problem with guava and e4 (javax.annotation) Sent by: equinox-dev-boun...@eclipse.org -- Importing what you export is only useful when the bundle contains other packages which actually use the exported package. For example, a bundle implements the OSGi Event Admin service. That bundle can export the org.osgi.service.event package and also import it. The bundle is happy to use any (version matching) org.osgi.service.event package. But if the bundle is just a container of packages which it exports for other and does not itself use the packages in anyway, then there is less value in also importing the packages. Say a bundle just contains the org.osgi.service.event package and exports it as well as imports it. If this bundle is resolved to import the package, the bundle is essentially empty. It is not exporting the package and has no other packages. I don't know the make up of the bundles in question here. But is may or may not make sense to import the packages being exported. What the bundle contains will influence the choice. That being said, there is little harm in also importing the packages, so it is a safe (but perhaps of little value) choice. -- *BJ Hargrave* Senior Technical Staff Member, IBM OSGi Fellow and CTO of the *OSGi Alliance* http://www.osgi.org/ *hargr...@us.ibm.com* hargr...@us.ibm.com office: +1 386 848 1781 mobile: +1 386 848 3788 From:Andreas Sewe andreas.s...@codetrails.com To:equinox-dev@eclipse.org, orbit-...@eclipse.org Date:2014/07/11 04:38 Subject:Re: [equinox-dev] Resolver Problem with guava and e4 (javax.annotation) Sent by:equinox-dev-boun...@eclipse.org -- David M Williams wrote: I notice in Orbit, all our javax.annotation bundles follow the import what you export pattern that's good, such as *Export-Package*: javax.annotation;/version/=1.2.0, javax.annotation.security;/version/=1.2.0, javax.annotation.sql;/version/=1.2.0 *Import-Package*: javax.annotation;/version/=1.2.0, javax.annotation.security;/version/=1.2.0, javax.annotation.sql;/version/=1.2.0 Is this import what you export best practice for *all* javax.* bundles in Orbit? As far as I can see, some of them don't follow this policy (javax.xml.bind, for example, whose packages are also provided by the system bundle provides at least from Java 7 onwards) and I am wondering whether it's worth opening bugs for this. Best wishes, Andreas -- Codetrails GmbH The knowledge transfer company Robert-Bosch-Str. 7, 64293 Darmstadt Phone: +49-6151-276-7092 Mobile: +49-170-811-3791 *http://www.codetrails.com/* http://www.codetrails.com/ Managing Director: Dr. Marcel Bruch Handelsregister: Darmstadt HRB 91940 ___ equinox-dev mailing list
Re: [equinox-dev] Resolver Problem with guava and e4 (javax.annotation)
My main question is ... is this required for Luna? (I assume not, that it shows up in e4 incubator? so could wait to SR1 if we find a safe, non-breaking change? Or Mars if breaking?) Second, I've only barely read the details (they make my head spin) but wondering if it is reasonable for resolver.problem to require Java 8 AND javax.annotaion 1.0.0? That seems quite a mix of old and new? I assume this is an attempt to be compatible with older bundles that require javax.annotation 1.0? If it helps, and if you haven't already, you might want to read https://bugs.eclipse.org/bugs/show_bug.cgi?id=424909#c0 and what it points to, https://bugs.eclipse.org/bugs/show_bug.cgi?id=422981#c5 Now for some wild ideas to show my ignorance ... which helps occasionally :) ... I notice in Orbit, all our javax.annotation bundles follow the import what you export pattern that's good, such as Export-Package: javax.annotation;version=1.2.0, javax.annotation.security;version=1.2.0, javax.annotation.sql;version=1.2.0 Import-Package: javax.annotation;version=1.2.0, javax.annotation.security;version=1.2.0, javax.annotation.sql;version=1.2.0 BUT, in this case, I wonder if we should be so restrictive about what we import? Would the following be better? Export-Package: javax.annotation;version=1.2.0, javax.annotation.security;version=1.2.0, javax.annotation.sql;version=1.2.0 Import-Package: javax.annotation, javax.annotation.security, javax.annotation.sql I suppose that's about the same as requiring system.bundle? Just mix in with what ever in in running JRE? (Which, from https://bugs.eclipse.org/bugs/show_bug.cgi?id=422981#c5 sounds like it would work, in this case ... that is, high degree of similarity, except for new things? I'm just throwing this out as an idea ... only the experts could say if it makes sense. As for your suggestion b) guava does import javax.annotation;1.0.0 instead I'm assuming our Orbit guava version is what they (the third party) provides (which is what we always strive for) so you might work with them, to find out if there's a reason they did it the way they did, if they'd be willing to change, etc. But I'm mostly asking ... this isn't blocking Luna, right? Thanks, From: Tom Schindl tom.schi...@bestsolution.at To: equinox-dev@eclipse.org, E4 Project developer mailing list e4-...@eclipse.org, orbit-...@eclipse.org, Date: 06/10/2014 04:32 PM Subject:[equinox-dev] Resolver Problem with guava and e4 (javax.annotation) Sent by:equinox-dev-boun...@eclipse.org Hi, [cross posting because different projects are involved in the problem] I've just discover a problem when one tries to use e4-DI and com.google.guava 15.0.0. The MANIFEST.MF is really simply: Manifest-Version: 1.0 Bundle-ManifestVersion: 2 Bundle-Name: Problem Bundle-SymbolicName: resolver.problem Bundle-Version: 1.0.0.qualifier Bundle-RequiredExecutionEnvironment: JavaSE-1.8 Import-Package: javax.annotation;version=1.0.0 Require-Bundle: com.google.guava;bundle-version=15.0.0 and when trying to resolve it one gets: resolver.problem [196] Bundle was not resolved because of a uses contraint violation. org.osgi.service.resolver.ResolutionException: Uses constraint violation. Unable to resolve resource resolver.problem [osgi.identity; osgi.identity=resolver.problem; type=osgi.bundle; version:Version=1.0.0.qualifier] because it is exposed to package 'javax.annotation' from resources javax.annotation [osgi.identity; osgi.identity=javax.annotation; type=osgi.bundle; version:Version=1.2.0.v201401042248] and org.eclipse.osgi [osgi.identity; osgi.identity=org.eclipse.osgi; type=osgi.bundle; version:Version=3.10.0.v20140528-2014; singleton:=true] via two dependency chains. Chain 1: resolver.problem [osgi.identity; osgi.identity=resolver.problem; type=osgi.bundle; version:Version=1.0.0.qualifier] import: ((osgi.wiring.package=javax.annotation)(version=1.0.0)) | export: osgi.wiring.package: javax.annotation javax.annotation [osgi.identity; osgi.identity=javax.annotation; type=osgi.bundle; version:Version=1.2.0.v201401042248] Chain 2: resolver.problem [osgi.identity; osgi.identity=resolver.problem; type=osgi.bundle; version:Version=1.0.0.qualifier] require: ((osgi.wiring.bundle=com.google.guava)(bundle-version=15.0.0)) | provide: osgi.wiring.bundle; bundle-version:Version=15.0.0.v201403281430; osgi.wiring.bundle=com.google.guava com.google.guava [osgi.identity; osgi.identity=com.google.guava; type=osgi.bundle; version:Version=15.0.0.v201403281430] import: (osgi.wiring.package=javax.annotation) | export: osgi.wiring.package: javax.annotation org.eclipse.osgi [osgi.identity; osgi.identity=org.eclipse.osgi; type=osgi.bundle; version:Version=3.10.0.v20140528-2014; singleton:=true] The reason is that guava optionally imports: Import-Package: javax.annotation;resolution
[equinox-dev] Resolver Problem with guava and e4 (javax.annotation)
Hi, [cross posting because different projects are involved in the problem] I've just discover a problem when one tries to use e4-DI and com.google.guava 15.0.0. The MANIFEST.MF is really simply: Manifest-Version: 1.0 Bundle-ManifestVersion: 2 Bundle-Name: Problem Bundle-SymbolicName: resolver.problem Bundle-Version: 1.0.0.qualifier Bundle-RequiredExecutionEnvironment: JavaSE-1.8 Import-Package: javax.annotation;version=1.0.0 Require-Bundle: com.google.guava;bundle-version=15.0.0 and when trying to resolve it one gets: resolver.problem [196] Bundle was not resolved because of a uses contraint violation. org.osgi.service.resolver.ResolutionException: Uses constraint violation. Unable to resolve resource resolver.problem [osgi.identity; osgi.identity=resolver.problem; type=osgi.bundle; version:Version=1.0.0.qualifier] because it is exposed to package 'javax.annotation' from resources javax.annotation [osgi.identity; osgi.identity=javax.annotation; type=osgi.bundle; version:Version=1.2.0.v201401042248] and org.eclipse.osgi [osgi.identity; osgi.identity=org.eclipse.osgi; type=osgi.bundle; version:Version=3.10.0.v20140528-2014; singleton:=true] via two dependency chains. Chain 1: resolver.problem [osgi.identity; osgi.identity=resolver.problem; type=osgi.bundle; version:Version=1.0.0.qualifier] import: ((osgi.wiring.package=javax.annotation)(version=1.0.0)) | export: osgi.wiring.package: javax.annotation javax.annotation [osgi.identity; osgi.identity=javax.annotation; type=osgi.bundle; version:Version=1.2.0.v201401042248] Chain 2: resolver.problem [osgi.identity; osgi.identity=resolver.problem; type=osgi.bundle; version:Version=1.0.0.qualifier] require: ((osgi.wiring.bundle=com.google.guava)(bundle-version=15.0.0)) | provide: osgi.wiring.bundle; bundle-version:Version=15.0.0.v201403281430; osgi.wiring.bundle=com.google.guava com.google.guava [osgi.identity; osgi.identity=com.google.guava; type=osgi.bundle; version:Version=15.0.0.v201403281430] import: (osgi.wiring.package=javax.annotation) | export: osgi.wiring.package: javax.annotation org.eclipse.osgi [osgi.identity; osgi.identity=org.eclipse.osgi; type=osgi.bundle; version:Version=3.10.0.v20140528-2014; singleton:=true] The reason is that guava optionally imports: Import-Package: javax.annotation;resolution:=optional,javax.inject;res olution:=optional,sun.misc;resolution:=optional So guava wires to the package from the JDK and presents classes in its API so I guess that's why the bundles who uses guava results in the resolution conflict. There are 2 possible solutions: a) because we now require JavaSE-6 in all our e4 code we could remove the need for explicit javax.annotation imports - this would break existing code but is maybe the correct solution in the long run? b) guava does import javax.annotation;1.0.0 instead Tom ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] Resolver Problem with guava and e4 (javax.annotation)
a) Removing the javax.annotation import would surely not work, since then you won’t have any visibility of that package at all. I assume resolver.problem does actually use this package? b) Modifying Guava would require repackaging it and maintaining that indefinitely. I propose a third solution: import package javax.annotation from your bundle but don’t require version 1. The package is after all part of JavaSE since at least Java 1.6, and the JRE exports everything as version zero. Regards, Neil On 10 June 2014 at 21:32:06, Tom Schindl (tom.schi...@bestsolution.at) wrote: Hi, [cross posting because different projects are involved in the problem] I've just discover a problem when one tries to use e4-DI and com.google.guava 15.0.0. The MANIFEST.MF is really simply: Manifest-Version: 1.0 Bundle-ManifestVersion: 2 Bundle-Name: Problem Bundle-SymbolicName: resolver.problem Bundle-Version: 1.0.0.qualifier Bundle-RequiredExecutionEnvironment: JavaSE-1.8 Import-Package: javax.annotation;version=1.0.0 Require-Bundle: com.google.guava;bundle-version=15.0.0 and when trying to resolve it one gets: resolver.problem [196] Bundle was not resolved because of a uses contraint violation. org.osgi.service.resolver.ResolutionException: Uses constraint violation. Unable to resolve resource resolver.problem [osgi.identity; osgi.identity=resolver.problem; type=osgi.bundle; version:Version=1.0.0.qualifier] because it is exposed to package 'javax.annotation' from resources javax.annotation [osgi.identity; osgi.identity=javax.annotation; type=osgi.bundle; version:Version=1.2.0.v201401042248] and org.eclipse.osgi [osgi.identity; osgi.identity=org.eclipse.osgi; type=osgi.bundle; version:Version=3.10.0.v20140528-2014; singleton:=true] via two dependency chains. Chain 1: resolver.problem [osgi.identity; osgi.identity=resolver.problem; type=osgi.bundle; version:Version=1.0.0.qualifier] import: ((osgi.wiring.package=javax.annotation)(version=1.0.0)) | export: osgi.wiring.package: javax.annotation javax.annotation [osgi.identity; osgi.identity=javax.annotation; type=osgi.bundle; version:Version=1.2.0.v201401042248] Chain 2: resolver.problem [osgi.identity; osgi.identity=resolver.problem; type=osgi.bundle; version:Version=1.0.0.qualifier] require: ((osgi.wiring.bundle=com.google.guava)(bundle-version=15.0.0)) | provide: osgi.wiring.bundle; bundle-version:Version=15.0.0.v201403281430; osgi.wiring.bundle=com.google.guava com.google.guava [osgi.identity; osgi.identity=com.google.guava; type=osgi.bundle; version:Version=15.0.0.v201403281430] import: (osgi.wiring.package=javax.annotation) | export: osgi.wiring.package: javax.annotation org.eclipse.osgi [osgi.identity; osgi.identity=org.eclipse.osgi; type=osgi.bundle; version:Version=3.10.0.v20140528-2014; singleton:=true] The reason is that guava optionally imports: Import-Package: javax.annotation;resolution:=optional,javax.inject;res olution:=optional,sun.misc;resolution:=optional So guava wires to the package from the JDK and presents classes in its API so I guess that's why the bundles who uses guava results in the resolution conflict. There are 2 possible solutions: a) because we now require JavaSE-6 in all our e4 code we could remove the need for explicit javax.annotation imports - this would break existing code but is maybe the correct solution in the long run? b) guava does import javax.annotation;1.0.0 instead Tom ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] Resolver Problem with guava and e4 (javax.annotation)
On 11.06.14 00:44, Neil Bartlett wrote: a) Removing the javax.annotation import would surely not work, since then you won’t have any visibility of that package at all. I assume resolver.problem does actually use this package? My proposal was not to remove it but to make it version less but then this needs to be done by ALL bundles - most important those who process the javax.annotation (=e4.core.di) b) Modifying Guava would require repackaging it and maintaining that indefinitely. Well we already get that from orbit so it is repackaged I propose a third solution: import package javax.annotation from your bundle but don’t require version 1. The package is after all part of JavaSE since at least Java 1.6, and the JRE exports everything as version zero. I can not do that currently because the upstream project e.g. e4.core.di (see below) require 1.0.0 and then e.g. this package will not call methods annotated with @PostConstruct! I guess it would have been best from the beginning if all bundles would have imported it without a version but it is too late for that now. e4.core.di/MANIFEST.MF -- Manifest-Version: 1.0 Bundle-Localization: plugin Bundle-RequiredExecutionEnvironment: JavaSE-1.6 Built-By: e4Build Bundle-SymbolicName: org.eclipse.e4.core.di ... Import-Package: javax.annotation;version=1.0.0,javax.inject;version= 1.0.0 Tom ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
