Hi Christian, I’m really not sure why you aren’t advocating documentation *and* mandatory attributes. Bnd will add the attribute for you if it’s needed, so there’s no need to customise Import-Package and extra effort for the implementors in maintaining this, just an extra check at runtime to prevent class space wiring.
Regards, Tim > On 14 Nov 2016, at 08:48, Christian Schneider <ch...@die-schneider.net> wrote: > > 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 > <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 <http://www.liquid-reality.de/> > > Open Source Architect > http://www.talend.com <http://www.talend.com/> > _______________________________________________ > OSGi Developer Mail List > osgi-dev@mail.osgi.org > https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
