felix-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dileepa Jayakody <dile...@wso2.com>
Subject Re: Problems when removing dependency jars from <Embed-Dependency> section
Date Tue, 06 Dec 2011 06:26:29 GMT
Thanks a lot for the detailed explanation Stuart. :)

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

> On 21 October 2011 08:24, Dileepa Jayakody <dileepa@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

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