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
