Proposal for altering Jemmy packaging

Jie Kang jkang at
Mon Jan 28 15:48:11 UTC 2019

Hi all,

I propose to change the Jemmy packaging in one of two ways.

1. Re-arrange package names such that split package does not occur
2. Provide Jemmy uberjar containing all classes in one jar

The reason for this proposal is to prevent the split-package issue
encountered in OSGi with the current Jemmy structure. As a concrete
example, the package 'org.jemmy.image' is present in both
'jemmy-awt-input' and 'jemmy-core' with different classes. When both
of these jars are loaded by OSGi, only one can be resolved for
packages under 'org.jemmy.image'. In the case of JDK Mission Control,
this results in a Class Not Found Exception at run time for
org.jemmy.image.ImageComparator. This class is available in
jemmy-core, but the OSGi system has selected 'jemmy-awt-input' as the
provider for classes under 'org.jemmy.image'.

To resolve this, the package names could be made unique between the
jars produced by the Jemmy project. For example, the jemmy-awt-input
classes could be placed under 'org.jemmy.awt.*', and the core classes
could be under 'org.jemmy.core.*'. This would be similar to the
existing 'org.jemmy.browser.*' package space that only jemmy-browser
provides. Granted this would be a breaking change it would result in a
cleaner package structure for OSGi systems.

Alternatively, the Jemmy project could provide an uberjar, containing
all the classes of jemmy-awt-input, jemmy-core, etc. such that this
single jar can be loaded by OSGi to resolve all jemmy classes from.

By resolving this packaging issue, OSGI applications such as JDK
Mission Control will be able to use the Jemmy JARs supplied through
Maven as OSGi bundles with minimal manipulation. Currently we ask
users to download these manually and have all the classes from the
different jemmy jars included into a bundle of our own at build time.

I would be gladly willing to supply patches for either of these
solutions. Please let me know your thoughts.


Jie Kang
Software Engineer, Red Hat

More information about the jemmy-dev mailing list