Fwd: Proposal for altering Jemmy packaging

Jie Kang jkang at redhat.com
Thu Feb 28 22:10:54 UTC 2019

Forwarding to jemmy-dev. Sorry for missing that CC.

---------- Forwarded message ---------
From: Jie Kang <jkang at redhat.com>
Date: Thu, Feb 28, 2019 at 5:08 PM
Subject: Re: Proposal for altering Jemmy packaging

Hi Shura

Your explanation and suggestion makes sense to me; preventing a
conflict with a possible AWT/JemmyAWT module is worthwhile.

I would like to clarify the prefix 'test' in the package names you
listed of 'test.org.jemmy...'. Was this prefix intended to be
included? I think the packages are org.jemmy... and there are
corresponding src and test folders for the respective classes.

For a non-conflicting naming scheme, appending awt afterwards as you
suggested would solve the problem, however, suffixing the sub packages
of input/image/operators is a little strange in my opinion. How does:

org.jemmy.* -> org.jemmy.awtinput.*

sound to you? Let me know which you think is better and I will prepare
a revised patch for your consideration.

Apologies for the delay,

> 23 feb. 2019 kl. 00:57 skrev Alexandre (Shura) Iline <alexandre.iline at oracle.com>:
> Jie,
> Currently what you are suggesting is to rename test.org.jemmy.* packages to test.org.jemmy.awt.*. That, of course, resolves the package among conflict but I would like to suggest a slightly different renaming scheme for JemmyAWTInput.
> That projects does not provide Jemmy v3 support for AWT. For that there was AWT/JemmyAWT. It was a proof of concept, there is not much use to it because there is Jemmy v2. I can still recover it, if needed. Class hierarchy of JemmyAWT project would, logically, start with org.jemmy.awt.
> JemmyAWTInput, then, is an implementation, with the help of AWT, of a few abstractions from JemmyCore. There are implementations for input and operations with images. This implementations could be used in tests for SWT UI or JavaFX UI or anything else in an environment supported by AWT.
> What I am therefore suggesting is this refactoring for classes in JemmyAWTInput:
> test.org.jemmy.input -> test.org.jemmy.input.awt
> test.org.jemmy.image -> test.org.jemmy.image.awt
> test.org.jemmy.operators -> test.org.jemmy.operators.awt
> This is both more logical and will help to avoid package conflict with JemmyAWT, should that need to be re-introduced.
> Shura
> On Feb 19, 2019, at 7:48 AM, 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,

More information about the jemmy-dev mailing list