Thanks a lot for the detailed explanation Stuart. :) On Sat, Dec 3, 2011 at 4:14 AM, Stuart McCulloch <[email protected]> wrote:
> On 21 October 2011 08:24, Dileepa Jayakody <[email protected]> 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
