Proposal for altering Jemmy packaging

[Patrick Reinhart]

Hi everyone,

As soon as the commit is done (having the new version), I will publish a
new release to Maven Central...

-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
>>>>
>>>>
>>>>