Proposal for altering Jemmy packaging

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