| Introduction: This is a light weight tool developed in leisure time to analyse OSGi metadata of various bundles in a glassfish distribution. If you have questions, comments, please contact Sahoo & Siva. Given below is a snapshot of the report generated by the tool against GlassFish 4.0 trunk (SVN revision : 55315) . GROSS STATISTICS Total number of bundles in this repository: 275 Total number of wires = 6393 Total number of exported packages = 2252 Total number of duplicate-packages = 13 Total number of unused-packages = 1281 Detailed Report For details, refer to the individual files mentioned below: 1) bundles.xml: For each bundle, it contains symbolic name, exported package details and imported package details. Exported packages are further divided into two segments: used and unused. If an exported package is not imported by any other module than the exporter, it is considered an unused package. 2) duplicate.txt: Contains packages that are duplicated in various bundles. 3) wires.xml: Tries to match importers with exporters. There is a wires.xsl as well. So, if you open this file in a browser, you will get a nice tabular report. The wiring details may not be totally correct, because I just try to match package names without considering version constraint or attribute matching. 4) unused.txt: Contains list of exported packages that are never imported by anyone other the exporting bundle. We have quite a large number of such packages (do a wc on the file to know the number). As I write, almost two thirds of our exported packages are unused. What are the issues 0) Too many wires (i.e., dependencies among modules) 1) Too many unused packages Each module owner has to update either osgi.bundle or pom.xml or some other configuration file as per their build environment to remove unnecessary packages being exported. Look at the <used> segment in bundles.xml file to find out which packages are really needed as per OSGi package metadata. 2) Some bundles export package without any version The following command will show all such packages: grep version=0.0.0 bundles.xml It is OK to export packages with no version if you really don't know what should be the version of the package. Except for javax APIs, I don't see any reason for not specifying a version while exporting a package. For javax packages, it is a bigger problem and attempts are being made to standardise their OSGi version numbers. 3) Some bundles import without any version range The following command will show all such packages: grep "0.0.0, infinity" bundles.xml The result will include JRE packages as well, so module owners have to look at it more carefully. e.g., metro imports jax-ws like this, which is clearly wrong, because metro needs jax-ws 2.1.2. It can lead to bugs. See issue # 4) Duplicate packages Same package appears in multiple bundles. Unless there is a good reason to do so, avoid it. Exception List The tool will be modified to accept an exception list, because there are some packages which are needed to be exported even though they are not imported by any module in modules/. Instead those packages are either expected to be imported by some foreign bundles or imported via DynamicImport-Package mechanism (typically by application class loader). e.g., some of the EJB container APIs are needed to be exported because the generated EJB classes refer to them. Same is true for jsp container as well. Module owners are expected to update this Exceptionlist so that when the tool is capable of accepting such a list, it will not report them as something to take care of. How to generate the report yourself: svn co https://svn.java.net/svn/hk2~svn/trunk/hk2/ cd ./hk2/dependency-verifier/ mvn clean install ./run-package-analyser.sh path-to-glassfish-modules-directory bundles.xml wires.xml duplicate.txt unused.txt Maven Plugin The tool is already part of hk2-maven-plugin. The goal name is analyse-packages. To invoke the maven plugin, you need to use one of the distribution (e.g., nucleus/web/glassfish) pom.xml. e.g., mvn -f main/appserver/distributions/glassfish/pom.xml hk2:analyse-packages Once we integrate HK2 version 1.0.13 in v3, the -D properties in the above command will not be needed. Currently the maven plugin has some limitations. I am working on it. Associated bugs: See issue 11782 and its dependencies. TODO 1. Accept an exception list (Thanks to Tim for bringing it up). 2. Change the maven plugin to generate reports similar to command line utility. 3. Change the maven plugin to analyse bundles that are actually distributed. Currently the maven plugin analyses all bundles that are part of the maven project. Author: Comments/Suggestions If you have any comments or suggestions about this page or the tool, please contact me (Sahoo). 
Bundles.html.pdf (application/pdf)
duplicate.pdf (application/pdf)
unused.pdf (application/pdf)
wires.html.pdf (application/pdf)
|
