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 <[email protected]>wrote: > >> 2011/1/12 Holger Hoffstätte<[email protected]> >>> >>> 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: [email protected] >> For additional commands, e-mail: [email protected] >> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
