From marcus.hirt at oracle.com  Wed Feb 13 16:40:43 2019
From: marcus.hirt at oracle.com (Marcus Hirt)
Date: Wed, 13 Feb 2019 17:40:43 +0100
Subject: Proposal for altering Jemmy packaging
Message-ID: <7D329468-ED31-4888-8E73-804722CA0283@oracle.com>

Regarding Jie Kang's proposal, I think I?d prefer actually renaming the 
packages, even though that would mean breaking changes.

Shura, do you have any strong opinions regarding this?

Kind regards,
Marcus




From patrick at reini.net  Wed Feb 13 17:41:12 2019
From: patrick at reini.net (Patrick Reinhart)
Date: Wed, 13 Feb 2019 18:41:12 +0100
Subject: Proposal for altering Jemmy packaging
In-Reply-To: <7D329468-ED31-4888-8E73-804722CA0283@oracle.com>
References: <7D329468-ED31-4888-8E73-804722CA0283@oracle.com>
Message-ID: <2571635c-7c11-b197-9797-6e92abdec755@reini.net>

I got the similar idea though...

Sounds like a good plan to me...

-Patrick


Am 13.02.19 um 17:40 schrieb Marcus Hirt:
> Regarding Jie Kang's proposal, I think I?d prefer actually renaming the 
> packages, even though that would mean breaking changes.
>
> Shura, do you have any strong opinions regarding this?
>
> Kind regards,
> Marcus
>
>
>



From alexandre.iline at oracle.com  Thu Feb 14 03:06:49 2019
From: alexandre.iline at oracle.com (Alexandre (Shura) Iline)
Date: Wed, 13 Feb 2019 19:06:49 -0800
Subject: Proposal for altering Jemmy packaging
In-Reply-To: <CAEBeOco-o7x_iWt-++5ZrTrptpS7xyrcnr1eoyqeL4VGNVH8Vw@mail.gmail.com>
References: <CAEBeOco-o7x_iWt-++5ZrTrptpS7xyrcnr1eoyqeL4VGNVH8Vw@mail.gmail.com>
Message-ID: <4E02A3BF-9EE1-426B-BB3D-5CBC27DA6B6E@oracle.com>

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


From marcus.hirt at oracle.com  Thu Feb 14 09:30:05 2019
From: marcus.hirt at oracle.com (Marcus Hirt)
Date: Thu, 14 Feb 2019 10:30:05 +0100
Subject: Proposal for altering Jemmy packaging
In-Reply-To: <4E02A3BF-9EE1-426B-BB3D-5CBC27DA6B6E@oracle.com>
References: <CAEBeOco-o7x_iWt-++5ZrTrptpS7xyrcnr1eoyqeL4VGNVH8Vw@mail.gmail.com>
 <4E02A3BF-9EE1-426B-BB3D-5CBC27DA6B6E@oracle.com>
Message-ID: <D172A1E4-A3C8-481B-ACEF-3E176B660160@oracle.com>

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
    
    



From abdul.kolarkunnu at oracle.com  Fri Feb 15 10:56:53 2019
From: abdul.kolarkunnu at oracle.com (Muneer Kolarkunnu)
Date: Fri, 15 Feb 2019 10:56:53 +0000 (UTC)
Subject: RFR CODETOOLS-7902388: only one of the two should happen: either
 throw or calling Thread.interrupt()
Message-ID: <98008613-e0dc-4bf2-a272-374b5192abc4@default>

Hi All,

Please review fix for the bug : https://bugs.openjdk.java.net/browse/CODETOOLS-7902388 

Webrev : http://cr.openjdk.java.net/~akolarkunnu/7902388/webrev.00/ 

Description: Removed interrupt() invoke.

Regards,
Muneer

 

From alexandre.iline at oracle.com  Fri Feb 15 15:37:56 2019
From: alexandre.iline at oracle.com (Alexandre (Shura) Iline)
Date: Fri, 15 Feb 2019 07:37:56 -0800
Subject: RFR CODETOOLS-7902388: only one of the two should happen: either
 throw or calling Thread.interrupt()
