Marcel and I have been thinking about using an obfuscator/optimizer for doing what you are describing (i.e., only include the really needed classes in a bundle and throw out all the not needed one). This would allow to further optimize the needed classes as well if needed (i.e., have the obfuscator throw out not needed methods etc.).
I think it would be very interesting if somebody could add obfuscator/optimizer support to the plugin. Unfortunately, my time is rather limited at the moment :-(. A good free obfuscator would be ProGuard (http://proguard.sourceforge.net) but that one is GPL iirc. Anybody knows about a good, free, ALv2 compatible java obfuscator/optimizer? regards, Karl On 8/9/07, Stefano Lenzi <[EMAIL PROTECTED]> wrote: > 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 ;) > -- Karl Pauls [EMAIL PROTECTED]
