Proposal for altering Jemmy packaging

[Jie Kang]

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