In-Reply-To: <98008613-e0dc-4bf2-a272-374b5192abc4@default>
References: <98008613-e0dc-4bf2-a272-374b5192abc4@default>
Message-ID: <1EF05BE0-CA75-456D-925A-C9517CD5F767@oracle.com>

Muneer,

There are still extra parentheses, which is mentioned in the bug description.

Shura

> On Feb 15, 2019, at 2:56 AM, Muneer Kolarkunnu <abdul.kolarkunnu at oracle.com> wrote:
> 
> Hi All,
> 
> Please review fix for the bug : https://bugs.openjdk.java.net/browse/CODETOOLS-7902388 
> 
> Webrev : http://cr.openjdk.java.net/~akolarkunnu/7902388/webrev.00/ 
> 
> Description: Removed interrupt() invoke.
> 
> Regards,
> Muneer
> 
> 


From abdul.kolarkunnu at oracle.com  Fri Feb 15 20:14:42 2019
From: abdul.kolarkunnu at oracle.com (Muneer Kolarkunnu)
Date: Fri, 15 Feb 2019 12:14:42 -0800 (PST)
Subject: RFR CODETOOLS-7902388: only one of the two should happen: either
 throw or calling Thread.interrupt()
In-Reply-To: <1EF05BE0-CA75-456D-925A-C9517CD5F767@oracle.com>
References: <98008613-e0dc-4bf2-a272-374b5192abc4@default>
 <1EF05BE0-CA75-456D-925A-C9517CD5F767@oracle.com>
Message-ID: <b732fa58-af67-461c-a9f2-65b3ef836b2f@default>

Yes, I missed that.
Removed extra parentheses also.
New webrev: http://cr.openjdk.java.net/~akolarkunnu/7902388/webrev.01/ 

Regards,
Muneer

-----Original Message-----
From: Alexandre (Shura) Iline 
Sent: Friday, February 15, 2019 9:08 PM
To: Muneer Kolarkunnu <abdul.kolarkunnu at oracle.com>
Cc: jemmy-dev at openjdk.java.net
Subject: Re: RFR CODETOOLS-7902388: only one of the two should happen: either throw or calling Thread.interrupt()

Muneer,

There are still extra parentheses, which is mentioned in the bug description.

Shura

> On Feb 15, 2019, at 2:56 AM, Muneer Kolarkunnu <abdul.kolarkunnu at oracle.com> wrote:
> 
> Hi All,
> 
> Please review fix for the bug : https://bugs.openjdk.java.net/browse/CODETOOLS-7902388 
> 
> Webrev : http://cr.openjdk.java.net/~akolarkunnu/7902388/webrev.00/ 
> 
> Description: Removed interrupt() invoke.
> 
> Regards,
> Muneer
> 
> 


From alexandre.iline at oracle.com  Fri Feb 15 20:40:49 2019
From: alexandre.iline at oracle.com (Alexandre (Shura) Iline)
Date: Fri, 15 Feb 2019 12:40:49 -0800
Subject: RFR CODETOOLS-7902388: only one of the two should happen: either
 throw or calling Thread.interrupt()
In-Reply-To: <b732fa58-af67-461c-a9f2-65b3ef836b2f@default>
References: <98008613-e0dc-4bf2-a272-374b5192abc4@default>
 <1EF05BE0-CA75-456D-925A-C9517CD5F767@oracle.com>
 <b732fa58-af67-461c-a9f2-65b3ef836b2f@default>
Message-ID: <C5F56BC9-6213-46F9-A1F0-7E6073E56BC7@oracle.com>

Looks good.

