Proposal for altering Jemmy packaging

[Marcus Hirt]

Hi Jie,

I think it looks good, but I just took a cursory look. Shura, 
what do you think? Also, Shura, can you please help get the 
new repo for this work going?

Kind regards,
Marcus

On 2019-02-19, 16:48, "Jie Kang" <jkang at redhat.com> wrote:

    Hello Shura, Marcus,
    
    I have prepared a prototype patch that:
    
    a) renames AWT packages from org.jemmy.* -> org.jemmy.awt.*
    b) renames SWT packages from org.jemmy.* -> org.jemmy.swt.*
    c) fixes two maven warnings, adding an explicit version for
    maven-bundle-plugin and using ${project.version.class} instead of the
    deprecated ${version.class}
    d) updates version to 2.0.0
    
    I'm not an author or committer so I have attached the patch file to
    this e-mail. Please let me know what you think! I'm very willing to
    address any direction you have, e.g. name of packages, what version to
    update to, etc.
    
    I am currently testing this with JMC on Fedora 29. Note that on Fedora
    29, X11 with i3 as the window manager, I the jemmy project tests fail
    on both HEAD and HEAD plus this patch. Is there some special setup I
    need to have? The failed tests are:
    
    [ERROR]   ScreenImageTest.compareFull:100 compareFull failed, see
    positive.png and positive_diff.png for details
    [ERROR]   RobotDriverTest.testDragNDrop:431 » TimeoutExpired State
    'org.jemmy.input.Robo...
    
    
    Regards,
    
    
    On Thu, Feb 14, 2019 at 4:30 AM Marcus Hirt <marcus.hirt at oracle.com> wrote:
    >
    > 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
    >
    >
    >
    >