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: References: 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 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: <4E02A3BF-9EE1-426B-BB3D-5CBC27DA6B6E@oracle.com> Message-ID: 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" 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 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 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: 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 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 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: References: <98008613-e0dc-4bf2-a272-374b5192abc4@default> <1EF05BE0-CA75-456D-925A-C9517CD5F767@oracle.com> Message-ID: Looks good. > On Feb 15, 2019, at 12:14 PM, Muneer Kolarkunnu 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 > 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 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: References: <4E02A3BF-9EE1-426B-BB3D-5CBC27DA6B6E@oracle.com> Message-ID: 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 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" 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 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: 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: References: <4E02A3BF-9EE1-426B-BB3D-5CBC27DA6B6E@oracle.com> Message-ID: On Tue, Feb 19, 2019 at 10:48 AM Jie Kang 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 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" 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 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: References: <4E02A3BF-9EE1-426B-BB3D-5CBC27DA6B6E@oracle.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" 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 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" 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 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: References: <4E02A3BF-9EE1-426B-BB3D-5CBC27DA6B6E@oracle.com> Message-ID: 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 wrote: > > On Tue, Feb 19, 2019 at 10:48 AM Jie Kang 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 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" 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 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: References: <4E02A3BF-9EE1-426B-BB3D-5CBC27DA6B6E@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 wrote: >> >> On Tue, Feb 19, 2019 at 10:48 AM Jie Kang 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 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" 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 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: <4E02A3BF-9EE1-426B-BB3D-5CBC27DA6B6E@oracle.com> <1ce66112-7917-099f-3e61-da505bfb37e2@reini.net> Message-ID: > On Feb 19, 2019, at 10:39 AM, Patrick Reinhart 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 wrote: >>> >>> On Tue, Feb 19, 2019 at 10:48 AM Jie Kang 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 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" 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 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: References: <4E02A3BF-9EE1-426B-BB3D-5CBC27DA6B6E@oracle.com> <1ce66112-7917-099f-3e61-da505bfb37e2@reini.net> 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 >> 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: References: <4E02A3BF-9EE1-426B-BB3D-5CBC27DA6B6E@oracle.com> Message-ID: <75D6504B-B58E-48E3-81C3-2A9A0CF90B96@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 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 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" 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 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: References: <4E02A3BF-9EE1-426B-BB3D-5CBC27DA6B6E@oracle.com> <75D6504B-B58E-48E3-81C3-2A9A0CF90B96@oracle.com> <6E36A8AB-BC51-4AC3-8785-8B8F3ED8AADC@oracle.com> Message-ID: Forwarding to jemmy-dev. Sorry for missing that CC. ---------- Forwarded message --------- From: Jie Kang 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 : > > 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 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, >