You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by Stefano Lenzi <ki...@interfree.it> on 2007/08/08 13:50:24 UTC
[maven-bundle-plugin] Some ignore-package and class level code
inspection
Hi All,
I would like to speak about the maven-bundle-plugin.
Q.1 - There is a way to say to the plugin to ignore some packages?
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
Re: [maven-bundle-plugin] Some ignore-package and class level code inspection
Posted by Karl Pauls <ka...@gmail.com>.
On 8/10/07, Stuart McCulloch <st...@jayway.net> wrote:
> On 10/08/07, Karl Pauls <ka...@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)
Excellent :-)
> regards,
> >
> > Karl
> >
> > On 8/9/07, Stefano Lenzi <ki...@interfree.it> wrote:
> > > Stuart McCulloch wrote:
> > > > On 09/08/07, Stefano Lenzi <ki...@interfree.it> wrote:
> > > >> Stuart McCulloch wrote:
> > > >>> On 08/08/07, Stefano Lenzi <ki...@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
>
--
Karl Pauls
karlpauls@gmail.com
Re: [maven-bundle-plugin] Some ignore-package and class level code inspection
Posted by Stuart McCulloch <st...@jayway.net>.
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 <st...@jayway.net> wrote:
>
> On 10/08/07, Karl Pauls <ka...@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 <ki...@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 <ki...@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
Re: [maven-bundle-plugin] Some ignore-package and class level code inspection
Posted by Stuart McCulloch <st...@jayway.net>.
On 10/08/07, Karl Pauls <ka...@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 <ki...@interfree.it> wrote:
> > Stuart McCulloch wrote:
> > > On 09/08/07, Stefano Lenzi <ki...@interfree.it> wrote:
> > >> Stuart McCulloch wrote:
> > >>> On 08/08/07, Stefano Lenzi <ki...@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
Re: [maven-bundle-plugin] Some ignore-package and class level code inspection
Posted by Karl Pauls <ka...@gmail.com>.
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 <ki...@interfree.it> wrote:
> Stuart McCulloch wrote:
> > On 09/08/07, Stefano Lenzi <ki...@interfree.it> wrote:
> >> Stuart McCulloch wrote:
> >>> On 08/08/07, Stefano Lenzi <ki...@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
Re: [maven-bundle-plugin] Some ignore-package and class level code
inspection
Posted by Stefano Lenzi <ki...@interfree.it>.
Stuart McCulloch wrote:
> On 09/08/07, Stefano Lenzi <ki...@interfree.it> wrote:
>> Stuart McCulloch wrote:
>>> On 08/08/07, Stefano Lenzi <ki...@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 ;)
Re: [maven-bundle-plugin] Some ignore-package and class level code inspection
Posted by Stuart McCulloch <st...@jayway.net>.
On 09/08/07, Stefano Lenzi <ki...@interfree.it> wrote:
>
> Stuart McCulloch wrote:
> > On 08/08/07, Stefano Lenzi <ki...@interfree.it> wrote:
> >> Hi All,
> >>
> >> I would like to speak about the maven-bundle-plugin.
> >>
> >> Q.1 - There is a way to say to the plugin to ignore some packages?
> >
> >
> > Yes - you can add negative instructions to both Import-Package and
> > Export-Package, to override the automatic processing, for example:
> >
> > <Import-Package>!foo.bar, *</Import-Package>
> >
> > would avoid importing the foo.bar package, even if it was required.
> >
> > Basically, any directives you can give to BND can be used with the
> > bundle-plugin - for a good overview of the directives, please read:
> >
> > http://aqute.biz/Code/Bnd
> >
> > 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
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.
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
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.
(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... )
--
Cheers, Stuart
Re: [maven-bundle-plugin] Some ignore-package and class level code
inspection
Posted by Stefano Lenzi <ki...@interfree.it>.
Stuart McCulloch wrote:
> On 08/08/07, Stefano Lenzi <ki...@interfree.it> wrote:
>> Hi All,
>>
>> I would like to speak about the maven-bundle-plugin.
>>
>> Q.1 - There is a way to say to the plugin to ignore some packages?
>
>
> Yes - you can add negative instructions to both Import-Package and
> Export-Package, to override the automatic processing, for example:
>
> <Import-Package>!foo.bar, *</Import-Package>
>
> would avoid importing the foo.bar package, even if it was required.
>
> Basically, any directives you can give to BND can be used with the
> bundle-plugin - for a good overview of the directives, please read:
>
> http://aqute.biz/Code/Bnd
>
> 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.
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?
>
> 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
>>
>
>
>
Re: [maven-bundle-plugin] Some ignore-package and class level code inspection
Posted by Stuart McCulloch <st...@jayway.net>.
On 08/08/07, Stefano Lenzi <ki...@interfree.it> wrote:
>
> Hi All,
>
> I would like to speak about the maven-bundle-plugin.
>
> Q.1 - There is a way to say to the plugin to ignore some packages?
Yes - you can add negative instructions to both Import-Package and
Export-Package, to override the automatic processing, for example:
<Import-Package>!foo.bar, *</Import-Package>
would avoid importing the foo.bar package, even if it was required.
Basically, any directives you can give to BND can be used with the
bundle-plugin - for a good overview of the directives, please read:
http://aqute.biz/Code/Bnd
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.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
>
--
Cheers, Stuart