felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Lenzi <kis...@interfree.it>
Subject Re: [maven-bundle-plugin] Some ignore-package and class level code inspection
Date Thu, 09 Aug 2007 16:44:15 GMT
Stuart McCulloch wrote:
> On 09/08/07, Stefano Lenzi <kismet@interfree.it> wrote:
>> Stuart McCulloch wrote:
>>> On 08/08/07, Stefano Lenzi <kismet@interfree.it> wrote:
>>>> Hi All,
>>> the thing to remember is the "pull-approach"... the BND tool uses
>>> Export-Package, Private-Package and Include-Resource to decide
>>> the contents of the bundle - it then analyzes the contents to find
>>> referred packages and applies the Import-Package rules.
>> I've read the documentation and it looks that there is no way to avoid
>> BND do add classes that are in packages that you import but that you
>> never use.
>> For example: A class inside a Bundle import uses the class a.b.Foo, and
>> it use the BND directive private-package in order to include such class
>> in the bundle classes. The package a.b contains also the classes:
>> a.b.Muo, a.b.Gal, so BND will add to the bundle all a.b.XXX classes even
>> if they are never referenced.
> ah... you mean split packages! ie. where bundle A and bundle B may
> contain different sets of classes from the same package namespace

Not really :S But thank you for the example now it's more clear to me 
how it works :)

> there has been some recent support for handling split packages in BND:
>    http://aqute.biz/Code/Bnd#export-package   (second part)
> but it is mostly to do with compiling against other bundles, where your
> bundle has the same internal package and you don't want to pull in the
> classes from the other bundle - in that case you'd use:
>    Export-Package= com.acme.internal.*;-split-package:=first
> which would mean only classes from your internal package would be
> included in the bundle, and none from other bundles on the classpath.
> So my question is: do you think that a class filter should be added to
>> maven-bundle-plugin or the bundle developer should achieve that in other
>> ways?
> such a filter would have to be added to the BND tool, maintained by
> Peter Kriens, as the bundle-plugin is not involved in this part of the
> bundling process.
> however, most people discourage the use of split packages because
> it makes the package notion more vague. If a package can be split
> into two or more conceptual parts, that would suggest they could be
> refactored into separate sub-packages.
> it is also very difficult to programmatically select the classes you may
> need from a given package, because they could be referenced only at
> runtime using reflection, etc.

The reflection will break the maven-bundle-plugin in any case even if 
you look only at package. Looking at package make only the process faster :)

> it is much safer to just include the whole package - which typically is
> only a fraction of the process space - if the package contents are really
> large then again that would suggest a need to refactor

In fact refactoring the package could make sense, but that applies only 
for package that can modify...

> also, if you only use a couple of classes from the package and are sure
> that in using these classes you don't need to import other packages used
> elsewhere in the package then you can use negative (ie. !) patterns to
> limit your imports to the ones that you know you need.

The problem occurs when the useless, never referenced classes, belong to 
the package that you use in part.

> (or mark them as optional...)
>>> I.1 - If there is no way to inform the plugin ignore some packages I
>>>> think would be very useful; because if (like in my case) a bundle
>>>> depends on a library that contains "too much code" there is no way to
>>>> avoid to satisfy all the "package requirement" by using the plugin.
>> More
>>>> in general I think would be nice to improve the plugin in order to have
>>>> a class grain level  source(binary) code inspection.
>>>> Ciao,
>>>> Stefano "Kismet" Lenzi
> PS. can you share your current use-case for requiring per-class filtering?
> I find it much easier to discuss options when there's a concrete example.
> ( ie. what package(s) are you having trouble including/importing... )

Sure no problem :)

Here is my use case:
the org.apache.felix.upnp.basedriver (not yet committed in my working 
copy) depends on the org.cybergarage.cyberlink:upnp-stack:1.8.0-SNAPSHOT 
artifact which contains a package with the following classes:
BTW, org.apache.felix.upnp.basedriver bundle references only the 
org.cybergarage.xml.parser.JaxpParser class but I can't find a way to 
avoid to put the all the org.cybergarage.xml.parser.* in the bundle 
generated by the maven-bundle-plugin.
If maven-bundle-plugin (in particular BND) do a analysis of all the 
referenced class then it will avoid to include all the "useless" class.

Stefano "Kismet" Lenzi

P.S.: If you want you may cat some of the e-mail thread ;)

View raw message