You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@felix.apache.org by Dmitry Skavish <sk...@gmail.com> on 2009/08/12 23:02:56 UTC

two bundles exporting the same package

Hi,
So I have this case when I have two (or more) bundles exporting the same
package, but different classes in them and I have another bundle which is
importing classes from this package. The problem is that I am getting an
error saying that some classes could not be found, i.e. classes from this
common package. It seems as though the importing is possible only from one
of the bundles. Importing the same package in those bundles in a manifest
does not help.

I am using google guice and basically the error is originated in guice when
it tries to inject one of those imported classes. I am suspecting that it
has something to do with it, probably proxies guice creates or something
like that.

Does anybody know what I am talking about here? Any solutions? Bridge
classloaders maybe?

Thanks!

-- 
Dmitry Skavish

Re: two bundles exporting the same package

Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 8/13/09 11:39, Dmitry Skavish wrote:
> I mean if a package comes only from one bundle it
> basically means that we have dependency on that bundle (although not by name
> of the bundle).
>    

Exactly! :-)

That is a big difference.

-> richard

> On Wed, Aug 12, 2009 at 5:27 PM,<cr...@habuma.com>  wrote:
>
>    
>> You've encountered a split-packages problem. That is, while multiple
>> bundles can export a package, a bundle can only import from one of them.
>>
>> In general, split-packages are a bad thing and break modularization. But,
>> they are a reality and so there are a few ways to deal with them.
>>
>> I hesitate to suggest it, but Require-Bundle is one way...instead of
>> importing the package, require the whole bundle. But use Require-Bundle
>> very carefully, as it creates an undesirable bundle-to-bundle coupling.
>>
>> Another way I've dealt with it is to embed one bundle in the other
>> (actually, the embedded one doesn't even have to be a bundle...a plain JAR
>> will work). Be sure to put the embedded JAR in the outer bundle's
>> Bundle-ClassPath. Then, when the outer bundle exports the package, the
>> entire package will be exported (from both JARs). This is especially
>> useful if the embedded JAR file is only useful within the context of the
>> bundle it is embedded in. For example, I did with with Lucene and Compass.
>> Both export some of the same Lucene packages. So, I embedded Lucene within
>> a Compass bundle because I wasn't planning on using Lucene without
>> Compass.
>>
>> Others on this list may have other suggestions, but these are the two I've
>> used.
>>
>>
>>      
>>> Hi,
>>> So I have this case when I have two (or more) bundles exporting the same
>>> package, but different classes in them and I have another bundle which is
>>> importing classes from this package. The problem is that I am getting an
>>> error saying that some classes could not be found, i.e. classes from this
>>> common package. It seems as though the importing is possible only from
>>>        
>> one
>>      
>>> of the bundles. Importing the same package in those bundles in a manifest
>>> does not help.
>>>
>>> I am using google guice and basically the error is originated in guice
>>> when
>>> it tries to inject one of those imported classes. I am suspecting that it
>>> has something to do with it, probably proxies guice creates or something
>>> like that.
>>>
>>> Does anybody know what I am talking about here? Any solutions? Bridge
>>> classloaders maybe?
>>>
>>> Thanks!
>>>
>>> --
>>> Dmitry Skavish
>>>
>>>        
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>>      
>
>    

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org


Re: two bundles exporting the same package

Posted by cr...@habuma.com.
> But if you think about it forbidding split packages is very
> similar to supporting Require-Bundle which is usually frowned upon

Not really. Saying "Require-Bundle: Ozarka" means that you *MUST* have
Ozarka. You won't accept any imitations. If Ozarka isn't available, then
you can't go on...even if a perfectly suitable Ozarka alternative is
available.

Saying "Import-Package: com.habuma.water" says that you need
com.habuma.water. It doesn't matter who provides it. It may be the Ozarka
bundle...or it may be Aquafina...or it may be Evian. If you're thirsty,
does it really matter where the water comes from?




---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org


Re: two bundles exporting the same package