> On Feb 15, 2019, at 12:14 PM, Muneer Kolarkunnu <abdul.kolarkunnu at oracle.com> wrote:
> 
> Yes, I missed that.
> Removed extra parentheses also.
> New webrev: http://cr.openjdk.java.net/~akolarkunnu/7902388/webrev.01/ 
> 
> Regards,
> Muneer
> 
> -----Original Message-----
> From: Alexandre (Shura) Iline 
> Sent: Friday, February 15, 2019 9:08 PM
> To: Muneer Kolarkunnu <abdul.kolarkunnu at oracle.com>
> Cc: jemmy-dev at openjdk.java.net
> Subject: Re: RFR CODETOOLS-7902388: only one of the two should happen: either throw or calling Thread.interrupt()
> 
> Muneer,
> 
> There are still extra parentheses, which is mentioned in the bug description.
> 
> Shura
> 
>> On Feb 15, 2019, at 2:56 AM, Muneer Kolarkunnu <abdul.kolarkunnu at oracle.com> wrote:
>> 
>> Hi All,
>> 
>> Please review fix for the bug : https://bugs.openjdk.java.net/browse/CODETOOLS-7902388 
>> 
>> Webrev : http://cr.openjdk.java.net/~akolarkunnu/7902388/webrev.00/ 
>> 
>> Description: Removed interrupt() invoke.
>> 
>> Regards,
>> Muneer
>> 
>> 
> 


From jkang at redhat.com  Tue Feb 19 15:48:23 2019
From: jkang at redhat.com (Jie Kang)
Date: Tue, 19 Feb 2019 10:48:23 -0500
Subject: Proposal for altering Jemmy packaging
In-Reply-To: <D172A1E4-A3C8-481B-ACEF-3E176B660160@oracle.com>
References: <CAEBeOco-o7x_iWt-++5ZrTrptpS7xyrcnr1eoyqeL4VGNVH8Vw@mail.gmail.com>
 <4E02A3BF-9EE1-426B-BB3D-5CBC27DA6B6E@oracle.com>
 <D172A1E4-A3C8-481B-ACEF-3E176B660160@oracle.com>
Message-ID: <CAEBeOcqhvnaRXD9ZMc0QVf53frk+Qj=47Lv=x-3mHxuTvo0-WQ@mail.gmail.com>

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
>
>
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jemmy-package-update.patch
Type: text/x-patch
Size: 61345 bytes
Desc: not available
URL: <https://mail.openjdk.java.net/pipermail/jemmy-dev/attachments/20190219/c9f3570a/jemmy-package-update-0001.patch>

From jkang at redhat.com  Tue Feb 19 17:09:46 2019
From: jkang at redhat.com (Jie Kang)
Date: Tue, 19 Feb 2019 12:09:46 -0500
Subject: Proposal for altering Jemmy packaging
In-Reply-To: <CAEBeOcqhvnaRXD9ZMc0QVf53frk+Qj=47Lv=x-3mHxuTvo0-WQ@mail.gmail.com>
References: <CAEBeOco-o7x_iWt-++5ZrTrptpS7xyrcnr1eoyqeL4VGNVH8Vw@mail.gmail.com>
 <4E02A3BF-9EE1-426B-BB3D-5CBC27DA6B6E@oracle.com>
 <D172A1E4-A3C8-481B-ACEF-3E176B660160@oracle.com>
 <CAEBeOcqhvnaRXD9ZMc0QVf53frk+Qj=47Lv=x-3mHxuTvo0-WQ@mail.gmail.com>
Message-ID: <CAEBeOcpN_OhYrfCuZhypk5jVhe=n=7k4+iUKbNPcKv=v0+J8bg@mail.gmail.com>

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

From marcus.hirt at oracle.com  Tue Feb 19 17:42:12 2019
From: marcus.hirt at oracle.com (Marcus Hirt)
Date: Tue, 19 Feb 2019 18:42:12 +0100
Subject: Proposal for altering Jemmy packaging
In-Reply-To: <CAEBeOcqhvnaRXD9ZMc0QVf53frk+Qj=47Lv=x-3mHxuTvo0-WQ@mail.gmail.com>
References: <CAEBeOco-o7x_iWt-++5ZrTrptpS7xyrcnr1eoyqeL4VGNVH8Vw@mail.gmail.com>
 <4E02A3BF-9EE1-426B-BB3D-5CBC27DA6B6E@oracle.com>
 <D172A1E4-A3C8-481B-ACEF-3E176B660160@oracle.com>
 <CAEBeOcqhvnaRXD9ZMc0QVf53frk+Qj=47Lv=x-3mHxuTvo0-WQ@mail.gmail.com>
