Stuart McCulloch wrote:
On 09/08/07, Stefano Lenzi <[EMAIL PROTECTED]> wrote:
Stuart McCulloch wrote:
On 08/08/07, Stefano Lenzi <[EMAIL PROTECTED]> wrote:
Hi All,
[cu]
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:
org.cybergarage.xml.parser.JaxpParser
org.cybergarage.xml.parser.kXML2Parser
org.cybergarage.xml.parser.XercesParser
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.
Ciao,
Stefano "Kismet" Lenzi
P.S.: If you want you may cat some of the e-mail thread ;)
