Adding Jemmy v3 to https://adopt-openjdk.ci.cloudbees.com/view/OpenJDK%20code-tools/

Alexandre (Shura) Iline alexandre.iline at oracle.com
Wed Apr 11 21:13:54 UTC 2018 


> On Apr 11, 2018, at 9:41 AM, Martijn Verburg <martijnverburg at gmail.com> wrote:
> 
> Hi all,
> 
> The Jemmy build project is here: https://ci.adoptopenjdk.net/view/Dependencies/job/jemmy/
> 
> If managed to get a mostly successful run and have produced a jemmy.tar.gz file that contains the 3 jar files (jemmyCore.jar, JemmyAWTInput.jar, JemmyBrowser.jar).  Now for some questions :-)
> 
> 1.) I'm running this on Linux x86 - since we're replying on an SWT lib, do platform specific jemmy's need to be built?
> 2.) Some of the tests naturally failed (Robot testing the UI), I'll see if I can get that Jenkins node to fire up an X11 so that those tests can pass.
> 3.) Can folks please grab the tar.gz from the latest artifacts link and let me know if that's how they expect it to be named and whether the layout of the contents is acceptable

This and above I will leave for Erik to answer.

> 4.) Versioning / naming - should I be building off a known good tag?  Do we want the tip/commit number to be part of the artifact name?

Ah, the versioning.

Historically, Jemmy version is contained in a properties file in the source code. This is true for all Jemmy artifacts. Such as, for example:
$ cat core/JemmyCore/src/org/jemmy/jemmy.properties 
version.major=1
version.minor=0
version.mini=0

Side note: it is 1.0.0 because I have bumped it to that while uploading to code-tools. It used to be 0.9.* before that. Every developer is supposed to bump up the mini or the minor version with API changes.

The build process is so that a build number adds a date to the version and specifies appropriate manifest so the version could be reported from commend line. Such as
$ java -jar core/JemmyCore/build/JemmyCore.jar
JemmyCore version: 1.0.0.20180328

I know too little about maven to tell what of that could be preserved with maven builds. It would definitely be good to not loose this info in maven artifacts.

Shura


