Proposal for altering Jemmy packaging

Marcus Hirt marcus.hirt at datadoghq.com
Thu May 30 14:10:38 UTC 2019


Guru,

Any objections?

Kind regards,
Marcus

On Thu, 30 May 2019 at 16:00, Jie Kang <jkang at redhat.com> wrote:

> Hi,
>
> It has been quite a while; has the status here changed?
>
>
> Regards,
>
> On Thu, Mar 28, 2019 at 2:43 PM Marcus Hirt <marcus.hirt at datadoghq.com>
> wrote:
> >
> > 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
> >> >>>>>
> >> >>>>>
> >> >>>>>
> >> >>>>>
> >> >>>>>
> >> >>>>>
> >> >>>
> >> >>
> >> >
> >>
>


More information about the jemmy-dev mailing list