Proposal for altering Jemmy packaging

Tue Feb 19 18:44:14 UTC 2019

> On Feb 19, 2019, at 10:39 AM, Patrick Reinhart <patrick at reini.net> wrote:
> 
> Hi everyone,
> 
> As soon as the commit is done (having the new version), I will publish a
> new release to Maven Central…

May be wait a bit with that.

I would like to have this in a branch first.

Once it is there, I would see what, if any, changes need to be done in JemmyFX (which is not co-located) and if it is possible to run some JavaFX tests.
Also, and, as Marcus has said, JMC tests need to be run.

Once we sure everything works with a reasonable amount of updates, I will push it on trunk.

Shura

> 
> -Patrick
> 
> 
> Am 19.02.19 um 19:26 schrieb Alexandre (Shura) Iline:
>> Thank you!
>> 
>> I will take a look and push it into a branch when it is ready.
>> 
>> Shura
>> 
>> 
>> 
>>> On Feb 19, 2019, at 9:09 AM, Jie Kang <jkang at redhat.com> wrote:
>>> 
>>> On Tue, Feb 19, 2019 at 10: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}
>>> Ah, the maven-bundle-plugin was a local addition for testing with JMC
>>> that isn't necessary; sorry about that. I will remove it along with
>>> any other forthcoming suggestions
>>> 
>>>> 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
>>>>> 
>>>>> 
>>>>> 
> 
> 