Proposal for altering Jemmy packaging

[Alexandre (Shura) Iline]

This looks good.

As I have find out, I need to request switching off jcheck to create new branch.

Let me do that and then I will push the code onto a branch.

Shura

> On Mar 1, 2019, at 10:57 AM, Jie Kang <jkang at redhat.com> wrote:
> 
> Hi Shura,
> 
> Please find attached a patch that:
> 
> a) renames SWT packages from org.jemmy.* -> org.jemmy.swt.*
> b) renames AWT packages from org.jemmy.* -> org.jemmy.*.awt
> c) fixes one maven warnings using ${project.version.class} instead of the
> deprecated ${version.class}
> d) updates project version to 2.0.0
> 
> How does it look?
> 
> 
> Regards,
> 
> On Fri, Feb 22, 2019 at 6:58 PM Alexandre (Shura) Iline
> <alexandre.iline at oracle.com> wrote:
>> 
>> 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,
>> 
>> 
>> 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-1.patch
Type: text/x-patch
Size: 58305 bytes
Desc: not available
URL: <https://mail.openjdk.java.net/pipermail/jemmy-dev/attachments/20190304/fb20fa53/jemmy-package-update-1-0001.patch>
-------------- next part --------------