I am currently helping at openzipkin to make it fully OSGi ready. At one
of the projects we came up with a problem that is of some general
relevance.
In the project brave-core there is a package
com.github.kristofa.brave.internal. It contains several classes that are
used inside other brave modules but should not be used by users. It
started with an annotation that we were able to limit to source
retention .. but there are also normal classes that will require package
visibility.
See:
https://github.com/openzipkin/brave/issues/268
I know several possible solutions:
* Export the package but document in the classes that they are brave
internal. This solution has the advantage that it is easiest to
configure
* Shade the package into each brave module in different package. So
the classes become internally embedded into each module. This
approach requires quite a bit of tuning in each module and is
sensitive to changes in the code.
* Use mandatory attributes like recommended by Neil. I will scope how
I would do this below. The disadvantage here seems to be that we
need a manually tuned Import-Package statement in each module that
imports the package.
How to use a mandatory attribute for the project public package:
In brave-core:
Export-Package:
com.github.kristofa.brave.internal;brave=true;mandatory=brave
In brave modules:
Import-Package: com.github.kristofa.brave.internal;brave=true
So this would make the package visible to other brave modules but would
make sure users do not accidently use the package. Of course users could
still import the package like above if they intend to break things.
So I personally would go with the first option to just document that the
package and the classes are for internal use. The main reason for me is
to minimize the configuration effort inside brave. The problem is that
brave and zipkin maintainers do not use OSGi themselves. So the more
complicated we make the configuration the more likely it is to break
over time.
So what strategy would you recommend for this problem? Are there ways to
make the other options easy to maintain too?
Christian
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
