I've raised https://issues.apache.org/jira/browse/FELIX-336 to look into this
feel free to contribute ideas, patches or even opinions on whether the bundle-plugin is the right place for this feature (compared to putting it in a separate maven plugin). On 10/08/07, Stuart McCulloch <[EMAIL PROTECTED]> wrote: > > On 10/08/07, Karl Pauls <[EMAIL PROTECTED]> wrote: > > > > 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? > > > the minjar maven2 plugin is ALv2: > > http://mojo.codehaus.org/minijar-maven-plugin/usage.html > http://mojo.codehaus.org/minijar-maven-plugin/faq.html > > which you could use to shrink existing bundles > (afaik no obfuscation - but it can do relocation) > > 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] > > > > > > -- > Cheers, Stuart -- Cheers, Stuart