> 
> It should build on an SCM change and weekly as well
> 
> 
> Cheers,
> Martijn
> 
> On 11 April 2018 at 09:56, Martijn Verburg <martijnverburg at gmail.com> wrote:
> Cool, I'll go with what I have as a working build for now and adjust to use the test target when that change comes in, and then perhaps move to the Maven build later.
> 
> Cheers,
> Martijn
> 
> On 10 April 2018 at 21:26, Alexandre (Shura) Iline <alexandre.iline at oracle.com> wrote:
> 
> 
>> On Apr 10, 2018, at 8:52 AM, Martijn Verburg <martijnverburg at gmail.com> wrote:
>> 
>> Hi Alexandre,
>> 
>> I'm using JTReg from the AdoptOpenJDK Build Farm (https://ci.adoptopenjdk.net/view/all/job/jtreg/) in particular the jtreg-4.2-b12.tar.gz binary.  That appears to have cleared that issue up (we did have broken binaries for a bit).
>> 
>> If I now run 
>> 
>> ant -Dswt.jar=lib/org.eclipse.swt.cocoa.macosx.x86_64-4.3.jar build-dependecies-impl
>> ant -Djtreg.home=/Users/karianna/Documents/workspace/AdoptOpenJDK_Projects/jtreg/ -Dswt.jar=lib/org.eclipse.swt.cocoa.macosx.x86_64-4.3.jar test-dependecies-impl
>> 
>> Then I get a passing build!
>> 
>> ---------
>> 
>> Onto the next issue! If I run just:
>> 
>> ant -Djtreg.home=/Users/karianna/Documents/workspace/AdoptOpenJDK_Projects/jtreg/ -Dswt.jar=lib/org.eclipse.swt.cocoa.macosx.x86_64-4.3.jar test
>> 
>> Then I get compile errors like:
>> 
>> compile-test:
>>     [javac] Compiling 7 source files to /Users/karianna/Documents/workspace/AdoptOpenJDK_Projects/v3/SWT/JemmySWT/build/test
>>     [javac] /Users/karianna/Documents/workspace/AdoptOpenJDK_Projects/v3/SWT/JemmySWT/test/org/jemmy/swt/ItemsTest.java:84: error: cannot find symbol
>>     [javac]         prnt.lookup(new ByTextItem<TabItem>("Table")).wrap().mouse().click();
>>     [javac]                         ^
>>     [javac]   symbol:   class ByTextItem
>>     [javac]   location: class ItemsTest
>>     [javac] /Users/karianna/Documents/workspace/AdoptOpenJDK_Projects/v3/SWT/JemmySWT/test/org/jemmy/swt/ItemsTest.java:92: error: cannot find symbol
>>     [javac]         prnt.lookup(new ByTextItem<TabItem>(tab)).wrap().mouse().click();
>>     [javac]                         ^
>>     [javac]   symbol:   class ByTextItem
>>     [javac]   location: class ItemsTest
> 
> 
> This, I believe, is a bug which is going to be addressed by the review in progress: http://mail.openjdk.java.net/pipermail/jemmy-dev/2018-April/000080.html
> 
> Shura
> 
>> 
>> ------------
>> 
>> A README.txt for building at the root of the project and a .hgignore file would also be nice to haves.
>> 
>> ------------
>> 
>> I'm now going to source a Linux 4.3 SWT lib and see if I can get Jemmy building nightly on our build farm.  I'm also very interested in seeing the Maven support go in :-).
>> 
>> Cheers,
>> Martijn
>> 
>> On 9 April 2018 at 18:52, Alexandre (Shura) Iline <alexandre.iline at oracle.com> wrote:
>> Do you happen to have full stack trace of that?
>> 
>> Also, how to I get JTReg which are you using?
>> 
>> The reported missing method would be a part of JTReg, clearly.
>> 
>> The other thing is you should probably be ok with just running ant …. test. “test” target is coming from http://hg.openjdk.java.net/code-tools/jemmy/v3/file/898c9e02c8c9/make/build_template.xml.
>> 
>> Shura
>> 
>> 
>>> On Apr 6, 2018, at 6:47 AM, Martijn Verburg <martijnverburg at gmail.com> wrote:
>>> 
>>> Hi Alexandre,
>>> 
>>> I got a little further (This is using Java 1.8.0_162).  Once I set my swt.jar and jtreg.home I was able to run:
>>> 
>>> ant -Dswt.jar=lib/org.eclipse.swt.cocoa.macosx.x86_64-4.3 check-dependecies-impl
>>> ant -Dswt.jar=lib/org.eclipse.swt.cocoa.macosx.x86_64-4.3 build-dependecies-impl
>>> ant -Dswt.jar=lib/org.eclipse.swt.cocoa.macosx.x86_64-4.3 -Djtreg.home=/Users/karianna/Documents/workspace/AdoptOpenJDK_Projects/jtreg/ test-dependecies-impl
>>> 
>>> The first two execute OK but then the test gives me the test failure of:
>>> 
>>> test:
>>>      [exec] Directory "/Users/karianna/Documents/workspace/AdoptOpenJDK_Projects/v3/core/JemmyBrowser/build/test_wd" not found: creating
>>>      [exec] Directory "/Users/karianna/Documents/workspace/AdoptOpenJDK_Projects/v3/core/JemmyBrowser/build/test_report" not found: creating
>>>      [exec] runner starting test: org/jemmy/browser/PropPanelTest.java
>>>      [exec] runner finished test: org/jemmy/browser/PropPanelTest.java
>>>      [exec] Error. Unexpected error caught from test org/jemmy/browser/PropPanelTest.java: java.lang.NoSuchMethodError: com.sun.javatest.regtest.agent.JDK_Version.compareTo(Lcom/sun/javatest/regtest/agent/JDK_Version;)I
>>>      [exec] Test results: error: 1
>>>      [exec] Report written to /Users/karianna/Documents/workspace/AdoptOpenJDK_Projects/v3/core/JemmyBrowser/build/test_report/html/report.html
>>>      [exec] Results written to /Users/karianna/Documents/workspace/AdoptOpenJDK_Projects/v3/core/JemmyBrowser/build/test_wd
>>>      [exec] Error: Some tests failed or other problems occurred.
>>>      [exec] Result: 3
>>> 
>>> Any ideas?
>>> 
>>> FYI - I'm still running this locally on my Mac OS X box until I get a clean build so I know the minimum steps for the build farm job.  Note to self that the build box will need to provide a platform specific SWT lib (Linux x86).
>>> 
>>> Cheers,
>>> Martijn
>>> 
>>> On 28 March 2018 at 21:43, Alexandre (Shura) Iline <alexandre.iline at oracle.com> wrote:
>>> Now including aliases and more recipients..
>>> 
>>> > On Mar 28, 2018, at 1:41 PM, Alexandre (Shura) Iline <alexandre.iline at oracle.com> wrote:
>>> >
>>> >
>>> >
>>> >> On Mar 28, 2018, at 12:28 PM, Martijn Verburg <martijnverburg at gmail.com> wrote:
>>> >>
>>> >> Hi Alexandre,
>>> >>
>>> >> OK, So I naively tried to run ant in the SWT/JemmySWT folder and that failed with:
>>> >>
>>> >> /Users/karianna/Documents/workspace/AdoptOpenJDK_Projects/v3/SWT/JemmySWT/build.xml:33: Please specify swt.jar
>>> >
>>> > You do need the SWT library to build SWT.
>>> >
>>> > this is what I just did:
>>> >
>>> > ~/JDK/hg/jemmy/v3/SWT/JemmySWT$ ant -Dswt.jar=/usr/lib/eclipse/plugins/org.eclipse.swt_3.8.2.jar jar
>>> >
>>> >
>>> > I clearly need to provide a README. Will do.
>>> >
>>> > Shura
>>> >
>>> >>
>>> >> Then I actually bothered to read the build.xml file and saw the build-dependecies-impl target, so I ran ant build-dependecies-impl which seemed to build:
>>> >>
>>> >> /Users/karianna/Documents/workspace/AdoptOpenJDK_Projects/v3/core/JemmyCore/build/JemmyCore.jar
>>> >> /Users/karianna/Documents/workspace/AdoptOpenJDK_Projects/v3/core/JemmyAWTInput/build/JemmyAWTInput.jar
>>> >> /Users/karianna/Documents/workspace/AdoptOpenJDK_Projects/v3/core/JemmyBrowser/build/JemmyBrowser.jar
>>> >>
>>> >> Then I ran ant test-dependecies-impl and it wanted my jtreg.home set
>>> >>
>>> >> Before I shave more Yaks, is this the right direction to be going in?
>>> >>
>>> >>
>>> >> Cheers,
>>> >> Martijn
>>> >>
>>> >> On 28 March 2018 at 20:43, Alexandre (Shura) Iline <alexandre.iline at oracle.com> wrote:
>>> >> Martijn,
>>> >>
>>> >> Jemmy v3 consists of several project which depend on each other.
>>> >>
>>> >> If, besides hosting the source, the intension is to build it, you need to build projects which are in use by others who would be coming to AdoptOpenJDK for binaries.
>>> >>
>>> >> At this point of time, from what I know, JemmySWT is what is needed. Ant build scripts are constructed in a way so that by while JemmySWT is build, the dependences are also built, you should have no problem with that.
>>> >>
>>> >> Binaries would, then, simply include all jar files create after the build. The jar files will be: */*/build/*.jar
>>> >>
>>> >> Shura
>>> >>
>>> >>
>>> >>> On Mar 28, 2018, at 11:35 AM, Martijn Verburg <martijnverburg at gmail.com> wrote:
>>> >>>
>>> >>> Hi Dalibor,
>>> >>>
>>> >>> We're shifting the code tools off Cloudbees to the new adoptiopenjdk.net build farm.  I'm more than happy to add it, a quick Q:
>>> >>>
>>> >>> hg clone http://hg.openjdk.java.net/code-tools/jemmy/v3/ gives me:
>>> >>>
>>> >>> drwxr-xr-x   7 karianna  staff   238 28 Mar 19:30 .
>>> >>> drwxr-xr-x  44 karianna  staff  1496 28 Mar 19:30 ..
>>> >>> drwxr-xr-x  13 karianna  staff   442 28 Mar 19:30 .hg
>>> >>> drwxr-xr-x   3 karianna  staff   102 28 Mar 19:30 .jcheck
>>> >>> drwxr-xr-x   4 karianna  staff   136 28 Mar 19:30 SWT
>>> >>> drwxr-xr-x   6 karianna  staff   204 28 Mar 19:30 core
>>> >>> drwxr-xr-x   3 karianna  staff   102 28 Mar 19:30 make
>>> >>>
>>> >>> but I can't see what the canonical entry point to build it is.
>>> >>>
>>> >>> I'll sign up to jemmy-dev and x-post there shortly.
>>> >>>
>>> >>> Cheers,
>>> >>> Martijn
>>> >>>
>>> >>> On 28 March 2018 at 17:02, dalibor topic <dalibor.topic at oracle.com> wrote:
>>> >>> Hi Martijn,
>>> >>>
>>> >>> would you be able to add the Jemmy v3 repo at http://hg.openjdk.java.net/code-tools/jemmy/v3/ to https://adopt-openjdk.ci.cloudbees.com/view/OpenJDK%20code-tools/ ?
>>> >>>
>>> >>> cheers,
>>> >>> dalibor topic
>>> >>> --
>>> >>> <http://www.oracle.com> Dalibor Topic | Principal Product Manager
>>> >>> Phone: +494089091214 <tel:+494089091214> | Mobile: +491737185961
>>> >>> <tel:+491737185961>
>>> >>>
>>> >>> ORACLE Deutschland B.V. & Co. KG | Kühnehöfe 5 | 22761 Hamburg
>>> >>>
>>> >>> ORACLE Deutschland B.V. & Co. KG
>>> >>> Hauptverwaltung: Riesstr. 25, D-80992 München
>>> >>> Registergericht: Amtsgericht München, HRA 95603
>>> >>>
>>> >>> Komplementärin: ORACLE Deutschland Verwaltung B.V.
>>> >>> Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
>>> >>> Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
>>> >>> Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher
>>> >>>
>>> >>> <http://www.oracle.com/commitment> Oracle is committed to developing
>>> >>> practices and products that help protect the environment
>>> >>>
>>> >>
>>> >>
>>> >
>>> 
>>> 
>> 
>> 
> 
> 
>

More information about the adoption-discuss mailing list