Proposal for altering Jemmy packaging

[Marcus Hirt]

Hi Shura,

1. Agreed, version bump needed.
2. Sounds like an absolute must.
3. A good idea; can you help set up that branch?
4. I know that the JMC tests will, at the very least, exercise the SWT bit.

Thanks for the help!

Kind regards,
Marcus


On 2019-02-14, 04:07, "jemmy-dev on behalf of Alexandre (Shura) Iline" <jemmy-dev-bounces at openjdk.java.net on behalf of alexandre.iline at oracle.com> wrote:

    Hi.
    
    The problem is definitely there to address! Thank you! 
    
    In addition to the reasons you have provided, it will help when we finally get around turning this projects to modules.
    
    Full list of package name conflicts is this:
    org/jemmy/image is in JemmyAWTInput, JemmyCore
    org/jemmy/input is in JemmySWT, JemmyAWTInput, JemmyCore
    org/jemmy/operators is in JemmyAWTInput, JemmyCore
    
    
    I am all for renaming the packages, actually. But …
    
    1. It is an incompatible change, so a major bump in version should be done
    2. The code needs to be checked for hardcodes. I, for example, remember that there was a hardcode of "org/jemmy/operators” somewhere in JemmyFX, at some moment. I do not immediately see hardcodes of that package in Jemmy v3 code, but checking for others should still be done.
    3. Can we do it in a branch?
    4. Of course all internal tests should pass, but it would also help to know that some other tests pass, such as some using JemmySWT and JemmyFX.
    
    Shura
    
    > On Jan 28, 2019, at 7:48 AM, Jie Kang <jkang at redhat.com> wrote:
    > 
    > 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
    > or
    > 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.
    > 
    > 
    > Thanks,
    > 
    > Jie Kang
    > Software Engineer, Red Hat