Message-ID: <9C4F944D-9E1D-4571-96AE-788AE58CA5D7@oracle.com>

Hi Jie,

I think it looks good, but I just took a cursory look. Shura, 
what do you think? Also, Shura, can you please help get the 
new repo for this work going?

Kind regards,
Marcus

?On 2019-02-19, 16:48, "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
    >
    >
    >
    >
    



From alexandre.iline at oracle.com  Tue Feb 19 18:26:18 2019
From: alexandre.iline at oracle.com (Alexandre (Shura) Iline)
Date: Tue, 19 Feb 2019 10:26:18 -0800
Subject: Proposal for altering Jemmy packaging
In-Reply-To: <CAEBeOcpN_OhYrfCuZhypk5jVhe=n=7k4+iUKbNPcKv=v0+J8bg@mail.gmail.com>
References: <CAEBeOco-o7x_iWt-++5ZrTrptpS7xyrcnr1eoyqeL4VGNVH8Vw@mail.gmail.com>
 <4E02A3BF-9EE1-426B-BB3D-5CBC27DA6B6E@oracle.com>
 <D172A1E4-A3C8-481B-ACEF-3E176B660160@oracle.com>
 <CAEBeOcqhvnaRXD9ZMc0QVf53frk+Qj=47Lv=x-3mHxuTvo0-WQ@mail.gmail.com>
 <CAEBeOcpN_OhYrfCuZhypk5jVhe=n=7k4+iUKbNPcKv=v0+J8bg@mail.gmail.com>
Message-ID: <DF632689-0482-4400-89C4-D731E98DDC5F@oracle.com>

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


From patrick at reini.net  Tue Feb 19 18:39:15 2019
From: patrick at reini.net (Patrick Reinhart)
Date: Tue, 19 Feb 2019 19:39:15 +0100
Subject: Proposal for altering Jemmy packaging
In-Reply-To: <DF632689-0482-4400-89C4-D731E98DDC5F@oracle.com>
References: <CAEBeOco-o7x_iWt-++5ZrTrptpS7xyrcnr1eoyqeL4VGNVH8Vw@mail.gmail.com>
 <4E02A3BF-9EE1-426B-BB3D-5CBC27DA6B6E@oracle.com>
 <D172A1E4-A3C8-481B-ACEF-3E176B660160@oracle.com>
 <CAEBeOcqhvnaRXD9ZMc0QVf53frk+Qj=47Lv=x-3mHxuTvo0-WQ@mail.gmail.com>
 <CAEBeOcpN_OhYrfCuZhypk5jVhe=n=7k4+iUKbNPcKv=v0+J8bg@mail.gmail.com>
 <DF632689-0482-4400-89C4-D731E98DDC5F@oracle.com>
Message-ID: <1ce66112-7917-099f-3e61-da505bfb37e2@reini.net>

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



From alexandre.iline at oracle.com  Tue Feb 19 18:44:14 2019
From: alexandre.iline at oracle.com (Alexandre (Shura) Iline)
Date: Tue, 19 Feb 2019 10:44:14 -0800
Subject: Proposal for altering Jemmy packaging
In-Reply-To: <1ce66112-7917-099f-3e61-da505bfb37e2@reini.net>
References: <CAEBeOco-o7x_iWt-++5ZrTrptpS7xyrcnr1eoyqeL4VGNVH8Vw@mail.gmail.com>
 <4E02A3BF-9EE1-426B-BB3D-5CBC27DA6B6E@oracle.com>
 <D172A1E4-A3C8-481B-ACEF-3E176B660160@oracle.com>
 <CAEBeOcqhvnaRXD9ZMc0QVf53frk+Qj=47Lv=x-3mHxuTvo0-WQ@mail.gmail.com>
 <CAEBeOcpN_OhYrfCuZhypk5jVhe=n=7k4+iUKbNPcKv=v0+J8bg@mail.gmail.com>
 <DF632689-0482-4400-89C4-D731E98DDC5F@oracle.com>
 <1ce66112-7917-099f-3e61-da505bfb37e2@reini.net>
