...

In it's present form it mangen is simple, reasonably fast, and usable. Ideas on some of the more significant areas where it could be enhanced or improved are described in the sections below.

If you look at the source code, don't be surprised if you also find a few //TODO markers. These don't necessarily signify areas which don't work, just thoughts on how things could be done differently or perhaps better as the code was being written.

Rules to allow better handling of duplicate exports

At present, duplicate exports are handled in the ResolveImportsToExports rule and are simply flagged with a =*** WARNING ***= message. The first occurence of a duplicate export will be picked for inclusion and all others will be removed. This may not be the desired behaviour. This can partially be solved with the current AttributeStamp rule to ensure that if several exports represent different package versions they will not be flagged as duplicates. However, where there are multiple possible exporters of the same package version additional rule handling would be beneficial to allow a given bundle to be specified as the exporter.

Auto-handling of inner JARs

At present, mangen will only process inner JARs that are specified in a valid Bundle-ClassPath attribute in the existing JAR Manifest. It would be perfectly feasible to have an option to tell mangen to scan any inner JAR it finds, and also to automatically generate a valid Bundle-ClassPath for each inner JAR when updating the bundle's JAR.

Include a ManifestReport

Make one of the reports (possibly the default) a report which basically shows what the Manifest would look like for each processed JAR. Also for the UpdateBundles rule change the default name to be bundle.new.jar.

...

Manifest-less usage

With auto-handling of inner JARs and the existing functionality it would be possible to make mangen generate the essential import, export, and classpath headers of an OSGi manifest completely automatically. Although an existing manifest can provide additional descriptive headers, these are by no means essential for basic OSGi operation.

Online usage within an OSGi environment

Extending the concept of Manifest-less usage comes an interesting possibility that a specific OSGi platform such as Oscar could be extended to load any JAR and automatically 'fix-up' a usable Manifest. This would require internal access/knowledge of the specific platform's implementation since the existing standard OSGi API would not supply sufficient details and access to the set of loaded bundle JARs. Additionally, it would probably need to be a "multi-step" process since until a largely complete set of bundle JARs were loaded it may not be possible to resolve all imports and exports. This perhaps implies some form of platform extension to allow a set of JARs to be passed to some form of "pre-load" mechanism capable of resolving their imports and exports within the JAR set, and possibly from existing loaded bundle JARs or even an external OBR.

No current support for Dynamic-ImportPackage

Current processing and rules do not parse or use any Dynamic-ImportPackage attributes present. At the least, it would probably be useful to have the ability to not include anything in Import-Package which matches a dynamic import attribute. Beyond this, there may be benefit in additional processing to make fuller use of dynamic imports where the user requires it.

Read-only JARs for package resolution

At present all bundle JARs are considered "updateable", there is no way to indicate that certain JARs should be read but not modified. Where this may be useful is to provide certain JARs purely for resolution of package imports and exports, such as via the ResolveImportsToExports rule, without having mangen modify them.

OSGi R4 enhancements

The specification for OSGi R4 is still under development, although some early information has been made available on possible extensions to enhance package import and export controls and dependency management. As these start to become ratified, mangen will need to be enhanced to support them. Some possible areas are:

• enhanced handling of package "attributes" and "directives" e.g. support for a possible "uses" attribute
• support for partial package imports and exports e.g. via class name regex patterns
• include way to generate a valid Oscar org.osgi.framework.system.packages property setting for all referenced system packages, to make it easy to determine the required value for Oscar's properties

Deeper class processing

It's possible that mangen could go deeper into the scanned classes to provide enhanced functionality e.g.

...

Most mangen enhancement ideas have now been created as issues in the Apache JIRA list.

Those which are more speculative have been left below.

Online usage within an OSGi environment

Extending the concept of Manifest-less usage comes an interesting possibility that a specific OSGi platform such as Oscar could be extended to load any JAR and automatically 'fix-up' a usable Manifest. This would require internal access/knowledge of the specific platform's implementation since the existing standard OSGi API would not supply sufficient details and access to the set of loaded bundle JARs. Additionally, it would probably need to be a "multi-step" process since until a largely complete set of bundle JARs were loaded it may not be possible to resolve all imports and exports. This perhaps implies some form of platform extension to allow a set of JARs to be passed to some form of "pre-load" mechanism capable of resolving their imports and exports within the JAR set, and possibly from existing loaded bundle JARs or even an external OBR.

...

Acknowledgements

Ascert is pleased to acknowledge the following projects, organisations and individuals whose tools have been used in the creation of this software:

...