Posted by Dmitry Skavish <sk...@gmail.com>.
Thanks Craig!
I am curious as to why it is not supported. I don't see any technical
problems with, so it should be ideological. But if you think about it
forbidding split packages is very similar to supporting Require-Bundle which
is usually frowned upon. I mean if a package comes only from one bundle it
basically means that we have dependency on that bundle (although not by name
of the bundle).

On Wed, Aug 12, 2009 at 5:27 PM, <cr...@habuma.com> wrote:

>
> You've encountered a split-packages problem. That is, while multiple
> bundles can export a package, a bundle can only import from one of them.
>
> In general, split-packages are a bad thing and break modularization. But,
> they are a reality and so there are a few ways to deal with them.
>
> I hesitate to suggest it, but Require-Bundle is one way...instead of
> importing the package, require the whole bundle. But use Require-Bundle
> very carefully, as it creates an undesirable bundle-to-bundle coupling.
>
> Another way I've dealt with it is to embed one bundle in the other
> (actually, the embedded one doesn't even have to be a bundle...a plain JAR
> will work). Be sure to put the embedded JAR in the outer bundle's
> Bundle-ClassPath. Then, when the outer bundle exports the package, the
> entire package will be exported (from both JARs). This is especially
> useful if the embedded JAR file is only useful within the context of the
> bundle it is embedded in. For example, I did with with Lucene and Compass.
> Both export some of the same Lucene packages. So, I embedded Lucene within
> a Compass bundle because I wasn't planning on using Lucene without
> Compass.
>
> Others on this list may have other suggestions, but these are the two I've
> used.
>
>
> > Hi,
> > So I have this case when I have two (or more) bundles exporting the same
> > package, but different classes in them and I have another bundle which is
> > importing classes from this package. The problem is that I am getting an
> > error saying that some classes could not be found, i.e. classes from this
> > common package. It seems as though the importing is possible only from
> one
> > of the bundles. Importing the same package in those bundles in a manifest
> > does not help.
> >
> > I am using google guice and basically the error is originated in guice
> > when
> > it tries to inject one of those imported classes. I am suspecting that it
> > has something to do with it, probably proxies guice creates or something
> > like that.
> >
> > Does anybody know what I am talking about here? Any solutions? Bridge
> > classloaders maybe?
> >
> > Thanks!
> >
> > --
> > Dmitry Skavish
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>


-- 
Dmitry Skavish

Re: two bundles exporting the same package

Posted by cr...@habuma.com.
You've encountered a split-packages problem. That is, while multiple
bundles can export a package, a bundle can only import from one of them.

In general, split-packages are a bad thing and break modularization. But,
they are a reality and so there are a few ways to deal with them.

I hesitate to suggest it, but Require-Bundle is one way...instead of
importing the package, require the whole bundle. But use Require-Bundle
very carefully, as it creates an undesirable bundle-to-bundle coupling.

Another way I've dealt with it is to embed one bundle in the other
(actually, the embedded one doesn't even have to be a bundle...a plain JAR
will work). Be sure to put the embedded JAR in the outer bundle's
Bundle-ClassPath. Then, when the outer bundle exports the package, the
entire package will be exported (from both JARs). This is especially
useful if the embedded JAR file is only useful within the context of the
bundle it is embedded in. For example, I did with with Lucene and Compass.
Both export some of the same Lucene packages. So, I embedded Lucene within
a Compass bundle because I wasn't planning on using Lucene without
Compass.

Others on this list may have other suggestions, but these are the two I've
used.


> Hi,
> So I have this case when I have two (or more) bundles exporting the same
> package, but different classes in them and I have another bundle which is
> importing classes from this package. The problem is that I am getting an
> error saying that some classes could not be found, i.e. classes from this
> common package. It seems as though the importing is possible only from one
> of the bundles. Importing the same package in those bundles in a manifest
> does not help.
>
> I am using google guice and basically the error is originated in guice
> when
> it tries to inject one of those imported classes. I am suspecting that it
> has something to do with it, probably proxies guice creates or something
> like that.
>
> Does anybody know what I am talking about here? Any solutions? Bridge
> classloaders maybe?
>
> Thanks!
>
> --
> Dmitry Skavish
>


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org