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>
Sent: Friday, November 18, 2016 05:29 AM
To: OSGi Developer Mail List <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 <mailto: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 Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org <mailto: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
--
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
--
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
