In Eclipse we have the x-internal directive for that. http://help.eclipse.org/neon/index.jsp?topic=%2Forg.eclipse.platform.doc.isv%2Freference%2Fmisc%2Fbundle_manifest.html
But IIRC that is Equinox specific and no default OSGi feature. Am 18.11.2016 08:02 schrieb "Christian Schneider" <ch...@die-schneider.net>: I try to avoid fragments whereever possible. In this case fragments would not even help as there is one core bundle that offers the internal package and several others using it. Christian On 18.11.2016 01:50, Daghan ACAY wrote: I might be totally of with this but have you considered fragments? This link might be useful http://blog.vogella.com/2016/02/09/osgi-bundles-fragments-dependencies/ Cheers Daghan Sent by MailWise <http://www.mail-wise.com/installation/2> – See your emails as clean, short chats. -------- Original Message -------- From: Christian Schneider <ch...@die-schneider.net> <ch...@die-schneider.net> Sent: Friday, November 18, 2016 05:29 AM To: OSGi Developer Mail List <osgi-dev@mail.osgi.org> <osgi-dev@mail.osgi.org> Subject: Re: [osgi-dev] How to make packages only visible for some peer bundles? Well actually I did not expect it to work automatically. So I was not even trying it. After your comment I tested using a mandatory attribute and indeed it works fine. There is one caveat of course. As it works without additional config on the import side it also means that it will not really prevent people to simply use a class from the internal package. Still I think it is a good solution as the attribute can tell quite explicitly in which context it is appropriate to use the package. For example I used an attribute braveprivate=true. Which quite clearly tells that it is just form brave internal usage. So thanks for the hint. Christian On 14.11.2016 10:45, Timothy Ward wrote: 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 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 Schneiderhttp://www.liquid-reality.de Open Source Architecthttp://www.talend.com _______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev _______________________________________________ OSGi Developer Mail listosgi-...@mail.osgi.orghttps://mail.osgi.org/mailman/listinfo/osgi-dev -- Christian Schneiderhttp://www.liquid-reality.de Open Source Architecthttp://www.talend.com _______________________________________________ OSGi Developer Mail listosgi-...@mail.osgi.orghttps://mail.osgi.org/mailman/listinfo/osgi-dev -- Christian Schneiderhttp://www.liquid-reality.de Open Source Architecthttp://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
