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