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