Well, if exported package p imports from package q, my understanding is
that q will need to be available ( imported ) wherever p is used ( "p uses
q" )
What state is "provisioned" ? active ? I'm not sure how the bundle would
resolve with q not exported, to begin with. Is your build system bnd? Who
or what writes the export-package line for this bundle?
You might also want to consider declarative services to share state (
"communicate information" ) across bundles without spreading your
dependencies across the system classpath
On 23 December 2014 at 15:18, Neil Bartlett <njbartl...@gmail.com> wrote:
> Your question is not very clear. Who or what uses the classes from package
> ‘q’? Where are they now and where do you want them to be?
>
> Please also report the actual error message from Felix. Merely stating
> that “Felix complains” is not informative.
>
> Regards,
> Neil
>
>
> > On 23 Dec 2014, at 13:58, Benson Margulies <ben...@basistech.com> wrote:
> >
> > I have a bundle that contains a set of classes that are used to
> communicate
> > information across the boundary of the OSGi container. All these classes
> > are in one package ('p'). That package is both imported and exported from
> > the bundle.
> >
> > The bundle also contains some support classes in the package that never
> > cross the boundary. They are in package 'q'. 'q' is neither imported nor
> > exported.
> >
> > I set up as follows:
> >
> > - The classes in 'p' are in my overall application classpath.
> > - 'p' is listed as a system bundle package
> > - the bundle is provisioned
> >
> > If I don't list 'q' in the system bundle packages, then Felix complains
> > that it cannot find classes in 'q'. I imagine that I'm missing something
> > basic here. Is there a way to avoid including 'q' in the system bundle?
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
> For additional commands, e-mail: users-h...@felix.apache.org
>
>
