felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stuart McCulloch" <stuart.mccull...@jayway.net>
Subject Re: [maven-bundle-plugin] Some ignore-package and class level code inspection
Date Fri, 10 Aug 2007 02:03:21 GMT
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 <stuart.mcculloch@jayway.net> wrote:
>
> On 10/08/07, Karl Pauls <karlpauls@gmail.com> 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 <kismet@interfree.it> wrote:
> > > 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,
> > > >>>>
> > > [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
> > karlpauls@gmail.com
> >
>
>
>
> --
> Cheers, Stuart




-- 
Cheers, Stuart

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message