You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@felix.apache.org by Clay McCoy <cm...@claymccoy.com> on 2011/01/12 00:04:57 UTC
What do I do about strange package in Import-Package?
I have a dependency on guava and I am using Embed dependencies. The maven
plugin bundle adds javax.annotation and sun.misc to the import packages of
the manifest. I'm not sure why or if it is what I want to happen.
It causes an error when an OSGI bundle consumes my project because it tries
to find sun.misc and can't:
[INFO] Cannot complete the request. Generating details.
[INFO] {org.osgi.framework.executionenvironment=OSGi/Minimum-1.0,OSGi/Minimum-1.1,
osgi.ws=win32, osgi.arch=x86_64, osgi.os=win32,
org.eclipse.update.install.features=true,
org.osgi.framework.system.packages=}
[INFO] [Software being installed: example.p2.repo
raw:0.1.0.'SNAPSHOT'/format(n[.n=0;[.n=0;[-S]]]):0.1.0-SNAPSHOT,
Missing requirement: com.jha.yhs.pomfirst-bundle 0.1.0.SNAPSHOT
requires 'package sun.misc 0.0.0' but it could not be found, Cannot
satisfy dependency: example.p2.repo
raw:0.1.0.'SNAPSHOT'/format(n[.n=0;[.n=0;[-S]]]):0.1.0-SNAPSHOT
depends on: feature.feature.group [0.1.0,0.1.1), Cannot satisfy
dependency: feature.feature.group 0.1.0.qualifier depends on:
com.jha.yhs.pomfirst-bundle [0.1.0.SNAPSHOT]]
Below are the pom and the generated manifest.
Thanks,
Clay
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="
http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/maven-v4_0_0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>com.jha.yhs</groupId>
<artifactId>pomfirst-bundle</artifactId>
<version>0.1.0-SNAPSHOT</version>
<packaging>bundle</packaging>
<repositories>
<repository>
<id>nexus</id>
<name>Yellow Hammer Nexus</name>
<url>http://haldevyh:8083/nexus/content/groups/public</url>
<snapshots>
<enabled>true</enabled>
<updatePolicy>always</updatePolicy>
<checksumPolicy>warn</checksumPolicy>
</snapshots>
</repository>
</repositories>
<distributionManagement>
<repository>
<id>releases</id>
<name>Internal Releases</name>
<url>http://haldevyh:8083/nexus/content/repositories/releases</url>
</repository>
<snapshotRepository>
<id>snapshots</id>
<name>Internal Snapshots</name>
<url>http://haldevyh:8083/nexus/content/repositories/snapshots</url>
<uniqueVersion>false</uniqueVersion>
</snapshotRepository>
</distributionManagement>
<dependencies>
<dependency>
<groupId>com.google.guava</groupId>
<artifactId>guava</artifactId>
<version>r07</version>
</dependency>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>4.8.2</version>
<scope>test</scope>
</dependency>
</dependencies>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>2.0.2</version>
<configuration>
<source>1.6</source>
<target>1.6</target>
</configuration>
</plugin>
<plugin>
<groupId>org.apache.felix</groupId>
<artifactId>maven-bundle-plugin</artifactId>
<version>2.1.0</version>
<extensions>true</extensions>
<configuration>
<manifestLocation>META-INF</manifestLocation>
<instructions>
<Embed-Dependency>*;scope=compile|runtime</Embed-Dependency>
<Embed-Transitive>true</Embed-Transitive>
</instructions>
</configuration>
</plugin>
</plugins>
</build>
</project>
Manifest-Version: 1.0
Export-Package: com.jha.yhs.pomfirst
Bundle-ClassPath: .,guava-r07.jar
Built-By: crowmobe
Tool: Bnd-0.0.357
Bundle-Name: Unnamed - com.jha.yhs:pomfirst-bundle:bundle:0.1.0-SNAPSH
OT
Created-By: Apache Maven Bundle Plugin
Build-Jdk: 1.6.0_22
Bundle-Version: 0.1.0.SNAPSHOT
Bnd-LastModified: 1294785977314
Embed-Transitive: true
Bundle-ManifestVersion: 2
Embed-Dependency: *;scope=compile|runtime
Import-Package: com.jha.yhs.pomfirst,javax.annotation,sun.misc
Bundle-SymbolicName: com.jha.yhs.pomfirst-bundle
Re: What do I do about strange package in Import-Package?
Posted by Clay McCoy <cm...@claymccoy.com>.
I added an instruction making that package optional. Better suggestions are
welcome.
<instructions>
<Embed-Dependency>*;scope=compile|runtime</Embed-Dependency>
<Embed-Transitive>true</Embed-Transitive>
<Import-Package>sun.misc;resolution:=optional,*</Import-Package>
</instructions>
Re: What do I do about strange package in Import-Package?
Posted by Justin Edelson <ju...@gmail.com>.
On 1/12/11 11:13 AM, Clay McCoy wrote:
> I appreciate the back and forth about OSGI's strengths and frustrations.
> But can someone with more felix/osgi experience than me please give me some
> pragmatic advice about what to do in this particular case.
It's pretty simple. There are two options:
1) sun.misc is required for the use of the bundle.
2) sun.misc isn't required for the use of the bundle.
If (1) have the system bundle export sun.misc. If (2) have the import be
optional.
Whether (1) or (2) is true is a guava question, not a felix/osgi question.
> I don't think it is a odd thing to want to use guava inside my bundle as an
> implementation detail, and not have anything outside the bundle know or
> care. That's the whole point of modularity.
This is the case. The issue you are having is that your bundle depends
upon a package which is not available in the framework. That this unmet
dependency (to sun.misc) is through an embedded dependency (from guava)
isn't relevant. The same thing would be true if sun.misc was directly
referenced from your code.
>
> sun.misc appears to be optional, at least in one case:
> http://hiroshiyamauchi.blogspot.com/
>
> It is not guaranteed to be in the jvm. Do I manually need to do something
> to keep that package out of the manifest, or make it optional somehow with
> an instruction in my pom? What are the ramifications of doing that? What
> is the typical course of action here?
Optional packages are defined in section 3.6.3 of the OSGi 4.2 spec.
That describes both the manifest header syntax and the ramifications for
client bundles.
>
> Thanks,
> Clay
>
> On Wed, Jan 12, 2011 at 9:59 AM, Richard S. Hall <he...@ungoverned.org>wrote:
>
>> 2011/1/12 Holger Hoffstätte<ho...@googlemail.com>
>>>
>>> On 12.01.2011 15:13, Clay McCoy wrote:
>>>>
>>>>> The whole reason that I am trying to use Embed dependencies and
>>>>>
>>>> transitive =
>>>>
>>>>> true is so that I don't have to deal with dependencies. They are all
>>>>> supposed to be embedded into a self contained jar.
>>>>> But now I am having to deal with sun.misc. This seems like a conceptual
>>>>> flaw with the plugin or a misconception on my part.
>>>>>
>>>> The misconception on your part is the gross modularity violation by
>>>> Guava, which relies on a JDK-specific package. The error you get is
>>>> *good* and the whole point of OSGi. Blaming OSGi for the last 15 years
>>>> of Java's carelessness and the community's ignorance of modularity is
>>>> easy, but misses the point.
>>>>
>>>>
>>>> I'm not blaiming OSGI, I think its ideals are good. But it would be nice
>>> with tools to help lessen migratory pains, I'm not advocating changes in
>>> OSGI itself. On the other hand I myself am not willing to put effort into
>>> that, so I should probably shut up.
>>>
>>
>> The reality is, you just keep perpetuating the same poor modularity
>> practices. Migration is a pain because there is a complete shift in world
>> view. You go from a world where every public type on the class path is
>> visible to one where only public types in java.* packages are visible
>> (unless you explicitly import additional packages). This is not something
>> that can easily be swept under the rug by tools, especially when it comes to
>> packages like sun.misc.
>>
>> -> richard
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: What do I do about strange package in Import-Package?
Posted by John Bäckstrand <so...@gmail.com>.
On Wed, Jan 12, 2011 at 19:05, Clay McCoy <cm...@claymccoy.com> wrote:
> >
> >
> > If you want to completely embed it and not have it be visible at all or
> > impact your bundle, then you need to embed it and all of its
> dependencies.
>
>
> That is what I am doing isn't it? Is there something that I should be doing
> more than embed dependencies and setting transitives to true? I don't
> understand what you are suggesting here.
>
> I am surprised by the maven bundle plugin in this case. I would expect it
> to do one of two things.
> * Actually bring in everything it needs (sun.misc included)
> or
> * Fail if it can't bring in a dependency. After all that i what I asked it
> to do.
>
> The fact that it doesn't bring it all in and is quiet about it seems wrong.
> Is this intended?
>
This is due to how BND/osgi works. I think the maven-bundle-plugin does
things correctly on the maven side, but BND on the other hand looks at
actual packages in the binary classes. This essentially detects usage that
is not in maven a maven dependency.
--
John Bäckstrand
Re: What do I do about strange package in Import-Package?
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 1/12/11 13:05, Clay McCoy wrote:
>>
>> If you want to completely embed it and not have it be visible at all or
>> impact your bundle, then you need to embed it and all of its dependencies.
>
> That is what I am doing isn't it? Is there something that I should be doing
> more than embed dependencies and setting transitives to true? I don't
> understand what you are suggesting here.
I'm not suggesting anything. I am summarizing what you need to do. If
you are already doing, then that's fine.
> I am surprised by the maven bundle plugin in this case. I would expect it
> to do one of two things.
> * Actually bring in everything it needs (sun.misc included)
> or
> * Fail if it can't bring in a dependency. After all that i what I asked it
> to do.
>
> The fact that it doesn't bring it all in and is quiet about it seems wrong.
> Is this intended?
I believe the dependencies being referred to are Maven dependencies, not
package dependencies. The sun.misc package is not in a JAR file on which
you have a Maven dependency.
-> richard
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: What do I do about strange package in Import-Package?
Posted by Clay McCoy <cm...@claymccoy.com>.
>
>
> If you want to completely embed it and not have it be visible at all or
> impact your bundle, then you need to embed it and all of its dependencies.
That is what I am doing isn't it? Is there something that I should be doing
more than embed dependencies and setting transitives to true? I don't
understand what you are suggesting here.
I am surprised by the maven bundle plugin in this case. I would expect it
to do one of two things.
* Actually bring in everything it needs (sun.misc included)
or
* Fail if it can't bring in a dependency. After all that i what I asked it
to do.
The fact that it doesn't bring it all in and is quiet about it seems wrong.
Is this intended?
Re: What do I do about strange package in Import-Package?
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 1/12/11 11:13, Clay McCoy wrote:
> I appreciate the back and forth about OSGI's strengths and frustrations.
> But can someone with more felix/osgi experience than me please give me some
> pragmatic advice about what to do in this particular case.
> I don't think it is a odd thing to want to use guava inside my bundle as an
> implementation detail, and not have anything outside the bundle know or
> care. That's the whole point of modularity.
>
> sun.misc appears to be optional, at least in one case:
> http://hiroshiyamauchi.blogspot.com/
>
> It is not guaranteed to be in the jvm. Do I manually need to do something
> to keep that package out of the manifest, or make it optional somehow with
> an instruction in my pom? What are the ramifications of doing that? What
> is the typical course of action here?
If you want to completely embed it and not have it be visible at all or
impact your bundle, then you need to embed it and all of its
dependencies. If you are certain that sun.misc isn't needed, then just
tell the bnd to ignore it (e.g.,
<Import-Package>!sun.misc,*</Import-Package>). As long as the remaining
code only needs what is contained in the bundle and doesn't make any
other assumptions about type visibility or the duration of its lifetime,
then it will work fine.
-> richard
> Thanks,
> Clay
>
> On Wed, Jan 12, 2011 at 9:59 AM, Richard S. Hall<he...@ungoverned.org>wrote:
>
>> 2011/1/12 Holger Hoffstätte<ho...@googlemail.com>
>>> On 12.01.2011 15:13, Clay McCoy wrote:
>>>>> The whole reason that I am trying to use Embed dependencies and
>>>>>
>>>> transitive =
>>>>
>>>>> true is so that I don't have to deal with dependencies. They are all
>>>>> supposed to be embedded into a self contained jar.
>>>>> But now I am having to deal with sun.misc. This seems like a conceptual
>>>>> flaw with the plugin or a misconception on my part.
>>>>>
>>>> The misconception on your part is the gross modularity violation by
>>>> Guava, which relies on a JDK-specific package. The error you get is
>>>> *good* and the whole point of OSGi. Blaming OSGi for the last 15 years
>>>> of Java's carelessness and the community's ignorance of modularity is
>>>> easy, but misses the point.
>>>>
>>>>
>>>> I'm not blaiming OSGI, I think its ideals are good. But it would be nice
>>> with tools to help lessen migratory pains, I'm not advocating changes in
>>> OSGI itself. On the other hand I myself am not willing to put effort into
>>> that, so I should probably shut up.
>>>
>> The reality is, you just keep perpetuating the same poor modularity
>> practices. Migration is a pain because there is a complete shift in world
>> view. You go from a world where every public type on the class path is
>> visible to one where only public types in java.* packages are visible
>> (unless you explicitly import additional packages). This is not something
>> that can easily be swept under the rug by tools, especially when it comes to
>> packages like sun.misc.
>>
>> -> richard
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: What do I do about strange package in Import-Package?
Posted by Clay McCoy <cm...@claymccoy.com>.
I appreciate the back and forth about OSGI's strengths and frustrations.
But can someone with more felix/osgi experience than me please give me some
pragmatic advice about what to do in this particular case.
I don't think it is a odd thing to want to use guava inside my bundle as an
implementation detail, and not have anything outside the bundle know or
care. That's the whole point of modularity.
sun.misc appears to be optional, at least in one case:
http://hiroshiyamauchi.blogspot.com/
It is not guaranteed to be in the jvm. Do I manually need to do something
to keep that package out of the manifest, or make it optional somehow with
an instruction in my pom? What are the ramifications of doing that? What
is the typical course of action here?
Thanks,
Clay
On Wed, Jan 12, 2011 at 9:59 AM, Richard S. Hall <he...@ungoverned.org>wrote:
> 2011/1/12 Holger Hoffstätte<ho...@googlemail.com>
>>
>> On 12.01.2011 15:13, Clay McCoy wrote:
>>>
>>>> The whole reason that I am trying to use Embed dependencies and
>>>>
>>> transitive =
>>>
>>>> true is so that I don't have to deal with dependencies. They are all
>>>> supposed to be embedded into a self contained jar.
>>>> But now I am having to deal with sun.misc. This seems like a conceptual
>>>> flaw with the plugin or a misconception on my part.
>>>>
>>> The misconception on your part is the gross modularity violation by
>>> Guava, which relies on a JDK-specific package. The error you get is
>>> *good* and the whole point of OSGi. Blaming OSGi for the last 15 years
>>> of Java's carelessness and the community's ignorance of modularity is
>>> easy, but misses the point.
>>>
>>>
>>> I'm not blaiming OSGI, I think its ideals are good. But it would be nice
>> with tools to help lessen migratory pains, I'm not advocating changes in
>> OSGI itself. On the other hand I myself am not willing to put effort into
>> that, so I should probably shut up.
>>
>
> The reality is, you just keep perpetuating the same poor modularity
> practices. Migration is a pain because there is a complete shift in world
> view. You go from a world where every public type on the class path is
> visible to one where only public types in java.* packages are visible
> (unless you explicitly import additional packages). This is not something
> that can easily be swept under the rug by tools, especially when it comes to
> packages like sun.misc.
>
> -> richard
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
Re: What do I do about strange package in Import-Package?
Posted by "Richard S. Hall" <he...@ungoverned.org>.
> 2011/1/12 Holger Hoffstätte<ho...@googlemail.com>
>
>> On 12.01.2011 15:13, Clay McCoy wrote:
>>> The whole reason that I am trying to use Embed dependencies and
>> transitive =
>>> true is so that I don't have to deal with dependencies. They are all
>>> supposed to be embedded into a self contained jar.
>>> But now I am having to deal with sun.misc. This seems like a conceptual
>>> flaw with the plugin or a misconception on my part.
>> The misconception on your part is the gross modularity violation by
>> Guava, which relies on a JDK-specific package. The error you get is
>> *good* and the whole point of OSGi. Blaming OSGi for the last 15 years
>> of Java's carelessness and the community's ignorance of modularity is
>> easy, but misses the point.
>>
>>
> I'm not blaiming OSGI, I think its ideals are good. But it would be nice
> with tools to help lessen migratory pains, I'm not advocating changes in
> OSGI itself. On the other hand I myself am not willing to put effort into
> that, so I should probably shut up.
The reality is, you just keep perpetuating the same poor modularity
practices. Migration is a pain because there is a complete shift in
world view. You go from a world where every public type on the class
path is visible to one where only public types in java.* packages are
visible (unless you explicitly import additional packages). This is not
something that can easily be swept under the rug by tools, especially
when it comes to packages like sun.misc.
-> richard
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: What do I do about strange package in Import-Package?
Posted by John Bäckstrand <so...@gmail.com>.
2011/1/12 Holger Hoffstätte <ho...@googlemail.com>
> On 12.01.2011 15:13, Clay McCoy wrote:
> > The whole reason that I am trying to use Embed dependencies and
> transitive =
> > true is so that I don't have to deal with dependencies. They are all
> > supposed to be embedded into a self contained jar.
> > But now I am having to deal with sun.misc. This seems like a conceptual
> > flaw with the plugin or a misconception on my part.
>
> The misconception on your part is the gross modularity violation by
> Guava, which relies on a JDK-specific package. The error you get is
> *good* and the whole point of OSGi. Blaming OSGi for the last 15 years
> of Java's carelessness and the community's ignorance of modularity is
> easy, but misses the point.
>
>
I'm not blaiming OSGI, I think its ideals are good. But it would be nice
with tools to help lessen migratory pains, I'm not advocating changes in
OSGI itself. On the other hand I myself am not willing to put effort into
that, so I should probably shut up.
Re: What do I do about strange package in Import-Package?
Posted by Holger Hoffstätte <ho...@googlemail.com>.
On 12.01.2011 15:13, Clay McCoy wrote:
> The whole reason that I am trying to use Embed dependencies and transitive =
> true is so that I don't have to deal with dependencies. They are all
> supposed to be embedded into a self contained jar.
> But now I am having to deal with sun.misc. This seems like a conceptual
> flaw with the plugin or a misconception on my part.
The misconception on your part is the gross modularity violation by
Guava, which relies on a JDK-specific package. The error you get is
*good* and the whole point of OSGi. Blaming OSGi for the last 15 years
of Java's carelessness and the community's ignorance of modularity is
easy, but misses the point.
-h
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: What do I do about strange package in Import-Package?
Posted by Justin Edelson <ju...@gmail.com>.
On 1/12/11 9:13 AM, Clay McCoy wrote:
> The whole reason that I am trying to use Embed dependencies and transitive =
> true is so that I don't have to deal with dependencies. They are all
> supposed to be embedded into a self contained jar.
> But now I am having to deal with sun.misc. This seems like a conceptual
> flaw with the plugin or a misconception on my part.
There are Maven plugins designed for building uberjars. Use of of those
if you're not actually interested in using OSGi.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: What do I do about strange package in Import-Package?
Posted by John Bäckstrand <so...@gmail.com>.
Oh, and I missed stating my original point in posting: I feel the
maven-bundle-plugin should allow the "add everything this dep needs, and
never bother me about it" thought you are having. Sadly this does not really
work.
On Wed, Jan 12, 2011 at 15:13, Clay McCoy <cm...@claymccoy.com> wrote:
> The whole reason that I am trying to use Embed dependencies and transitive
> =
> true is so that I don't have to deal with dependencies. They are all
> supposed to be embedded into a self contained jar.
> But now I am having to deal with sun.misc. This seems like a conceptual
> flaw with the plugin or a misconception on my part.
>
> On Tue, Jan 11, 2011 at 5:45 PM, Justin Edelson <justin@justinedelson.com
> >wrote:
>
> > The system bundle is described in section 4.6 of the OSGi core spec.
> >
> > On Jan 11, 2011, at 6:36 PM, Clay McCoy <cm...@claymccoy.com> wrote:
> >
> > > What is the system bundle?
> > > I don't know what guava needs, and I don't want to.
> > >
> > > On Jan 11, 2011 5:09 PM, "Justin Edelson" <ju...@justinedelson.com>
> > wrote:
> > >
> > > If this package is necessary for guava to operate, you should add it to
> > the
> > > system bundle's exports.
> > >
> > > Justin
> > >
> > > On Jan 11, 2011, at 6:04 PM, Clay McCoy <cm...@claymccoy.com> wrote: > I
> > have a
> > > dependency on guava a...
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> > > For additional commands, e-mail: users-help@felix.apache.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> > For additional commands, e-mail: users-help@felix.apache.org
> >
> >
>
--
John Bäckstrand
Re: What do I do about strange package in Import-Package?
Posted by John Bäckstrand <so...@gmail.com>.
This is, I think, the biggest problem with OSGI for me at least. The maven
dependency model is different from OSGI (classloaders work differently, so
some packages will just not work. Also implied classes from JDKs etc are
"just there" seemingly when using maven + a JDK to run things) and the
maven-bundle-plugin does not automatically convert from maven bundles to
something useable in osgi. This is not possible generally for it, but it
feels as if it could still be improved slightly.
I actually use guava in OSGI though, and did not have this particular
problem. I might have been using a pre-realease maven-bundle-plugin, but
dont think the guava was a specific osgi-bundle.
On Wed, Jan 12, 2011 at 15:13, Clay McCoy <cm...@claymccoy.com> wrote:
> The whole reason that I am trying to use Embed dependencies and transitive
> =
> true is so that I don't have to deal with dependencies. They are all
> supposed to be embedded into a self contained jar.
> But now I am having to deal with sun.misc. This seems like a conceptual
> flaw with the plugin or a misconception on my part.
>
> On Tue, Jan 11, 2011 at 5:45 PM, Justin Edelson <justin@justinedelson.com
> >wrote:
>
> > The system bundle is described in section 4.6 of the OSGi core spec.
> >
> > On Jan 11, 2011, at 6:36 PM, Clay McCoy <cm...@claymccoy.com> wrote:
> >
> > > What is the system bundle?
> > > I don't know what guava needs, and I don't want to.
> > >
> > > On Jan 11, 2011 5:09 PM, "Justin Edelson" <ju...@justinedelson.com>
> > wrote:
> > >
> > > If this package is necessary for guava to operate, you should add it to
> > the
> > > system bundle's exports.
> > >
> > > Justin
> > >
> > > On Jan 11, 2011, at 6:04 PM, Clay McCoy <cm...@claymccoy.com> wrote: > I
> > have a
> > > dependency on guava a...
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> > > For additional commands, e-mail: users-help@felix.apache.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> > For additional commands, e-mail: users-help@felix.apache.org
> >
> >
>
--
John Bäckstrand
Re: What do I do about strange package in Import-Package?
Posted by Stuart McCulloch <mc...@gmail.com>.
On 12 January 2011 14:13, Clay McCoy <cm...@claymccoy.com> wrote:
> The whole reason that I am trying to use Embed dependencies and transitive
> =
> true is so that I don't have to deal with dependencies. They are all
> supposed to be embedded into a self contained jar.
> But now I am having to deal with sun.misc. This seems like a conceptual
> flaw with the plugin or a misconception on my part.
>
Not really - you're embedding the whole jar, and the plugin can't tell what
bits you might end up using.
What happens in the future if you call some method in Guava that then calls
another Guava method
that uses the "sun.misc.Unsafe" class (which may not exist on all JDKs as
it's not a standard API)
The safest (and easiest) option in this case is to mark it as optional,
which is what you did I believe.
Or to put it another way... how would you suggest the plugin handle this
situation? How can it tell
that this import is not required, compared to other non-local references
that should require imports?
On Tue, Jan 11, 2011 at 5:45 PM, Justin Edelson <justin@justinedelson.com
> >wrote:
>
> > The system bundle is described in section 4.6 of the OSGi core spec.
> >
> > On Jan 11, 2011, at 6:36 PM, Clay McCoy <cm...@claymccoy.com> wrote:
> >
> > > What is the system bundle?
> > > I don't know what guava needs, and I don't want to.
> > >
> > > On Jan 11, 2011 5:09 PM, "Justin Edelson" <ju...@justinedelson.com>
> > wrote:
> > >
> > > If this package is necessary for guava to operate, you should add it to
> > the
> > > system bundle's exports.
> > >
> > > Justin
> > >
> > > On Jan 11, 2011, at 6:04 PM, Clay McCoy <cm...@claymccoy.com> wrote: > I
> > have a
> > > dependency on guava a...
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> > > For additional commands, e-mail: users-help@felix.apache.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> > For additional commands, e-mail: users-help@felix.apache.org
> >
> >
>
--
Cheers, Stuart
Re: What do I do about strange package in Import-Package?
Posted by Clay McCoy <cm...@claymccoy.com>.
The whole reason that I am trying to use Embed dependencies and transitive =
true is so that I don't have to deal with dependencies. They are all
supposed to be embedded into a self contained jar.
But now I am having to deal with sun.misc. This seems like a conceptual
flaw with the plugin or a misconception on my part.
On Tue, Jan 11, 2011 at 5:45 PM, Justin Edelson <ju...@justinedelson.com>wrote:
> The system bundle is described in section 4.6 of the OSGi core spec.
>
> On Jan 11, 2011, at 6:36 PM, Clay McCoy <cm...@claymccoy.com> wrote:
>
> > What is the system bundle?
> > I don't know what guava needs, and I don't want to.
> >
> > On Jan 11, 2011 5:09 PM, "Justin Edelson" <ju...@justinedelson.com>
> wrote:
> >
> > If this package is necessary for guava to operate, you should add it to
> the
> > system bundle's exports.
> >
> > Justin
> >
> > On Jan 11, 2011, at 6:04 PM, Clay McCoy <cm...@claymccoy.com> wrote: > I
> have a
> > dependency on guava a...
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> > For additional commands, e-mail: users-help@felix.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
Re: What do I do about strange package in Import-Package?
Posted by Justin Edelson <ju...@justinedelson.com>.
The system bundle is described in section 4.6 of the OSGi core spec.
On Jan 11, 2011, at 6:36 PM, Clay McCoy <cm...@claymccoy.com> wrote:
> What is the system bundle?
> I don't know what guava needs, and I don't want to.
>
> On Jan 11, 2011 5:09 PM, "Justin Edelson" <ju...@justinedelson.com> wrote:
>
> If this package is necessary for guava to operate, you should add it to the
> system bundle's exports.
>
> Justin
>
> On Jan 11, 2011, at 6:04 PM, Clay McCoy <cm...@claymccoy.com> wrote: > I have a
> dependency on guava a...
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: What do I do about strange package in Import-Package?
Posted by Clay McCoy <cm...@claymccoy.com>.
What is the system bundle?
I don't know what guava needs, and I don't want to.
On Jan 11, 2011 5:09 PM, "Justin Edelson" <ju...@justinedelson.com> wrote:
If this package is necessary for guava to operate, you should add it to the
system bundle's exports.
Justin
On Jan 11, 2011, at 6:04 PM, Clay McCoy <cm...@claymccoy.com> wrote: > I have a
dependency on guava a...
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: What do I do about strange package in Import-Package?
Posted by Justin Edelson <ju...@justinedelson.com>.
If this package is necessary for guava to operate, you should add it to the system bundle's exports.
Justin
On Jan 11, 2011, at 6:04 PM, Clay McCoy <cm...@claymccoy.com> wrote:
> I have a dependency on guava and I am using Embed dependencies. The maven
> plugin bundle adds javax.annotation and sun.misc to the import packages of
> the manifest. I'm not sure why or if it is what I want to happen.
> It causes an error when an OSGI bundle consumes my project because it tries
> to find sun.misc and can't:
>
> [INFO] Cannot complete the request. Generating details.
> [INFO] {org.osgi.framework.executionenvironment=OSGi/Minimum-1.0,OSGi/Minimum-1.1,
> osgi.ws=win32, osgi.arch=x86_64, osgi.os=win32,
> org.eclipse.update.install.features=true,
> org.osgi.framework.system.packages=}
> [INFO] [Software being installed: example.p2.repo
> raw:0.1.0.'SNAPSHOT'/format(n[.n=0;[.n=0;[-S]]]):0.1.0-SNAPSHOT,
> Missing requirement: com.jha.yhs.pomfirst-bundle 0.1.0.SNAPSHOT
> requires 'package sun.misc 0.0.0' but it could not be found, Cannot
> satisfy dependency: example.p2.repo
> raw:0.1.0.'SNAPSHOT'/format(n[.n=0;[.n=0;[-S]]]):0.1.0-SNAPSHOT
> depends on: feature.feature.group [0.1.0,0.1.1), Cannot satisfy
> dependency: feature.feature.group 0.1.0.qualifier depends on:
> com.jha.yhs.pomfirst-bundle [0.1.0.SNAPSHOT]]
>
>
> Below are the pom and the generated manifest.
> Thanks,
> Clay
>
> <?xml version="1.0" encoding="UTF-8"?>
> <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="
> http://www.w3.org/2001/XMLSchema-instance"
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/maven-v4_0_0.xsd">
>
> <modelVersion>4.0.0</modelVersion>
> <groupId>com.jha.yhs</groupId>
> <artifactId>pomfirst-bundle</artifactId>
> <version>0.1.0-SNAPSHOT</version>
> <packaging>bundle</packaging>
>
> <repositories>
> <repository>
> <id>nexus</id>
> <name>Yellow Hammer Nexus</name>
> <url>http://haldevyh:8083/nexus/content/groups/public</url>
> <snapshots>
> <enabled>true</enabled>
> <updatePolicy>always</updatePolicy>
> <checksumPolicy>warn</checksumPolicy>
> </snapshots>
> </repository>
> </repositories>
>
> <distributionManagement>
> <repository>
> <id>releases</id>
> <name>Internal Releases</name>
> <url>http://haldevyh:8083/nexus/content/repositories/releases</url>
> </repository>
> <snapshotRepository>
> <id>snapshots</id>
> <name>Internal Snapshots</name>
> <url>http://haldevyh:8083/nexus/content/repositories/snapshots</url>
> <uniqueVersion>false</uniqueVersion>
> </snapshotRepository>
> </distributionManagement>
>
>
> <dependencies>
>
> <dependency>
> <groupId>com.google.guava</groupId>
> <artifactId>guava</artifactId>
> <version>r07</version>
> </dependency>
> <dependency>
> <groupId>junit</groupId>
> <artifactId>junit</artifactId>
> <version>4.8.2</version>
> <scope>test</scope>
> </dependency>
> </dependencies>
>
> <build>
> <plugins>
> <plugin>
> <groupId>org.apache.maven.plugins</groupId>
> <artifactId>maven-compiler-plugin</artifactId>
> <version>2.0.2</version>
> <configuration>
> <source>1.6</source>
> <target>1.6</target>
> </configuration>
> </plugin>
>
> <plugin>
> <groupId>org.apache.felix</groupId>
> <artifactId>maven-bundle-plugin</artifactId>
> <version>2.1.0</version>
> <extensions>true</extensions>
> <configuration>
> <manifestLocation>META-INF</manifestLocation>
> <instructions>
> <Embed-Dependency>*;scope=compile|runtime</Embed-Dependency>
> <Embed-Transitive>true</Embed-Transitive>
> </instructions>
> </configuration>
> </plugin>
>
> </plugins>
> </build>
>
> </project>
>
>
>
> Manifest-Version: 1.0
> Export-Package: com.jha.yhs.pomfirst
> Bundle-ClassPath: .,guava-r07.jar
> Built-By: crowmobe
> Tool: Bnd-0.0.357
> Bundle-Name: Unnamed - com.jha.yhs:pomfirst-bundle:bundle:0.1.0-SNAPSH
> OT
> Created-By: Apache Maven Bundle Plugin
> Build-Jdk: 1.6.0_22
> Bundle-Version: 0.1.0.SNAPSHOT
> Bnd-LastModified: 1294785977314
> Embed-Transitive: true
> Bundle-ManifestVersion: 2
> Embed-Dependency: *;scope=compile|runtime
> Import-Package: com.jha.yhs.pomfirst,javax.annotation,sun.misc
> Bundle-SymbolicName: com.jha.yhs.pomfirst-bundle
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org