Message-ID: <C4BE316A-BCDA-4D93-A4DC-F00DE0C2DA10@oracle.com>


> On Feb 19, 2019, at 10:39 AM, Patrick Reinhart <patrick at reini.net> wrote:
> 
> Hi everyone,
> 
> As soon as the commit is done (having the new version), I will publish a
> new release to Maven Central?

May be wait a bit with that.

I would like to have this in a branch first.

Once it is there, I would see what, if any, changes need to be done in JemmyFX (which is not co-located) and if it is possible to run some JavaFX tests.
Also, and, as Marcus has said, JMC tests need to be run.

Once we sure everything works with a reasonable amount of updates, I will push it on trunk.

Shura

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


From patrick at reini.net  Wed Feb 20 09:37:19 2019
From: patrick at reini.net (Patrick Reinhart)
Date: Wed, 20 Feb 2019 10:37:19 +0100
Subject: Proposal for altering Jemmy packaging
In-Reply-To: <C4BE316A-BCDA-4D93-A4DC-F00DE0C2DA10@oracle.com>
References: <CAEBeOco-o7x_iWt-++5ZrTrptpS7xyrcnr1eoyqeL4VGNVH8Vw@mail.gmail.com>
 <4E02A3BF-9EE1-426B-BB3D-5CBC27DA6B6E@oracle.com>
 <D172A1E4-A3C8-481B-ACEF-3E176B660160@oracle.com>
 <CAEBeOcqhvnaRXD9ZMc0QVf53frk+Qj=47Lv=x-3mHxuTvo0-WQ@mail.gmail.com>
 <CAEBeOcpN_OhYrfCuZhypk5jVhe=n=7k4+iUKbNPcKv=v0+J8bg@mail.gmail.com>
 <DF632689-0482-4400-89C4-D731E98DDC5F@oracle.com>
 <1ce66112-7917-099f-3e61-da505bfb37e2@reini.net>
 <C4BE316A-BCDA-4D93-A4DC-F00DE0C2DA10@oracle.com>
Message-ID: <6b6b3a45d370ff5e3bb35835c1c9f758@reini.net>


Shure, I will do that after the tests have been completed...

-Patrick

On 2019-02-19 19:44, Alexandre (Shura) Iline wrote:
>> On Feb 19, 2019, at 10:39 AM, Patrick Reinhart <patrick at reini.net> 
>> wrote:
>> 
>> Hi everyone,
>> 
>> As soon as the commit is done (having the new version), I will publish 
>> a
>> new release to Maven Central?
> 
> May be wait a bit with that.
> 
> I would like to have this in a branch first.
> 
> Once it is there, I would see what, if any, changes need to be done in
> JemmyFX (which is not co-located) and if it is possible to run some
> JavaFX tests.
> Also, and, as Marcus has said, JMC tests need to be run.
> 
> Once we sure everything works with a reasonable amount of updates, I
> will push it on trunk.
> 
> Shura
> 
>> 
>> -Patrick
>> 

From alexandre.iline at oracle.com  Fri Feb 22 23:57:57 2019
From: alexandre.iline at oracle.com (Alexandre (Shura) Iline)
Date: Fri, 22 Feb 2019 15:57:57 -0800
Subject: Proposal for altering Jemmy packaging
In-Reply-To: <CAEBeOcqhvnaRXD9ZMc0QVf53frk+Qj=47Lv=x-3mHxuTvo0-WQ@mail.gmail.com>
References: <CAEBeOco-o7x_iWt-++5ZrTrptpS7xyrcnr1eoyqeL4VGNVH8Vw@mail.gmail.com>
 <4E02A3BF-9EE1-426B-BB3D-5CBC27DA6B6E@oracle.com>
 <D172A1E4-A3C8-481B-ACEF-3E176B660160@oracle.com>
 <CAEBeOcqhvnaRXD9ZMc0QVf53frk+Qj=47Lv=x-3mHxuTvo0-WQ@mail.gmail.com>
Message-ID: <75D6504B-B58E-48E3-81C3-2A9A0CF90B96@oracle.com>

