Proposal for altering Jemmy packaging

[Jie Kang]

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
>
>
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jemmy-package-update.patch
Type: text/x-patch
Size: 61345 bytes
Desc: not available
URL: <https://mail.openjdk.java.net/pipermail/jemmy-dev/attachments/20190219/c9f3570a/jemmy-package-update-0001.patch>