You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@felix.apache.org by Stuart McCulloch <mc...@gmail.com> on 2011/12/02 23:44:47 UTC

Re: Problems when removing dependency jars from section

On 21 October 2011 08:24, Dileepa Jayakody <di...@wso2.com> wrote:

> Hi
> I'm working on a project which requires identification and removal of
> unused
> jar dependencies from the osgi bundles to make them leaner.
> Maven bundle-plugin is used to create the bundle and I'm using a tool
> called
> JBoss tattletale <http://www.jboss.org/tattletale> to identify unused
> jars,
> duplicated jars in the project/bundle. However there are some gray areas I
> need to be clear about; please give me some suggestions/comments on the
> following questions.
>
> Suppose I'm exporting a package foo.*; from a dependency jar (A.jar) in the
> bundle, as a result all the classes of foo pckg are in-lined/added to the
> bundle classpath. Suppose there's a class foo.Bar.java in th pckg which
> imports a class from B.jar, and I remove B.jar (which is assumed to be an
> unused embedded dependency as per my tool to identify unused jars).
> Now the bundle doesn't have B.jar in it's class-path and it still exports
> foo.* pckg in A.jar in the bundle.
>
> My 1st question is, will the maven bundle plugin throw any compilation
> errors because the transitive dependency of foo.Bar class is not satisfied
> as B.jar is no longer in the bundle classpath, or will it compile and
> export
> pckg foo.* without any compilation error, which may result in a run-time
> exception when trying to load foo.Bar class in the bundle at runtime?
>

The maven-bundle-plugin doesn't do any compilation, that's done by the
maven-compiler-plugin. But if your compiled code uses a class (say x.y.Z
from B.jar) and doesn't embed/inline it then it will add the package
containing that class (x.y) to the generated Import-Package statement in
the manifest. Of course you could override the generated Import-Package in
the instructions, but bnd will try to warn you if your bundle references a
package that isn't imported.

Now if you tried to install the bundle with Import-Package: x.y on an OSGi
framework and no other bundle exported package x.y you'd get a runtime
exception warning about the unsatisfied import constraint. This still
doesn't stop you from marking packages as optional or explicitly excluding
them from Import-Package - in which case your bundle would install, and
you'd get a class exception if anyone tried to use foo.Bar. But this
shouldn't happen when using the default instructions - this should only
happen when you explicitly told bnd that a package wasn't used when in fact
it is...

Will removing unused embedded dependencies from a bundle cause errors in
> cases like java reflexion used in the bundle ?(eg: Class.forName loading of
> a class which is removed from the bundle as a result of removing unused
> embedded dependencies)
>

AFAICT the tattletale plugin scans the bytecode to detect unused
dependencies, which is very similar to what bnd does when calculating the
difference between what's contained in the bundle and what's referenced
from the bundle (which gives you what should be imported). So in an ideal
world removing dependencies marked as unused by tattletale should not
affect the bundle. The main issue is reflection (as you mention above)
because the class name could be computed from the environment or some other
input and cannot be deduced just from the bytecode. In that case both
tattletale and bnd might not detect the reference and you'd end up with a
bundle that would install, but throw an exception at runtime.

Unfortunately there's no solution that can detect all possibilities - for
example, classloader.loadClass(System.getProperty("some.class.name")) - but
hopefully these cases are a) uncommon and b) already known by the developer
creating the bundle, in which case they can tweak the generated manifest
accordingly.

HTH

Thanks,
> --
> Dileepa Jayakody,
>



-- 
Cheers, Stuart

Re: Problems when removing dependency jars from section

Posted by Dileepa Jayakody <di...@wso2.com>.
Thanks a lot for the detailed explanation Stuart. :)

On Sat, Dec 3, 2011 at 4:14 AM, Stuart McCulloch <mc...@gmail.com> wrote:

> On 21 October 2011 08:24, Dileepa Jayakody <di...@wso2.com> wrote:
>
> > Hi
> > I'm working on a project which requires identification and removal of
> > unused
> > jar dependencies from the osgi bundles to make them leaner.
> > Maven bundle-plugin is used to create the bundle and I'm using a tool
> > called
> > JBoss tattletale <http://www.jboss.org/tattletale> to identify unused
> > jars,
> > duplicated jars in the project/bundle. However there are some gray areas
> I
> > need to be clear about; please give me some suggestions/comments on the
> > following questions.
> >
> > Suppose I'm exporting a package foo.*; from a dependency jar (A.jar) in
> the
> > bundle, as a result all the classes of foo pckg are in-lined/added to the
> > bundle classpath. Suppose there's a class foo.Bar.java in th pckg which
> > imports a class from B.jar, and I remove B.jar (which is assumed to be an
> > unused embedded dependency as per my tool to identify unused jars).
> > Now the bundle doesn't have B.jar in it's class-path and it still exports
> > foo.* pckg in A.jar in the bundle.
> >
> > My 1st question is, will the maven bundle plugin throw any compilation
> > errors because the transitive dependency of foo.Bar class is not
> satisfied
> > as B.jar is no longer in the bundle classpath, or will it compile and
> > export
> > pckg foo.* without any compilation error, which may result in a run-time
> > exception when trying to load foo.Bar class in the bundle at runtime?
> >
>
> The maven-bundle-plugin doesn't do any compilation, that's done by the
> maven-compiler-plugin. But if your compiled code uses a class (say x.y.Z
> from B.jar) and doesn't embed/inline it then it will add the package
> containing that class (x.y) to the generated Import-Package statement in
> the manifest. Of course you could override the generated Import-Package in
> the instructions, but bnd will try to warn you if your bundle references a
> package that isn't imported.
>
> Now if you tried to install the bundle with Import-Package: x.y on an OSGi
> framework and no other bundle exported package x.y you'd get a runtime
> exception warning about the unsatisfied import constraint. This still
> doesn't stop you from marking packages as optional or explicitly excluding
> them from Import-Package - in which case your bundle would install, and
> you'd get a class exception if anyone tried to use foo.Bar. But this
> shouldn't happen when using the default instructions - this should only
> happen when you explicitly told bnd that a package wasn't used when in fact
> it is...
>
> Will removing unused embedded dependencies from a bundle cause errors in
> > cases like java reflexion used in the bundle ?(eg: Class.forName loading
> of
> > a class which is removed from the bundle as a result of removing unused
> > embedded dependencies)
> >
>
> AFAICT the tattletale plugin scans the bytecode to detect unused
> dependencies, which is very similar to what bnd does when calculating the
> difference between what's contained in the bundle and what's referenced
> from the bundle (which gives you what should be imported). So in an ideal
> world removing dependencies marked as unused by tattletale should not
> affect the bundle. The main issue is reflection (as you mention above)
> because the class name could be computed from the environment or some other
> input and cannot be deduced just from the bytecode. In that case both
> tattletale and bnd might not detect the reference and you'd end up with a
> bundle that would install, but throw an exception at runtime.
>
> Unfortunately there's no solution that can detect all possibilities - for
> example, classloader.loadClass(System.getProperty("some.class.name")) -
> but
> hopefully these cases are a) uncommon and b) already known by the developer
> creating the bundle, in which case they can tweak the generated manifest
> accordingly.
>
> HTH
>
> Thanks,
> > --
> > Dileepa Jayakody,
> >
>
>
>
> --
> Cheers, Stuart
>



-- 
Dileepa Jayakody,
Software Engineer, WSO2 Inc.
Lean . Enterprise . Middleware