I think it’s unproductive to speculate about this until Benson tells us the actual error message.
However it is certainly important to distinguish between dependencies that create a “uses” constraint versus pure internal usage. If ‘p’ exposes types from ‘q’ through its public interface then of course ‘q’ needs to be exported as well, otherwise there would be no way for importers to either construct or consume types from package ‘q’. On the other hand if ‘p’ merely employs ‘q’ types in its internal implementation code, there should be no need to export it. > On 23 Dec 2014, at 15:49, Andras Szerdahelyi <[email protected]> > wrote: > >> I am using declarative services, but I do need a data model to pass >> information into and out of the services. > > > i think your fundamental problem here is you are making this model > available to bundles via the system classpath. Export it ( preferably from > your service api bundle and in its _entirety_; ie anything p imports ( > "uses" ) also needs to be available from somewhere.. ) and let the > framework manage dependencies for you. > > > I was expecting that q could be a private package. Could it be that I have >> to explicitly declare 'q' as a Private-Package? > > > if your build system is bnd, you'll need this directive in your bnd file > for packages that are not exported or imported but should be present in the > bundle. Otherwise IIRC, its not an actual OSGi manifest header line. > > But again, if exported package p imports classes from q, q needs to be made > available ( exported ) from somewhere, so it has no business being "private" > > >> On 23 December 2014 at 16:02, Benson Margulies <[email protected]> >> wrote: >> > On Tue, Dec 23, 2014 at 9:54 AM, Andras Szerdahelyi < >> [email protected]> wrote: >>> >>> 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" ) >>> >> >> I was expecting that q could be a private package. Could it be that I have >> to explicitly declare 'q' as a Private-Package? >> >> >> >>> >>> 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 >>> >> >> I am using declarative services, but I do need a data model to pass >> information into and out of the services. >> >> >> >> >>> >>> On 23 December 2014 at 15:18, Neil Bartlett <[email protected]> >> 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 <[email protected]> >>> 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: [email protected] >>>> For additional commands, e-mail: [email protected] >>>> >>>> >>> >> --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