Jie,

Currently what you are suggesting is to rename test.org <http://test.org/>.jemmy.* packages to test.org <http://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 <http://test.org/>.jemmy.input -> test.org <http://test.org/>.jemmy.input.awt
test.org <http://test.org/>.jemmy.image -> test.org <http://test.org/>.jemmy.image.awt
test.org <http://test.org/>.jemmy.operators -> test.org <http://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
>> 
>> 
>> 
>> 


From alexandre.iline at oracle.com  Thu Feb 28 18:35:26 2019
From: alexandre.iline at oracle.com (alexandre.iline at oracle.com)
Date: Thu, 28 Feb 2019 18:35:26 +0000
Subject: hg: code-tools/jemmy/v2: 7902388: only one of the two should happen:
 either throw or calling Thread.interrupt()
Message-ID: <201902281835.x1SIZR6T011777@aojmv0008.oracle.com>

Changeset: 464e600a2b0c
Author:    akolarkunnu
Date:      2019-02-15 13:09 -0800
URL:       http://hg.openjdk.java.net/code-tools/jemmy/v2/rev/464e600a2b0c

7902388: only one of the two should happen: either throw or calling Thread.interrupt()
Reviewed-by: shurailine
Contributed-by: abdul.kolarkunnu at oracle.com

! src/org/netbeans/jemmy/operators/JToolTipOperator.java
! src/org/netbeans/jemmy/operators/Operator.java


From jkang at redhat.com  Thu Feb 28 22:10:54 2019
From: jkang at redhat.com (Jie Kang)
Date: Thu, 28 Feb 2019 17:10:54 -0500
Subject: Fwd: Proposal for altering Jemmy packaging
In-Reply-To: <CAEBeOcqEJMvQ1gJutOZRvT5xcOoXNrq-UUS6rK7f_+RqtwOgEg@mail.gmail.com>
References: <CAEBeOco-o7x_iWt-++5ZrTrptpS7xyrcnr1eoyqeL4VGNVH8Vw@mail.gmail.com>
 <4E02A3BF-9EE1-426B-BB3D-5CBC27DA6B6E@oracle.com>
 <D172A1E4-A3C8-481B-ACEF-3E176B660160@oracle.com>
 <CAEBeOcqhvnaRXD9ZMc0QVf53frk+Qj=47Lv=x-3mHxuTvo0-WQ@mail.gmail.com>
 <75D6504B-B58E-48E3-81C3-2A9A0CF90B96@oracle.com>
 <6E36A8AB-BC51-4AC3-8785-8B8F3ED8AADC@oracle.com>
 <CAEBeOcqEJMvQ1gJutOZRvT5xcOoXNrq-UUS6rK7f_+RqtwOgEg@mail.gmail.com>
Message-ID: <CAEBeOcqjmSdjvmbhVyx2LAxFi0dTvi2RhPvQ6MLNLE+W3HgwEQ@mail.gmail.com>

Forwarding to jemmy-dev. Sorry for missing that CC.

---------- Forwarded message ---------
From: Jie Kang <jkang at redhat.com>
Date: Thu, Feb 28, 2019 at 5:08 PM
Subject: Re: Proposal for altering Jemmy packaging


Hi Shura

Your explanation and suggestion makes sense to me; preventing a
conflict with a possible AWT/JemmyAWT module is worthwhile.

I would like to clarify the prefix 'test' in the package names you
listed of 'test.org.jemmy...'. Was this prefix intended to be
included? I think the packages are org.jemmy... and there are
corresponding src and test folders for the respective classes.

For a non-conflicting naming scheme, appending awt afterwards as you
suggested would solve the problem, however, suffixing the sub packages
of input/image/operators is a little strange in my opinion. How does:

org.jemmy.* -> org.jemmy.awtinput.*

sound to you? Let me know which you think is better and I will prepare
a revised patch for your consideration.


Apologies for the delay,

> 23 feb. 2019 kl. 00:57 skrev Alexandre (Shura) Iline <alexandre.iline at oracle.com>:
>
> 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,
>