Proposal for altering Jemmy packaging

Thu Mar 28 18:43:29 UTC 2019

I believe this is fine, but including Guru to make sure. Guru, any
objections?

Kind regards,
Marcus

On Thu, Mar 28, 2019 at 5:51 PM Alexandre (Shura) Iline <
alexandre.iline at oracle.com> wrote:

> Sorry, I was away for two weeks …
>
> Marcus, I still need your confirmation that it is OK to push that on trunk.
>
> Shura
>
> > On Mar 12, 2019, at 8:45 AM, Alexandre (Shura) Iline <
> alexandre.iline at oracle.com> wrote:
> >
> > I am including Marcus to comment on behalf of JMC.
> >
> >> On Mar 6, 2019, at 6:10 PM, Alexandre (Shura) Iline <
> alexandre.iline at oracle.com> wrote:
> >>
> >> Hi.
> >>
> >> I have created a bug to track this [1] and uploaded the patch [2].
> >>
> >> I also have discovered that
> >> 1. It is hard to create a branch without loosing some of the other
> openjdk services. I would need to care a “sandbox” repo. I am prepared to
> do that, however see #2.
> >> 2. JemmyFX is not, presently, used. There are plans to revive that, but
> for now it is OK to introduce incompatible changes to Jemmy v3. I have
> created a bug to track JemmyFX changes [3].
> >>
> >> As JemmyFX is not currently a blocker for this integration, the only
> other major usage of Jemmy v3 is JemmySWT. If the refactoring is easy for
> JemmySWT tests then, perhaps, we can just integrate on trunk.
> >>
> >> Can somebody confirm that integrating on trunk is be acceptable for JMC
> tests refactoring?
> >>
> >> Shura
> >>
> >> [1] https://bugs.openjdk.java.net/browse/CODETOOLS-7902419
> >> [2] http://cr.openjdk.java.net/~shurailine/7902419/webrev.00/ <
> http://cr.openjdk.java.net/~shurailine/7902419/webrev.00/>
> >> [3] https://bugs.openjdk.java.net/browse/JDK-8220263
> >>
> >>> On Mar 4, 2019, at 11:00 AM, Alexandre (Shura) Iline <
> alexandre.iline at oracle.com> wrote:
> >>>
> >>> 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
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>
> >>
> >
>
>