From jonathan.gibbons at oracle.com Fri Dec 1 02:32:09 2017 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Fri, 01 Dec 2017 02:32:09 +0000 Subject: hg: code-tools/jtreg: 7902074: Simplify configuration for building and testing jtreg Message-ID: <201712010232.vB12W95D027358@aojmv0008.oracle.com> Changeset: 1d23b6baaa4f Author: jjg Date: 2017-11-30 18:28 -0800 URL: http://hg.openjdk.java.net/code-tools/jtreg/rev/1d23b6baaa4f 7902074: Simplify configuration for building and testing jtreg ! make/Defs.gmk ! make/Makefile ! make/Rules.gmk ! make/jtreg.gmk ! src/share/classes/com/sun/javatest/regtest/agent/JavaTestSecurityManager.java ! test/4499340/T4499340.gmk ! test/4730538/T4730538.gmk ! test/6517728/T6517728.gmk ! test/6517916/T6517916.gmk ! test/6519296/T6519296.gmk ! test/6527624/T6527624.gmk ! test/6533043/T6533043.gmk ! test/6533074/T6533074.gmk ! test/6533136/T6533136.gmk ! test/6585912/T6585912.gmk ! test/6590657/T6590657.gmk ! test/6590671/T6590671.gmk ! test/6622433/T6622433.gmk ! test/6783039/T6783039.gmk ! test/6783087/T6783087.gmk ! test/6799634/T6799634.gmk ! test/6809055/T6809055.gmk ! test/6811371.gmk ! test/7113596/T7113596.gmk ! test/7900130/T7900130.gmk ! test/7900165/T7900165.gmk ! test/Properties/PropertyTests.gmk ! test/SecurityManager/SecurityManagerTests.gmk ! test/TestWhiteSpaceFiles.gmk ! test/absLib/TestAbsLib.gmk ! test/autovm/AutoVMTests.gmk ! test/badlibs/BadLibsTest.gmk ! test/badtests/BadTests.gmk ! test/basic/Basic.gmk ! test/basic/ReportOnlyTest.gmk ! test/bugidtests/BugIdTests.gmk ! test/build-wildcards/buildWildcards.gmk ! test/buildPatternTest/BuildPatternTest.gmk ! test/buildTag/BuildTagTest.gmk ! test/classDirs/ClassDirsTest.gmk ! test/classIsolation/ClassIsolationTest.gmk ! test/cleanup/CleanupTest.gmk ! test/compileArgFileTest/CompileArgFileTest.gmk ! test/compilejdk/CompileTests.gmk ! test/cpappend/CPAppendTests.gmk ! test/ctrl/ControlTest.gmk ! test/debug/DebugTest.gmk ! test/dupTests/DupTest.gmk ! test/empty/EmptyTest.gmk ! test/env/EnvTest.gmk ! test/exclude/ExcludeTest.gmk ! test/exclusive/ExclusiveAccessTest.gmk ! test/exitCodes/ExitCodeTest.gmk ! test/extlib/ExtLibTest.gmk ! test/extra-props/ExtraPropDefnsTest.gmk ! test/groups/GroupTest.gmk ! test/i18n/i18n.com.sun.javatest.diff.gmk ! test/i18n/i18n.com.sun.javatest.regtest.gmk ! test/ignoreTag/IgnoreTagTest.gmk ! test/interrupt/RunInterrupt.gmk ! test/javac/JavacTests.gmk ! test/jdkModulesTest/JDKModulesTest.gmk ! test/jdkOptsTest/JDKOptsTest.gmk ! test/junitTrace/JUnitTrace.gmk ! test/libBuildArgs/LibBuildArgsTest.gmk ! test/libdirs/LibDirsTest.gmk ! test/moduleOpens/ModuleOpensTest.gmk ! test/multirun/MultiRunTest.gmk ! test/nativepath/TestNativePath.gmk ! test/normalizeStatus/NormalizeStatusTest.gmk ! test/openfiles/OpenFileTests.gmk ! test/optionDecoder/OptionDecoderTest.gmk ! test/osTest/OSTest.gmk ! test/pkgInfo/PkgInfoTest.gmk ! test/policy/PolicyTest.gmk ! test/problemList/ProblemList.gmk ! test/requires/RequiresTest.gmk ! test/rerun2/RerunTest2.gmk ! test/retain/TestRetainTest.gmk ! test/secprov/SecurityProviderTest.gmk ! test/statsTests/StatsTests.gmk ! test/testJavacExitCodes/JavacExitCodeTests.gmk ! test/testRequiredVersion.gmk ! test/testng/TestNGLibTest.gmk ! test/testngLibs/TestNGLibsTest.gmk ! test/testprops/TestPropsTest.gmk ! test/timelimit/TimelimitTests.gmk ! test/timeoutHandler/TimeoutHandlerTimeoutTest.gmk ! test/timeouts/TimeoutTest.gmk ! test/vmopts/TestVMOpts.gmk From jonathan.gibbons at oracle.com Fri Dec 1 22:02:54 2017 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Fri, 01 Dec 2017 22:02:54 +0000 Subject: hg: code-tools/jtreg: 7902075: jtreg doesn't build if jh.jar doesn't contain signatures Message-ID: <201712012202.vB1M2t6k014738@aojmv0008.oracle.com> Changeset: c0efd4ab54dc Author: jjg Date: 2017-12-01 13:51 -0800 URL: http://hg.openjdk.java.net/code-tools/jtreg/rev/c0efd4ab54dc 7902075: jtreg doesn't build if jh.jar doesn't contain signatures Contributed-by: volker.simonis at gmail.com ! make/jtreg.gmk From jvanek at redhat.com Tue Dec 5 10:01:31 2017 From: jvanek at redhat.com (Jiri Vanek) Date: Tue, 5 Dec 2017 11:01:31 +0100 Subject: RFC: add starred module(s) In-Reply-To: References: Message-ID: Hi Jonathan! I think this proposal have quite a sense. I was moving our old jtreg tests to work with jdk9 too, and copy pasting on module level is terrible. This proposal is cool. It is keeping encapsulation in place and lowering the writing a lot. I would go even more deep, eg " @modules all-needed", and jtreg will deduct necessary --add-whatever on its own. The shell part is even more worse. And especially the shell part is where jtreg is hard to replace (read: I like jtreg here very much :) ) Here you get only TESTMODULES variable which is not enough, and (unlike in java file) it is here even for jdk8 and older. So maybe there can be one more variable, containing full --add-whatever string which got filled only for modular jdk? I will be happy to implement those features if you agree with the principle. Thanx! J. On 11/30/2017 02:21 PM, Miloslav Zezulka wrote: > Hello, > > when working with @modules tag, it might be sometimes beneficial to have > the ability to open multiple packages from the same parent using one > @modules tag only (for example via star notation as in regular java > imports). The idea came to my mind when modifying some CPU reproducers to > be compatible with JDK9. Let's consider a JTreg comment for one of them: > > * .... > * @modules java.security.jgss/sun.security.krb5.internal > * @modules java.security.jgss/sun.security.krb5.internal.ccache > * @modules java.security.jgss/sun.security.krb5.internal.crypto > * @modules java.security.jgss/sun.security.krb5.internal.ktab > * @modules java.base/sun.security.util > * @modules java.security.jgss/sun.security.jgss > */ > > Although this has the advantage thta we explicitly know which internal > packages are being opened for the given test, someone might prefer to use > the @modules tag the folllowing way to make the JTreg comment more readable > and less wordier: > > * .... > * @modules java.security.jgss/sun.security.krb5.internal.* > * @modules java.base/sun.security.util > * @modules java.security.jgss/sun.security.jgss > */ > > As a JTreg newbie, I wasn't able to find such feature in the current > version. The attached patch is a draft of how this might be implemented. > > Thoughts? > > Thanks, > M?la > -- Jiri Vanek Senior QE engineer, OpenJDK QE lead, Mgr. Red Hat Czech jvanek at redhat.com M: +420775390109 From jonathan.gibbons at oracle.com Wed Dec 6 19:46:37 2017 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Wed, 06 Dec 2017 19:46:37 +0000 Subject: hg: code-tools/jtreg: small update to docs Message-ID: <201712061946.vB6JkbhG014343@aojmv0008.oracle.com> Changeset: 0965c43470bd Author: jjg Date: 2017-12-06 11:42 -0800 URL: http://hg.openjdk.java.net/code-tools/jtreg/rev/0965c43470bd small update to docs ! src/share/doc/javatest/regtest/README From jvanek at redhat.com Fri Dec 8 12:23:39 2017 From: jvanek at redhat.com (Jiri Vanek) Date: Fri, 8 Dec 2017 13:23:39 +0100 Subject: RFC: add starred module(s) In-Reply-To: References: Message-ID: ping? On 12/05/2017 11:01 AM, Jiri Vanek wrote: > Hi Jonathan! > > I think this proposal have quite a sense. I was moving our old jtreg tests to work with jdk9 too, > and copy pasting on module level is terrible. > > This proposal is cool. It is keeping encapsulation in place and lowering the writing a lot. > I would go even more deep, eg " @modules all-needed", and jtreg will deduct necessary --add-whatever > on its own. > > The shell part is even more worse. And especially the shell part is where jtreg is hard to replace > (read: I like jtreg here very much :) ) > Here you get only TESTMODULES variable which is not enough, and (unlike in java file) it is here > even for jdk8 and older. > So maybe there can be one more variable, containing full --add-whatever string which got filled > only for modular jdk? > > I will be happy to implement those features if you agree with the principle. > > > Thanx! > J. > > > > On 11/30/2017 02:21 PM, Miloslav Zezulka wrote: >> Hello, >> >> when working with @modules tag, it might be sometimes beneficial to have >> the ability to open multiple packages from the same parent using one >> @modules tag only (for example via star notation as in regular java >> imports). The idea came to my mind when modifying some CPU reproducers to >> be compatible with JDK9. Let's consider a JTreg comment for one of them: >> >> * .... >> * @modules java.security.jgss/sun.security.krb5.internal >> * @modules java.security.jgss/sun.security.krb5.internal.ccache >> * @modules java.security.jgss/sun.security.krb5.internal.crypto >> * @modules java.security.jgss/sun.security.krb5.internal.ktab >> * @modules java.base/sun.security.util >> * @modules java.security.jgss/sun.security.jgss >> */ >> >> Although this has the advantage thta we explicitly know which internal >> packages are being opened for the given test, someone might prefer to use >> the @modules tag the folllowing way to make the JTreg comment more readable >> and less wordier: >> >> * .... >> * @modules java.security.jgss/sun.security.krb5.internal.* >> * @modules java.base/sun.security.util >> * @modules java.security.jgss/sun.security.jgss >> */ >> >> As a JTreg newbie, I wasn't able to find such feature in the current >> version. The attached patch is a draft of how this might be implemented. >> >> Thoughts? >> >> Thanks, >> M?la >> > > -- Jiri Vanek Senior QE engineer, OpenJDK QE lead, Mgr. Red Hat Czech jvanek at redhat.com M: +420775390109 From jonathan.gibbons at oracle.com Sat Dec 9 01:51:10 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 08 Dec 2017 17:51:10 -0800 Subject: RFC: add starred module(s) In-Reply-To: References: Message-ID: <5A2B418E.9000607@oracle.com> Jiri, Mila, There are three significant questions here. 1. @modules all-needed This is a non-starter. @modules participates in a relatively light-weight test selection mechanism ... i.e. tests are not selected if the specified modules are not available in the system image. Having jtreg analyse the source code to determine the set of necessary modules is just not practical. 2. Starred modules, as in @modules java.security.jgss/sun.security.krb5.internal.* Setting aside whether this is desirable or not, this is not necessarily an easy thing to do. It requires that we can list the (internal) packages of a module. Yes, there may be a attribute that provides the info, but the attribute is not guaranteed to be available, and if it's not, you're reduced to scanning the module contents. On the desirability point of view, the use of this sort of syntax was discussed, and rejected, for module declarations, and while that is separate from what is proposed here, it does lend guidance. Neither is the '*' syntax supported by the options for the Java launcher or javac, and this construct is intended to be a thinly-veiled wrapper for those options. One minor comment ... you can reduce the "wordiness" of your examples by almost 50% by just having a single @modules directive with many arg values, possibly spanning many lines, as in ... * .... * @modules java.security.jgss/sun.security.krb5.internal * java.security.jgss/sun.security.krb5.internal.ccache * java.security.jgss/sun.security.krb5.internal.crypto * java.security.jgss/sun.security.krb5.internal.ktab * java.base/sun.security.util * java.security.jgss/sun.security.jgss 3. Shell scripts. Using shell scripts for jtreg tests is generally discouraged, these days, to the point that we have made efforts to convert many/most JDK shell tests to Java code. The general experience was that such tests were very fragile, and were often wrong/broken. They typically execute slower than equivalent Java code, especially when using libraries providing commonly-used or domain-specific functionality. And as you note below, processing variables like TESTMODULES is problematic. (It is a bug if present for JDK 8 tests). When using Java code instead of shell scripts, you can look to libraries in the various test suites for suggestions on useful methods to provide, such as invoking generating and compiling source code, providing simple equivalents for regex search (simple grep), comparison (simple diff), etc, as well as support for running subprocesses when necessary. One common pattern is to use Java code to validate whether it is appropriate to run a test in the current configuration and to then launch a JVM with a selected combination of options. This sort of mode has explicit support in jtreg: "@run driver" is similar to "@run main" for running a class, but it is not run with any JVM options intended for test JVMs. This makes it suitable for running "test driver" classes which spawn JVMs to run the "real" test code. And if you're just writing API tests, then I recommend using plain old Java code and "agentvm" mode to have the tests as fast as possible. -- Jon On 12/05/2017 02:01 AM, Jiri Vanek wrote: > Hi Jonathan! > > I think this proposal have quite a sense. I was moving our old jtreg > tests to work with jdk9 too, and copy pasting on module level is > terrible. > > This proposal is cool. It is keeping encapsulation in place and > lowering the writing a lot. > I would go even more deep, eg " @modules all-needed", and jtreg will > deduct necessary --add-whatever on its own. > > The shell part is even more worse. And especially the shell part is > where jtreg is hard to replace (read: I like jtreg here very much :) ) > Here you get only TESTMODULES variable which is not enough, and > (unlike in java file) it is here even for jdk8 and older. > So maybe there can be one more variable, containing full > --add-whatever string which got filled only for modular jdk? > > I will be happy to implement those features if you agree with the > principle. > > > Thanx! > J. > > > > On 11/30/2017 02:21 PM, Miloslav Zezulka wrote: >> Hello, >> >> when working with @modules tag, it might be sometimes beneficial to have >> the ability to open multiple packages from the same parent using one >> @modules tag only (for example via star notation as in regular java >> imports). The idea came to my mind when modifying some CPU >> reproducers to >> be compatible with JDK9. Let's consider a JTreg comment for one of them: >> >> * .... >> * @modules java.security.jgss/sun.security.krb5.internal >> * @modules java.security.jgss/sun.security.krb5.internal.ccache >> * @modules java.security.jgss/sun.security.krb5.internal.crypto >> * @modules java.security.jgss/sun.security.krb5.internal.ktab >> * @modules java.base/sun.security.util >> * @modules java.security.jgss/sun.security.jgss >> */ >> >> Although this has the advantage thta we explicitly know which internal >> packages are being opened for the given test, someone might prefer to >> use >> the @modules tag the folllowing way to make the JTreg comment more >> readable >> and less wordier: >> >> * .... >> * @modules java.security.jgss/sun.security.krb5.internal.* >> * @modules java.base/sun.security.util >> * @modules java.security.jgss/sun.security.jgss >> */ >> >> As a JTreg newbie, I wasn't able to find such feature in the current >> version. The attached patch is a draft of how this might be implemented. >> >> Thoughts? >> >> Thanks, >> M?la >> > > From jonathan.gibbons at oracle.com Thu Dec 14 00:32:31 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 13 Dec 2017 16:32:31 -0800 Subject: CODETOOLS-7902083: Simplify building jtreg Message-ID: <5A31C69F.4090800@oracle.com> This is for folk who are interested in building jtreg from source. As some of you have (rightfully) commented over the past years, jtreg has not been an easy tool to build from source. And, as some of you may have noticed, there has been some amount of activity over the past weeks and months to address this issue. This work has been led by Erik Helin (thanks, Erik!) and we're now getting to the point where we can show what we have been working towards. The core of the work to build jtreg is still the Makefiles as before, although as was recently noted, we've been simplifying the specification of the dependencies. Separately, Erik has helped provide updates to the way that some of the Code Tools dependencies can be built. Building on all that work, we can now get to the next stage, to provide a script that will download binaries for some components (JUnit, TestNG) and will download and build source for other components (AsmTools, JCov, JTHarness), for which there are no official binaries. To run the script, you just need to have Ant and a suitable "java" on your path, and to specify the location of an install of JDK 1.8 as an argument to the script. wget is used to download files, which honors proxy settings for those that need to use them. The script is deliberately fairly simple, and suitable for use in a CI system. You can see a webrev for the script at http://cr.openjdk.java.net/~jjg/7902083/webrev.00/ Example of use: $ which ant /opt/ant/1.9.4/bin/ant $ which java /opt/jdk/1.8.0/bin/java $ sh make/build-all.sh /opt/jdk/1.8.0 ... build output ... $ ls build/images/jtreg bin COPYRIGHT doc legal lib LICENSE README release $ Once this settles down a bit, I'll update the public docs on the jtreg web pages. -- Jon From stuart.monteith at linaro.org Thu Dec 14 13:19:42 2017 From: stuart.monteith at linaro.org (Stuart Monteith) Date: Thu, 14 Dec 2017 13:19:42 +0000 Subject: CODETOOLS-7902083: Simplify building jtreg In-Reply-To: <5A31C69F.4090800@oracle.com> References: <5A31C69F.4090800@oracle.com> Message-ID: Thanks for this Jonathan, This will simplify my automation greatly. The script looks fine to me and tests fine on my Ubuntu 17.10 x86 system and Ubuntu 14.04 aarch64 system. BR, Stuart On 14 December 2017 at 00:32, Jonathan Gibbons wrote: > This is for folk who are interested in building jtreg from source. > > As some of you have (rightfully) commented over the past years, jtreg has > not been an easy tool to build from source. > > And, as some of you may have noticed, there has been some amount of activity > over the past weeks and months to address this issue. This work has been led > by Erik Helin (thanks, Erik!) and we're now getting to the point where we > can show what we have been working towards. > > The core of the work to build jtreg is still the Makefiles as before, > although as was recently noted, we've been simplifying the specification of > the dependencies. > > Separately, Erik has helped provide updates to the way that some of the Code > Tools dependencies can be built. > > Building on all that work, we can now get to the next stage, to provide a > script that will download binaries for some components (JUnit, TestNG) and > will download and build source for other components (AsmTools, JCov, > JTHarness), for which there are no official binaries. > > To run the script, you just need to have Ant and a suitable "java" on your > path, and to specify the location of an install of JDK 1.8 as an argument to > the script. wget is used to download files, which honors proxy settings for > those that need to use them. The script is deliberately fairly simple, and > suitable for use in a CI system. > > You can see a webrev for the script at > http://cr.openjdk.java.net/~jjg/7902083/webrev.00/ > > Example of use: > > $ which ant > /opt/ant/1.9.4/bin/ant > $ which java > /opt/jdk/1.8.0/bin/java > $ sh make/build-all.sh /opt/jdk/1.8.0 > ... build output ... > $ ls build/images/jtreg > bin COPYRIGHT doc legal lib LICENSE README release > $ > > > Once this settles down a bit, I'll update the public docs on the jtreg web > pages. > > -- Jon > > From jvanek at redhat.com Thu Dec 14 15:56:32 2017 From: jvanek at redhat.com (Jiri Vanek) Date: Thu, 14 Dec 2017 16:56:32 +0100 Subject: RFC: add starred module(s) In-Reply-To: <5A2B418E.9000607@oracle.com> References: <5A2B418E.9000607@oracle.com> Message-ID: Hi Jonathan! Thank you very much for great answer. Few remarks inline. On 12/09/2017 02:51 AM, Jonathan Gibbons wrote: > Jiri, Mila, > > There are three significant questions here. > > 1. @modules all-needed > > This is a non-starter. @modules participates in a relatively light-weight test selection mechanism Sure. It is last step, if it will be ever started. > ... i.e. tests are not selected if the specified modules are not available in the system image. > Having jtreg analyse the source code to determine the set of necessary modules is just not practical. > > 2. Starred modules, as in @modules java.security.jgss/sun.security.krb5.internal.* > > Setting aside whether this is desirable or not, this is not necessarily an easy thing to do. It > requires that we can list the (internal) packages of a module. Yes, there may be a attribute that > provides the info, but the attribute is not guaranteed to be available, and if it's not, you're terrible truth. see at bottom. > reduced to scanning the module contents. On the desirability point of view, the use of this sort of > syntax was discussed, and rejected, for module declarations, and while that is separate from what is I was reading most of this discussion, and I can agree with it for final deployment, but not for testing. > proposed here, it does lend guidance. Neither is the '*' syntax supported by the options for the > Java launcher or javac, and this construct is intended to be a thinly-veiled wrapper for those options. This is probably the only sentence I moreover disagree with you. Jtreg is far away fro being tinny wrapper, and it always did huge help for tests authors. So helping testers with setting up module path a bit, may be good step. > > One minor comment ... you can reduce the "wordiness" of your examples by almost 50% by just having a > single @modules directive with many arg values, possibly spanning many lines, as in ... > > * .... > * @modules java.security.jgss/sun.security.krb5.internal > * java.security.jgss/sun.security.krb5.internal.ccache > * java.security.jgss/sun.security.krb5.internal.crypto > * java.security.jgss/sun.security.krb5.internal.ktab > * java.base/sun.security.util > * java.security.jgss/sun.security.jgss Still you need to enumerate them all. That mean to run javac and jmod in loops one by one, untill you get collect them. > > 3. Shell scripts. > > Using shell scripts for jtreg tests is generally discouraged, these days, to the point that we have > made efforts to convert many/most JDK shell tests to Java code. The general experience was that such > tests were very fragile, and were often wrong/broken. They typically execute slower than equivalent > Java code, especially when using libraries providing commonly-used or domain-specific functionality. Well, shell lunchers have theirs dark sides, thats right. But are awesome feature without replacement. > And as you note below, processing variables like TESTMODULES is problematic. (It is a bug if present > for JDK 8 tests). Its a bug :) > > When using Java code instead of shell scripts, you can look to libraries in the various test suites > for suggestions on useful methods to provide, such as invoking generating and compiling source code, > providing simple equivalents for regex search (simple grep), comparison (simple diff), etc, as well > as support for running subprocesses when necessary. One common pattern is to use Java code to > validate whether it is appropriate to run a test in the current configuration and to then launch a > JVM with a selected combination of options. This sort of mode has explicit support in jtreg: "@run > driver" is similar to "@run main" for running a class, but it is not run with any JVM options > intended for test JVMs. This makes it suitable for running "test driver" classes which spawn JVMs to > run the "real" test code. And if you're just writing API tests, then I recommend using plain old > Java code and "agentvm" mode to have the tests as fast as possible. You are mostly right. But consider this: The locating of modules is painful when you are dealing with private apis. And that is what you do in jtregs for half of the time... So naturally, the help would be easy. On contrary, the help do not come from JDK itself in any "supported" way (or am I missing something?) Still the javac can do so. So it would be natural to enahnce javac to help with this a bit more via some more solid api. Maybe you know something here? One would say, that writing private api jtreg is one or two modules usage only. Unluckily, oposite is true, and Mila's * idea is another proof of it. And If I look to past to my recent work, I was facing the same. Just got angry later. So generally - some help should be provided in JDK to deal with it. And as JDK looks to have its reasons to not to do so, Jtregs should. Thanx for again for your reply! J. From jonathan.gibbons at oracle.com Thu Dec 14 17:03:15 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 14 Dec 2017 09:03:15 -0800 Subject: CODETOOLS-7902083: Simplify building jtreg In-Reply-To: References: <5A31C69F.4090800@oracle.com> Message-ID: To be clear, the majority of the credit for this goes to Erik. :-) But thanks to you for checking out the script. I'll push it to the repo soon, and we can tweak/evolve it there as needed. -- Jon On 12/14/17 5:19 AM, Stuart Monteith wrote: > Thanks for this Jonathan, > This will simplify my automation greatly. The script looks fine to > me and tests fine on my Ubuntu 17.10 x86 system and Ubuntu 14.04 > aarch64 system. > > BR, > Stuart > > On 14 December 2017 at 00:32, Jonathan Gibbons > wrote: >> This is for folk who are interested in building jtreg from source. >> >> As some of you have (rightfully) commented over the past years, jtreg has >> not been an easy tool to build from source. >> >> And, as some of you may have noticed, there has been some amount of activity >> over the past weeks and months to address this issue. This work has been led >> by Erik Helin (thanks, Erik!) and we're now getting to the point where we >> can show what we have been working towards. >> >> The core of the work to build jtreg is still the Makefiles as before, >> although as was recently noted, we've been simplifying the specification of >> the dependencies. >> >> Separately, Erik has helped provide updates to the way that some of the Code >> Tools dependencies can be built. >> >> Building on all that work, we can now get to the next stage, to provide a >> script that will download binaries for some components (JUnit, TestNG) and >> will download and build source for other components (AsmTools, JCov, >> JTHarness), for which there are no official binaries. >> >> To run the script, you just need to have Ant and a suitable "java" on your >> path, and to specify the location of an install of JDK 1.8 as an argument to >> the script. wget is used to download files, which honors proxy settings for >> those that need to use them. The script is deliberately fairly simple, and >> suitable for use in a CI system. >> >> You can see a webrev for the script at >> http://cr.openjdk.java.net/~jjg/7902083/webrev.00/ >> >> Example of use: >> >> $ which ant >> /opt/ant/1.9.4/bin/ant >> $ which java >> /opt/jdk/1.8.0/bin/java >> $ sh make/build-all.sh /opt/jdk/1.8.0 >> ... build output ... >> $ ls build/images/jtreg >> bin COPYRIGHT doc legal lib LICENSE README release >> $ >> >> >> Once this settles down a bit, I'll update the public docs on the jtreg web >> pages. >> >> -- Jon >> >> From jonathan.gibbons at oracle.com Thu Dec 14 22:09:46 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 14 Dec 2017 14:09:46 -0800 Subject: RFC: add starred module(s) In-Reply-To: References: <5A2B418E.9000607@oracle.com> Message-ID: <5A32F6AA.3060102@oracle.com> Jiri, I have read all your comments. I don't think it helps to respond on a line by line basis, and so instead, I will say this ... I am sympathetic to the problem of the complexity of configuring individual tests, and it will come as no surprise to anyone that we have encountered some of those same problems as well, writing tests for JDK. But, I want to separate the issue of determining the appropriate content for @modules from the syntactic presentation of that content. In the discussions we've had regarding the addition of @modules for all the existing JDK tests, we have focused more on providing and using tools to analyse a test and suggest possible entries for @modules. This analysis is more than can reasonably be done on the fly by jtreg, involving tools like jdeprscan, and running tests in minimal JVMs with just the listed modules. For example, as well as verifying that we have enough entries in @modules, we also want to make sure we don't have any unnecessary entries, which might preclude running the test on a smaller JVM (because of an advertised dependence on module that is not actually required for the test to execute successfully.) In addition, we also want to write negative tests, such as being able to test the behavior of the system when modules A, B and C are present, but not modules D, E, and F ... even if there are references to those modules in the code. The bottom line is that I do not think it is appropriate to much too much smarts into jtreg to infer more than it is already doing. It's already close to being too complicated, which is why we added the "Configuration" section in the output (.jtr) file, to help users verify the setup being provided by jtreg. But maybe we can address the general need by focussing on providing better lint-like tools for validating the module setup for a test. And, if we have tools like that, then the presentation issues, such as wildcard entries in test descriptions, becomes less important. -- Jon On 12/14/2017 07:56 AM, Jiri Vanek wrote: > Hi Jonathan! > > Thank you very much for great answer. Few remarks inline. > > > On 12/09/2017 02:51 AM, Jonathan Gibbons wrote: >> Jiri, Mila, >> >> There are three significant questions here. >> >> 1. @modules all-needed >> >> This is a non-starter. @modules participates in a relatively >> light-weight test selection mechanism > > Sure. It is last step, if it will be ever started. > >> ... i.e. tests are not selected if the specified modules are not >> available in the system image. Having jtreg analyse the source code >> to determine the set of necessary modules is just not practical. >> >> 2. Starred modules, as in @modules >> java.security.jgss/sun.security.krb5.internal.* >> >> Setting aside whether this is desirable or not, this is not >> necessarily an easy thing to do. It requires that we can list the >> (internal) packages of a module. Yes, there may be a attribute that >> provides the info, but the attribute is not guaranteed to be >> available, and if it's not, you're > terrible truth. see at bottom. > >> reduced to scanning the module contents. On the desirability point of >> view, the use of this sort of syntax was discussed, and rejected, for >> module declarations, and while that is separate from what is > > I was reading most of this discussion, and I can agree with it for > final deployment, but not for testing. >> proposed here, it does lend guidance. Neither is the '*' syntax >> supported by the options for the Java launcher or javac, and this >> construct is intended to be a thinly-veiled wrapper for those options. > > This is probably the only sentence I moreover disagree with you. Jtreg > is far away fro being tinny wrapper, and it always did huge help for > tests authors. So helping testers with setting up module path a bit, > may be good step. >> >> One minor comment ... you can reduce the "wordiness" of your examples >> by almost 50% by just having a single @modules directive with many >> arg values, possibly spanning many lines, as in ... >> >> * .... >> * @modules java.security.jgss/sun.security.krb5.internal >> * java.security.jgss/sun.security.krb5.internal.ccache >> * java.security.jgss/sun.security.krb5.internal.crypto >> * java.security.jgss/sun.security.krb5.internal.ktab >> * java.base/sun.security.util >> * java.security.jgss/sun.security.jgss > > Still you need to enumerate them all. That mean to run javac and jmod > in loops one by one, untill you get collect them. >> >> 3. Shell scripts. >> >> Using shell scripts for jtreg tests is generally discouraged, these >> days, to the point that we have made efforts to convert many/most JDK >> shell tests to Java code. The general experience was that such tests >> were very fragile, and were often wrong/broken. They typically >> execute slower than equivalent Java code, especially when using >> libraries providing commonly-used or domain-specific functionality. > > Well, shell lunchers have theirs dark sides, thats right. But are > awesome feature without replacement. >> And as you note below, processing variables like TESTMODULES is >> problematic. (It is a bug if present for JDK 8 tests). > > Its a bug :) >> >> When using Java code instead of shell scripts, you can look to >> libraries in the various test suites for suggestions on useful >> methods to provide, such as invoking generating and compiling source >> code, providing simple equivalents for regex search (simple grep), >> comparison (simple diff), etc, as well as support for running >> subprocesses when necessary. One common pattern is to use Java code >> to validate whether it is appropriate to run a test in the current >> configuration and to then launch a JVM with a selected combination of >> options. This sort of mode has explicit support in jtreg: "@run >> driver" is similar to "@run main" for running a class, but it is not >> run with any JVM options intended for test JVMs. This makes it >> suitable for running "test driver" classes which spawn JVMs to run >> the "real" test code. And if you're just writing API tests, then I >> recommend using plain old Java code and "agentvm" mode to have the >> tests as fast as possible. > > > You are mostly right. But consider this: The locating of modules is > painful when you are dealing with private apis. And that is what you > do in jtregs for half of the time... > So naturally, the help would be easy. > On contrary, the help do not come from JDK itself in any "supported" > way (or am I missing something?) > Still the javac can do so. So it would be natural to enahnce javac to > help with this a bit more via some more solid api. Maybe you know > something here? > > One would say, that writing private api jtreg is one or two modules > usage only. Unluckily, oposite is true, and Mila's * idea is another > proof of it. And If I look to past to my recent work, I was facing the > same. Just got angry later. > > > So generally - some help should be provided in JDK to deal with it. > And as JDK looks to have its reasons to not to do so, Jtregs should. > > > Thanx for again for your reply! > J. > > > > > > > From mzezulka at redhat.com Fri Dec 15 10:37:51 2017 From: mzezulka at redhat.com (Miloslav Zezulka) Date: Fri, 15 Dec 2017 11:37:51 +0100 Subject: Bugfix: do not set TESTMODULES environment variable if JDK is not modular Message-ID: This is a very small patch fixing the issue pointed out in $subject. I've added checks for both compile and test JDK - is this an overkill, since most of the time the implication goes COMPILEJDK.modular => TESTJDK.modular, or a necessary thing to have for foolproofness? Please let me know what you think. Thanks, Mila -------------- next part -------------- A non-text attachment was scrubbed... Name: jtregTESTMODULES.patch Type: text/x-patch Size: 837 bytes Desc: not available URL: From jonathan.gibbons at oracle.com Fri Dec 15 22:21:57 2017 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Fri, 15 Dec 2017 22:21:57 +0000 Subject: hg: code-tools/jtreg: 2 new changesets Message-ID: <201712152221.vBFMLva6000611@aojmv0008.oracle.com> Changeset: 547570a0dd3b Author: jjg Date: 2017-12-15 14:15 -0800 URL: http://hg.openjdk.java.net/code-tools/jtreg/rev/547570a0dd3b fix test for when jcommander.jar is used ! test/rerun/RerunTest.gmk Changeset: 48096bc3d911 Author: jjg Date: 2017-12-15 14:17 -0800 URL: http://hg.openjdk.java.net/code-tools/jtreg/rev/48096bc3d911 7902083: Simplify building jtreg Contributed-by: erik.helin at oracle.com + make/build-all.sh From jonathan.gibbons at oracle.com Fri Dec 15 22:34:26 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 15 Dec 2017 14:34:26 -0800 Subject: CODETOOLS-7902083: Simplify building jtreg In-Reply-To: <5A31C69F.4090800@oracle.com> References: <5A31C69F.4090800@oracle.com> Message-ID: <5A344DF2.7060103@oracle.com> I've pushed the changeset containing this new script. There are two changes since I posted the webrev: 1. Change to use "shasum -a 1" instead of "sha1sum" 2. Update script to download and use jcommander.jar in conjunction with TestNG. With the second change in particular, all the jtreg self-tests pass, when the image is built with the build-all.sh script. -- Jon On 12/13/2017 04:32 PM, Jonathan Gibbons wrote: > This is for folk who are interested in building jtreg from source. > > As some of you have (rightfully) commented over the past years, jtreg > has not been an easy tool to build from source. > > And, as some of you may have noticed, there has been some amount of > activity over the past weeks and months to address this issue. This > work has been led by Erik Helin (thanks, Erik!) and we're now getting > to the point where we can show what we have been working towards. > > The core of the work to build jtreg is still the Makefiles as before, > although as was recently noted, we've been simplifying the > specification of the dependencies. > > Separately, Erik has helped provide updates to the way that some of > the Code Tools dependencies can be built. > > Building on all that work, we can now get to the next stage, to > provide a script that will download binaries for some components > (JUnit, TestNG) and will download and build source for other > components (AsmTools, JCov, JTHarness), for which there are no > official binaries. > > To run the script, you just need to have Ant and a suitable "java" on > your path, and to specify the location of an install of JDK 1.8 as an > argument to the script. wget is used to download files, which honors > proxy settings for those that need to use them. The script is > deliberately fairly simple, and suitable for use in a CI system. > > You can see a webrev for the script at > http://cr.openjdk.java.net/~jjg/7902083/webrev.00/ > > Example of use: > > $ which ant > /opt/ant/1.9.4/bin/ant > $ which java > /opt/jdk/1.8.0/bin/java > $ sh make/build-all.sh /opt/jdk/1.8.0 > ... build output ... > $ ls build/images/jtreg > bin COPYRIGHT doc legal lib LICENSE README release > $ > > > Once this settles down a bit, I'll update the public docs on the jtreg > web pages. > > -- Jon > > From jonathan.gibbons at oracle.com Fri Dec 15 22:45:11 2017 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Fri, 15 Dec 2017 22:45:11 +0000 Subject: hg: code-tools/jtreg: add support for upcoming JDK versions Message-ID: <201712152245.vBFMjBCw005947@aojmv0008.oracle.com> Changeset: 3f8c7383348c Author: jjg Date: 2017-12-15 14:40 -0800 URL: http://hg.openjdk.java.net/code-tools/jtreg/rev/3f8c7383348c add support for upcoming JDK versions ! src/share/classes/com/sun/javatest/regtest/agent/JDK_Version.java From sadhak001 at gmail.com Sat Dec 16 02:32:02 2017 From: sadhak001 at gmail.com (Mani Sarkar) Date: Sat, 16 Dec 2017 02:32:02 +0000 Subject: CODETOOLS-7902083: Simplify building jtreg In-Reply-To: <5A344DF2.7060103@oracle.com> References: <5A31C69F.4090800@oracle.com> <5A344DF2.7060103@oracle.com> Message-ID: Great, thanks! Will incorporate it with our build scripts on the adopt openjdk build farm. On Fri, 15 Dec 2017 22:34 Jonathan Gibbons, wrote: > I've pushed the changeset containing this new script. > > There are two changes since I posted the webrev: > > 1. Change to use "shasum -a 1" instead of "sha1sum" > 2. Update script to download and use jcommander.jar in conjunction with > TestNG. > > With the second change in particular, all the jtreg self-tests pass, > when the image is built with the build-all.sh script. > > -- Jon > > On 12/13/2017 04:32 PM, Jonathan Gibbons wrote: > > This is for folk who are interested in building jtreg from source. > > > > As some of you have (rightfully) commented over the past years, jtreg > > has not been an easy tool to build from source. > > > > And, as some of you may have noticed, there has been some amount of > > activity over the past weeks and months to address this issue. This > > work has been led by Erik Helin (thanks, Erik!) and we're now getting > > to the point where we can show what we have been working towards. > > > > The core of the work to build jtreg is still the Makefiles as before, > > although as was recently noted, we've been simplifying the > > specification of the dependencies. > > > > Separately, Erik has helped provide updates to the way that some of > > the Code Tools dependencies can be built. > > > > Building on all that work, we can now get to the next stage, to > > provide a script that will download binaries for some components > > (JUnit, TestNG) and will download and build source for other > > components (AsmTools, JCov, JTHarness), for which there are no > > official binaries. > > > > To run the script, you just need to have Ant and a suitable "java" on > > your path, and to specify the location of an install of JDK 1.8 as an > > argument to the script. wget is used to download files, which honors > > proxy settings for those that need to use them. The script is > > deliberately fairly simple, and suitable for use in a CI system. > > > > You can see a webrev for the script at > > http://cr.openjdk.java.net/~jjg/7902083/webrev.00/ > > > > Example of use: > > > > $ which ant > > /opt/ant/1.9.4/bin/ant > > $ which java > > /opt/jdk/1.8.0/bin/java > > $ sh make/build-all.sh /opt/jdk/1.8.0 > > ... build output ... > > $ ls build/images/jtreg > > bin COPYRIGHT doc legal lib LICENSE README release > > $ > > > > > > Once this settles down a bit, I'll update the public docs on the jtreg > > web pages. > > > > -- Jon > > > > > > -- @theNeomatrix369 | Blog | @adoptopenjdk | Dev communities Meet-a-Project - MutabilityDetector | Github | Slideshare | LinkedIn Come to Devoxx UK 2018: http://www.devoxx.co.uk/ Don't chase success, rather aim for "Excellence", and success will come chasing after you! From martinrb at google.com Sat Dec 16 17:55:08 2017 From: martinrb at google.com (Martin Buchholz) Date: Sat, 16 Dec 2017 09:55:08 -0800 Subject: CODETOOLS-7902083: Simplify building jtreg In-Reply-To: <5A344DF2.7060103@oracle.com> References: <5A31C69F.4090800@oracle.com> <5A344DF2.7060103@oracle.com> Message-ID: testng-6.9.5 was packaged poorly, with jdk8 classfiles. testng-6.9.8 had different packaging problems. testng-6.9.9 is golden, with jdk7 class files. (of course, there are also more recent testng versions) --- a/make/build-all.sh +++ b/make/build-all.sh @@ -172,12 +172,12 @@ TESTNG_DEPS_DIR=${JTREG_DEPS_DIR}/testng mkdir ${TESTNG_DEPS_DIR} -TESTNG_JAR=${TESTNG_DEPS_DIR}/testng-6.9.5.jar -wget ${MAVEN_REPO_URL}/org/testng/testng/6.9.5/testng-6.9.5.jar -O ${TESTNG_JAR} -printf "5d12ea207fc47c3f341a3f8ecc88a3eac396a777 ${TESTNG_JAR}" | shasum -a 1 --check - +TESTNG_JAR=${TESTNG_DEPS_DIR}/testng-6.9.9.jar +wget ${MAVEN_REPO_URL}/org/testng/testng/6.9.9/testng-6.9.9.jar -O ${TESTNG_JAR} +printf "8b211c4c5bed389e169a2173da32d07f93ee2fa8 ${TESTNG_JAR}" | shasum -a 1 --check - TESTNG_LICENSE=${TESTNG_DEPS_DIR}/LICENSE.txt -wget https://raw.githubusercontent.com/cbeust/testng/testng-6.9.5/LICENSE.txt -O ${TESTNG_LICENSE} +wget https://raw.githubusercontent.com/cbeust/testng/6.9.9/LICENSE.txt -O ${TESTNG_LICENSE} JCOMMANDER_JAR=${TESTNG_DEPS_DIR}/jcommander-1.72.jar wget ${MAVEN_REPO_URL}/com/beust/jcommander/1.72/jcommander-1.72.jar -O ${JCOMMANDER_JAR} On Fri, Dec 15, 2017 at 2:34 PM, Jonathan Gibbons < jonathan.gibbons at oracle.com> wrote: > I've pushed the changeset containing this new script. > > There are two changes since I posted the webrev: > > 1. Change to use "shasum -a 1" instead of "sha1sum" > 2. Update script to download and use jcommander.jar in conjunction with > TestNG. > > With the second change in particular, all the jtreg self-tests pass, when > the image is built with the build-all.sh script. > > -- Jon > > > On 12/13/2017 04:32 PM, Jonathan Gibbons wrote: > >> This is for folk who are interested in building jtreg from source. >> >> As some of you have (rightfully) commented over the past years, jtreg has >> not been an easy tool to build from source. >> >> And, as some of you may have noticed, there has been some amount of >> activity over the past weeks and months to address this issue. This work >> has been led by Erik Helin (thanks, Erik!) and we're now getting to the >> point where we can show what we have been working towards. >> >> The core of the work to build jtreg is still the Makefiles as before, >> although as was recently noted, we've been simplifying the specification of >> the dependencies. >> >> Separately, Erik has helped provide updates to the way that some of the >> Code Tools dependencies can be built. >> >> Building on all that work, we can now get to the next stage, to provide a >> script that will download binaries for some components (JUnit, TestNG) and >> will download and build source for other components (AsmTools, JCov, >> JTHarness), for which there are no official binaries. >> >> To run the script, you just need to have Ant and a suitable "java" on >> your path, and to specify the location of an install of JDK 1.8 as an >> argument to the script. wget is used to download files, which honors proxy >> settings for those that need to use them. The script is deliberately fairly >> simple, and suitable for use in a CI system. >> >> You can see a webrev for the script at >> http://cr.openjdk.java.net/~jjg/7902083/webrev.00/ >> >> Example of use: >> >> $ which ant >> /opt/ant/1.9.4/bin/ant >> $ which java >> /opt/jdk/1.8.0/bin/java >> $ sh make/build-all.sh /opt/jdk/1.8.0 >> ... build output ... >> $ ls build/images/jtreg >> bin COPYRIGHT doc legal lib LICENSE README release >> $ >> >> >> Once this settles down a bit, I'll update the public docs on the jtreg >> web pages. >> >> -- Jon >> >> >> > From martinrb at google.com Sat Dec 16 18:51:48 2017 From: martinrb at google.com (Martin Buchholz) Date: Sat, 16 Dec 2017 10:51:48 -0800 Subject: CODETOOLS-7902083: Simplify building jtreg In-Reply-To: References: <5A31C69F.4090800@oracle.com> <5A344DF2.7060103@oracle.com> Message-ID: Thanks for working on this. I've written similar scripts to gather up all dependencies and build. I suggest using wget's -q flag. I suggest creating little shell subroutines to check the checksums (which print the actual checksum in case of mismatch) and to download maven jars. Here's some random shell code I've written that could get reused: def_make_var() { typeset -n varref="$1" varref="$2" MAKE_FLAGS+=("$1=$2") } def_make_file() { [[ -f "$2" ]] || die "%s: no such file" "$2" def_make_var "$@" } def_make_dir() { [[ -d "$2" ]] || die "%s: no such directory" "$2" def_make_var "$@" } download_maven_jar() { local -r groupId="$1" artifactId="$2" version="$3" local -r jarfile="${artifactId}-${version}.jar" wget -qO"/tmp/$jarfile" \ " http://search.maven.org/remotecontent?filepath=${groupId}/${artifactId}/${version}/${jarfile} " def_make_file "${artifactId^^}_JAR" "/tmp/$jarfile" DOWNLOADED_MAVEN_JARS+=("/tmp/$jarfile") } On Sat, Dec 16, 2017 at 9:55 AM, Martin Buchholz wrote: > testng-6.9.5 was packaged poorly, with jdk8 classfiles. > testng-6.9.8 had different packaging problems. > testng-6.9.9 is golden, with jdk7 class files. > (of course, there are also more recent testng versions) > > --- a/make/build-all.sh > +++ b/make/build-all.sh > @@ -172,12 +172,12 @@ > TESTNG_DEPS_DIR=${JTREG_DEPS_DIR}/testng > mkdir ${TESTNG_DEPS_DIR} > > -TESTNG_JAR=${TESTNG_DEPS_DIR}/testng-6.9.5.jar > -wget ${MAVEN_REPO_URL}/org/testng/testng/6.9.5/testng-6.9.5.jar -O > ${TESTNG_JAR} > -printf "5d12ea207fc47c3f341a3f8ecc88a3eac396a777 ${TESTNG_JAR}" | > shasum -a 1 --check - > +TESTNG_JAR=${TESTNG_DEPS_DIR}/testng-6.9.9.jar > +wget ${MAVEN_REPO_URL}/org/testng/testng/6.9.9/testng-6.9.9.jar -O > ${TESTNG_JAR} > +printf "8b211c4c5bed389e169a2173da32d07f93ee2fa8 ${TESTNG_JAR}" | > shasum -a 1 --check - > > TESTNG_LICENSE=${TESTNG_DEPS_DIR}/LICENSE.txt > -wget https://raw.githubusercontent.com/cbeust/testng/testng-6.9. > 5/LICENSE.txt -O ${TESTNG_LICENSE} > +wget https://raw.githubusercontent.com/cbeust/testng/6.9.9/LICENSE.txt > -O ${TESTNG_LICENSE} > > JCOMMANDER_JAR=${TESTNG_DEPS_DIR}/jcommander-1.72.jar > wget ${MAVEN_REPO_URL}/com/beust/jcommander/1.72/jcommander-1.72.jar -O > ${JCOMMANDER_JAR} > > > On Fri, Dec 15, 2017 at 2:34 PM, Jonathan Gibbons < > jonathan.gibbons at oracle.com> wrote: > >> I've pushed the changeset containing this new script. >> >> There are two changes since I posted the webrev: >> >> 1. Change to use "shasum -a 1" instead of "sha1sum" >> 2. Update script to download and use jcommander.jar in conjunction with >> TestNG. >> >> With the second change in particular, all the jtreg self-tests pass, when >> the image is built with the build-all.sh script. >> >> -- Jon >> >> >> On 12/13/2017 04:32 PM, Jonathan Gibbons wrote: >> >>> This is for folk who are interested in building jtreg from source. >>> >>> As some of you have (rightfully) commented over the past years, jtreg >>> has not been an easy tool to build from source. >>> >>> And, as some of you may have noticed, there has been some amount of >>> activity over the past weeks and months to address this issue. This work >>> has been led by Erik Helin (thanks, Erik!) and we're now getting to the >>> point where we can show what we have been working towards. >>> >>> The core of the work to build jtreg is still the Makefiles as before, >>> although as was recently noted, we've been simplifying the specification of >>> the dependencies. >>> >>> Separately, Erik has helped provide updates to the way that some of the >>> Code Tools dependencies can be built. >>> >>> Building on all that work, we can now get to the next stage, to provide >>> a script that will download binaries for some components (JUnit, TestNG) >>> and will download and build source for other components (AsmTools, JCov, >>> JTHarness), for which there are no official binaries. >>> >>> To run the script, you just need to have Ant and a suitable "java" on >>> your path, and to specify the location of an install of JDK 1.8 as an >>> argument to the script. wget is used to download files, which honors proxy >>> settings for those that need to use them. The script is deliberately fairly >>> simple, and suitable for use in a CI system. >>> >>> You can see a webrev for the script at >>> http://cr.openjdk.java.net/~jjg/7902083/webrev.00/ >>> >>> Example of use: >>> >>> $ which ant >>> /opt/ant/1.9.4/bin/ant >>> $ which java >>> /opt/jdk/1.8.0/bin/java >>> $ sh make/build-all.sh /opt/jdk/1.8.0 >>> ... build output ... >>> $ ls build/images/jtreg >>> bin COPYRIGHT doc legal lib LICENSE README release >>> $ >>> >>> >>> Once this settles down a bit, I'll update the public docs on the jtreg >>> web pages. >>> >>> -- Jon >>> >>> >>> >> > From jonathan.gibbons at oracle.com Sun Dec 17 20:17:13 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Sun, 17 Dec 2017 12:17:13 -0800 Subject: CODETOOLS-7902083: Simplify building jtreg In-Reply-To: References: <5A31C69F.4090800@oracle.com> <5A344DF2.7060103@oracle.com> Message-ID: <3595a6a0-073c-90aa-c8ba-f37e24364e7c@oracle.com> Martin, Thanks for the feedback and suggestions. I'll look at incorporating the scripting changes, and will separately investigate moving jtreg onto newer versions of external components. -- Jon On 12/16/17 10:51 AM, Martin Buchholz wrote: > Thanks for working on this.? I've written similar scripts to gather up > all dependencies and build. > > I suggest using wget's -q flag. > > I suggest creating little shell subroutines to check the checksums > (which print the actual checksum in case of mismatch) and to download > maven jars. > > Here's some random shell code I've written that could get reused: > > def_make_var() { > ? typeset -n varref="$1" > ? varref="$2" > ? MAKE_FLAGS+=("$1=$2") > } > > def_make_file() { > ? [[ -f "$2" ]] || die "%s: no such file" "$2" > ? def_make_var "$@" > } > > def_make_dir() { > ? [[ -d "$2" ]] || die "%s: no such directory" "$2" > ? def_make_var "$@" > } > > download_maven_jar() { > ? local -r groupId="$1" artifactId="$2" version="$3" > ? local -r jarfile="${artifactId}-${version}.jar" > ? wget -qO"/tmp/$jarfile" \ > ? ? > "http://search.maven.org/remotecontent?filepath=${groupId}/${artifactId}/${version}/${jarfile} > " > ? def_make_file "${artifactId^^}_JAR" "/tmp/$jarfile" > ? DOWNLOADED_MAVEN_JARS+=("/tmp/$jarfile") > } > > > > On Sat, Dec 16, 2017 at 9:55 AM, Martin Buchholz > wrote: > > testng-6.9.5 was packaged poorly, with jdk8 classfiles. > testng-6.9.8 had different packaging problems. > testng-6.9.9 is golden, with jdk7 class files. > (of course, there are also more recent testng versions) > > --- a/make/build-all.sh > +++ b/make/build-all.sh > @@ -172,12 +172,12 @@ > ?TESTNG_DEPS_DIR=${JTREG_DEPS_DIR}/testng > ?mkdir ${TESTNG_DEPS_DIR} > -TESTNG_JAR=${TESTNG_DEPS_DIR}/testng-6.9.5.jar > -wget ${MAVEN_REPO_URL}/org/testng/testng/6.9.5/testng-6.9.5.jar > -O ${TESTNG_JAR} > -printf "5d12ea207fc47c3f341a3f8ecc88a3eac396a777 ${TESTNG_JAR}" | > shasum -a 1 --check - > +TESTNG_JAR=${TESTNG_DEPS_DIR}/testng-6.9.9.jar > +wget ${MAVEN_REPO_URL}/org/testng/testng/6.9.9/testng-6.9.9.jar > -O ${TESTNG_JAR} > +printf "8b211c4c5bed389e169a2173da32d07f93ee2fa8 ${TESTNG_JAR}" | > shasum -a 1 --check - > ?TESTNG_LICENSE=${TESTNG_DEPS_DIR}/LICENSE.txt > -wget > https://raw.githubusercontent.com/cbeust/testng/testng-6.9.5/LICENSE.txt > > -O ${TESTNG_LICENSE} > +wget > https://raw.githubusercontent.com/cbeust/testng/6.9.9/LICENSE.txt > > -O ${TESTNG_LICENSE} > ?JCOMMANDER_JAR=${TESTNG_DEPS_DIR}/jcommander-1.72.jar > ?wget > ${MAVEN_REPO_URL}/com/beust/jcommander/1.72/jcommander-1.72.jar -O > ${JCOMMANDER_JAR} > > > On Fri, Dec 15, 2017 at 2:34 PM, Jonathan Gibbons > > > wrote: > > I've pushed the changeset containing this new script. > > There are two changes since I posted the webrev: > > 1. Change to use "shasum -a 1" instead of "sha1sum" > 2. Update script to download and use jcommander.jar in > conjunction with TestNG. > > With the second change in particular, all the jtreg self-tests > pass, when the image is built with the build-all.sh script. > > -- Jon > > > On 12/13/2017 04:32 PM, Jonathan Gibbons wrote: > > This is for folk who are interested in building jtreg from > source. > > As some of you have (rightfully) commented over the past > years, jtreg has not been an easy tool to build from source. > > And, as some of you may have noticed, there has been some > amount of activity over the past weeks and months to > address this issue. This work has been led by Erik Helin > (thanks, Erik!) and we're now getting to the point where > we can show what we have been working towards. > > The core of the work to build jtreg is still the Makefiles > as before, although as was recently noted, we've been > simplifying the specification of the dependencies. > > Separately, Erik has helped provide updates to the way > that some of the Code Tools dependencies can be built. > > Building on all that work, we can now get to the next > stage, to provide a script that will download binaries for > some components (JUnit, TestNG) and will download and > build source for other components (AsmTools, JCov, > JTHarness), for which there are no official binaries. > > To run the script, you just need to have Ant and a > suitable "java" on your path, and to specify the location > of an install of JDK 1.8 as an argument to the script. > wget is used to download files, which honors proxy > settings for those that need to use them. The script is > deliberately fairly simple, and suitable for use in a CI > system. > > You can see a webrev for the script at > http://cr.openjdk.java.net/~jjg/7902083/webrev.00/ > > > Example of use: > > $ which ant > /opt/ant/1.9.4/bin/ant > $ which java > /opt/jdk/1.8.0/bin/java > $ sh make/build-all.sh /opt/jdk/1.8.0 > ... build output ... > $ ls build/images/jtreg > bin? COPYRIGHT? doc? legal? lib? LICENSE README? release > $ > > > Once this settles down a bit, I'll update the public docs > on the jtreg web pages. > > -- Jon > > > > > From maurizio.cimadamore at oracle.com Sun Dec 17 21:04:38 2017 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Sun, 17 Dec 2017 21:04:38 +0000 Subject: CODETOOLS-7902083: Simplify building jtreg In-Reply-To: <5A31C69F.4090800@oracle.com> References: <5A31C69F.4090800@oracle.com> Message-ID: <7b8de36f-dbb2-9ddc-5f68-049c60bce314@oracle.com> Looks great - thanks for doing this. If there's interest, I could also put some effort in order to integrate the plugins build into the system. In principle, it should be doable, by adding a bunch of env variables (to point at the IDEA runtime jar). Of course that would be an optional part of the build. Cheers Maurizio On 14/12/17 00:32, Jonathan Gibbons wrote: > This is for folk who are interested in building jtreg from source. > > As some of you have (rightfully) commented over the past years, jtreg > has not been an easy tool to build from source. > > And, as some of you may have noticed, there has been some amount of > activity over the past weeks and months to address this issue. This > work has been led by Erik Helin (thanks, Erik!) and we're now getting > to the point where we can show what we have been working towards. > > The core of the work to build jtreg is still the Makefiles as before, > although as was recently noted, we've been simplifying the > specification of the dependencies. > > Separately, Erik has helped provide updates to the way that some of > the Code Tools dependencies can be built. > > Building on all that work, we can now get to the next stage, to > provide a script that will download binaries for some components > (JUnit, TestNG) and will download and build source for other > components (AsmTools, JCov, JTHarness), for which there are no > official binaries. > > To run the script, you just need to have Ant and a suitable "java" on > your path, and to specify the location of an install of JDK 1.8 as an > argument to the script. wget is used to download files, which honors > proxy settings for those that need to use them. The script is > deliberately fairly simple, and suitable for use in a CI system. > > You can see a webrev for the script at > http://cr.openjdk.java.net/~jjg/7902083/webrev.00/ > > Example of use: > > $ which ant > /opt/ant/1.9.4/bin/ant > $ which java > /opt/jdk/1.8.0/bin/java > $ sh make/build-all.sh /opt/jdk/1.8.0 > ... build output ... > $ ls build/images/jtreg > bin? COPYRIGHT? doc? legal? lib? LICENSE? README? release > $ > > > Once this settles down a bit, I'll update the public docs on the jtreg > web pages. > > -- Jon > > From sadhak001 at gmail.com Sun Dec 17 21:46:38 2017 From: sadhak001 at gmail.com (Mani Sarkar) Date: Sun, 17 Dec 2017 21:46:38 +0000 Subject: CODETOOLS-7902083: Simplify building jtreg In-Reply-To: <7b8de36f-dbb2-9ddc-5f68-049c60bce314@oracle.com> References: <5A31C69F.4090800@oracle.com> <7b8de36f-dbb2-9ddc-5f68-049c60bce314@oracle.com> Message-ID: Hi Jon, I remember that the versions before this release also included asmtools during the build process, but we found lately that the final artifact did not actually contain the asmtools commands inside the final jtreg artifact. Has this been resolved in the current version, I will soon be building it, and would like to be able to use jtreg features that make use of asmtools. Thanks. Cheers, Mani On Sun, 17 Dec 2017 21:04 Maurizio Cimadamore, < maurizio.cimadamore at oracle.com> wrote: > Looks great - thanks for doing this. > > If there's interest, I could also put some effort in order to integrate > the plugins build into the system. In principle, it should be doable, by > adding a bunch of env variables (to point at the IDEA runtime jar). Of > course that would be an optional part of the build. > > Cheers > Maurizio > > > On 14/12/17 00:32, Jonathan Gibbons wrote: > > This is for folk who are interested in building jtreg from source. > > > > As some of you have (rightfully) commented over the past years, jtreg > > has not been an easy tool to build from source. > > > > And, as some of you may have noticed, there has been some amount of > > activity over the past weeks and months to address this issue. This > > work has been led by Erik Helin (thanks, Erik!) and we're now getting > > to the point where we can show what we have been working towards. > > > > The core of the work to build jtreg is still the Makefiles as before, > > although as was recently noted, we've been simplifying the > > specification of the dependencies. > > > > Separately, Erik has helped provide updates to the way that some of > > the Code Tools dependencies can be built. > > > > Building on all that work, we can now get to the next stage, to > > provide a script that will download binaries for some components > > (JUnit, TestNG) and will download and build source for other > > components (AsmTools, JCov, JTHarness), for which there are no > > official binaries. > > > > To run the script, you just need to have Ant and a suitable "java" on > > your path, and to specify the location of an install of JDK 1.8 as an > > argument to the script. wget is used to download files, which honors > > proxy settings for those that need to use them. The script is > > deliberately fairly simple, and suitable for use in a CI system. > > > > You can see a webrev for the script at > > http://cr.openjdk.java.net/~jjg/7902083/webrev.00/ > > > > Example of use: > > > > $ which ant > > /opt/ant/1.9.4/bin/ant > > $ which java > > /opt/jdk/1.8.0/bin/java > > $ sh make/build-all.sh /opt/jdk/1.8.0 > > ... build output ... > > $ ls build/images/jtreg > > bin COPYRIGHT doc legal lib LICENSE README release > > $ > > > > > > Once this settles down a bit, I'll update the public docs on the jtreg > > web pages. > > > > -- Jon > > > > > > -- @theNeomatrix369 | Blog | @adoptopenjdk | Dev communities Meet-a-Project - MutabilityDetector | Github | Slideshare | LinkedIn Come to Devoxx UK 2018: http://www.devoxx.co.uk/ Don't chase success, rather aim for "Excellence", and success will come chasing after you! From jonathan.gibbons at oracle.com Mon Dec 18 01:29:11 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Sun, 17 Dec 2017 17:29:11 -0800 Subject: CODETOOLS-7902083: Simplify building jtreg In-Reply-To: References: <5A31C69F.4090800@oracle.com> <7b8de36f-dbb2-9ddc-5f68-049c60bce314@oracle.com> Message-ID: <28292475-3d84-09ca-bcc7-9644b0b8ac68@oracle.com> Mani, I know of no issues with respect to asmtools.? When I build jtreg with this script, all the self-tests pass.? If you encounter issues with asmtools, please let me know. -- Jon On 12/17/17 1:46 PM, Mani Sarkar wrote: > > Hi Jon, > > I remember that the versions before this release also included > asmtools during the build process, but we found lately that the final > artifact did not actually contain the asmtools commands inside the > final jtreg artifact. > > Has this been resolved in the current version, I will soon be building > it, and would like to be able to use jtreg features that make use of? > asmtools. > > Thanks. > > Cheers, > Mani > > > On Sun, 17 Dec 2017 21:04 Maurizio Cimadamore, > > wrote: > > Looks great - thanks for doing this. > > If there's interest, I could also put some effort in order to > integrate > the plugins build into the system. In principle, it should be > doable, by > adding a bunch of env variables (to point at the IDEA runtime jar). Of > course that would be an optional part of the build. > > Cheers > Maurizio > > > On 14/12/17 00:32, Jonathan Gibbons wrote: > > This is for folk who are interested in building jtreg from source. > > > > As some of you have (rightfully) commented over the past years, > jtreg > > has not been an easy tool to build from source. > > > > And, as some of you may have noticed, there has been some amount of > > activity over the past weeks and months to address this issue. This > > work has been led by Erik Helin (thanks, Erik!) and we're now > getting > > to the point where we can show what we have been working towards. > > > > The core of the work to build jtreg is still the Makefiles as > before, > > although as was recently noted, we've been simplifying the > > specification of the dependencies. > > > > Separately, Erik has helped provide updates to the way that some of > > the Code Tools dependencies can be built. > > > > Building on all that work, we can now get to the next stage, to > > provide a script that will download binaries for some components > > (JUnit, TestNG) and will download and build source for other > > components (AsmTools, JCov, JTHarness), for which there are no > > official binaries. > > > > To run the script, you just need to have Ant and a suitable > "java" on > > your path, and to specify the location of an install of JDK 1.8 > as an > > argument to the script. wget is used to download files, which honors > > proxy settings for those that need to use them. The script is > > deliberately fairly simple, and suitable for use in a CI system. > > > > You can see a webrev for the script at > > http://cr.openjdk.java.net/~jjg/7902083/webrev.00/ > > > > > Example of use: > > > > $ which ant > > /opt/ant/1.9.4/bin/ant > > $ which java > > /opt/jdk/1.8.0/bin/java > > $ sh make/build-all.sh /opt/jdk/1.8.0 > > ... build output ... > > $ ls build/images/jtreg > > bin? COPYRIGHT? doc? legal? lib? LICENSE? README? release > > $ > > > > > > Once this settles down a bit, I'll update the public docs on the > jtreg > > web pages. > > > > -- Jon > > > > > > -- > > @theNeomatrix369 ?| Blog > ?| @adoptopenjdk | Dev communities > > Meet-a-Project - MutabilityDetector > ?| Github > ?| Slideshare > ?|LinkedIn > > > Come to Devoxx UK 2018:http://www.devoxx.co.uk/ > > > Don't chase success, rather aim for "Excellence", and success will > come chasing after you! > From jonathan.gibbons at oracle.com Mon Dec 18 01:32:22 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Sun, 17 Dec 2017 17:32:22 -0800 Subject: CODETOOLS-7902083: Simplify building jtreg In-Reply-To: <7b8de36f-dbb2-9ddc-5f68-049c60bce314@oracle.com> References: <5A31C69F.4090800@oracle.com> <7b8de36f-dbb2-9ddc-5f68-049c60bce314@oracle.com> Message-ID: Maurizio, If you can do this in a way that makes it optional, that would be great.?? Having put effort into pruning the set of dependencies, I've no desire to see the set creep up again unnecessarily, although I admit the usefulness of the plugin. -- Jon On 12/17/17 1:04 PM, Maurizio Cimadamore wrote: > Looks great - thanks for doing this. > > If there's interest, I could also put some effort in order to > integrate the plugins build into the system. In principle, it should > be doable, by adding a bunch of env variables (to point at the IDEA > runtime jar). Of course that would be an optional part of the build. > > Cheers > Maurizio > > > On 14/12/17 00:32, Jonathan Gibbons wrote: >> This is for folk who are interested in building jtreg from source. >> >> As some of you have (rightfully) commented over the past years, jtreg >> has not been an easy tool to build from source. >> >> And, as some of you may have noticed, there has been some amount of >> activity over the past weeks and months to address this issue. This >> work has been led by Erik Helin (thanks, Erik!) and we're now getting >> to the point where we can show what we have been working towards. >> >> The core of the work to build jtreg is still the Makefiles as before, >> although as was recently noted, we've been simplifying the >> specification of the dependencies. >> >> Separately, Erik has helped provide updates to the way that some of >> the Code Tools dependencies can be built. >> >> Building on all that work, we can now get to the next stage, to >> provide a script that will download binaries for some components >> (JUnit, TestNG) and will download and build source for other >> components (AsmTools, JCov, JTHarness), for which there are no >> official binaries. >> >> To run the script, you just need to have Ant and a suitable "java" on >> your path, and to specify the location of an install of JDK 1.8 as an >> argument to the script. wget is used to download files, which honors >> proxy settings for those that need to use them. The script is >> deliberately fairly simple, and suitable for use in a CI system. >> >> You can see a webrev for the script at >> http://cr.openjdk.java.net/~jjg/7902083/webrev.00/ >> >> Example of use: >> >> $ which ant >> /opt/ant/1.9.4/bin/ant >> $ which java >> /opt/jdk/1.8.0/bin/java >> $ sh make/build-all.sh /opt/jdk/1.8.0 >> ... build output ... >> $ ls build/images/jtreg >> bin? COPYRIGHT? doc? legal? lib? LICENSE? README? release >> $ >> >> >> Once this settles down a bit, I'll update the public docs on the >> jtreg web pages. >> >> -- Jon >> >> > From maurizio.cimadamore at oracle.com Mon Dec 18 10:18:13 2017 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 18 Dec 2017 10:18:13 +0000 Subject: CODETOOLS-7902083: Simplify building jtreg In-Reply-To: References: <5A31C69F.4090800@oracle.com> <7b8de36f-dbb2-9ddc-5f68-049c60bce314@oracle.com> Message-ID: <43aac4d2-b252-06ac-b900-bd6746013d47@oracle.com> On 18/12/17 01:32, Jonathan Gibbons wrote: > Maurizio, > > If you can do this in a way that makes it optional, that would be > great.?? Having put effort into pruning the set of dependencies, I've > no desire to see the set creep up again unnecessarily, although I > admit the usefulness of the plugin. Message understood :-) Btw, I'm bringing this up because, currently, the only way to build the plugin is through the IDE itself, which, while not unreasonable (after all you have to have an IDE if you want to use the plugin :-)), it require some configuration and I've seen people getting stuck quite frequently - a build command would probably mitigate some of those concerns. Maurizio > > -- Jon > > > On 12/17/17 1:04 PM, Maurizio Cimadamore wrote: >> Looks great - thanks for doing this. >> >> If there's interest, I could also put some effort in order to >> integrate the plugins build into the system. In principle, it should >> be doable, by adding a bunch of env variables (to point at the IDEA >> runtime jar). Of course that would be an optional part of the build. >> >> Cheers >> Maurizio >> >> >> On 14/12/17 00:32, Jonathan Gibbons wrote: >>> This is for folk who are interested in building jtreg from source. >>> >>> As some of you have (rightfully) commented over the past years, >>> jtreg has not been an easy tool to build from source. >>> >>> And, as some of you may have noticed, there has been some amount of >>> activity over the past weeks and months to address this issue. This >>> work has been led by Erik Helin (thanks, Erik!) and we're now >>> getting to the point where we can show what we have been working >>> towards. >>> >>> The core of the work to build jtreg is still the Makefiles as >>> before, although as was recently noted, we've been simplifying the >>> specification of the dependencies. >>> >>> Separately, Erik has helped provide updates to the way that some of >>> the Code Tools dependencies can be built. >>> >>> Building on all that work, we can now get to the next stage, to >>> provide a script that will download binaries for some components >>> (JUnit, TestNG) and will download and build source for other >>> components (AsmTools, JCov, JTHarness), for which there are no >>> official binaries. >>> >>> To run the script, you just need to have Ant and a suitable "java" >>> on your path, and to specify the location of an install of JDK 1.8 >>> as an argument to the script. wget is used to download files, which >>> honors proxy settings for those that need to use them. The script is >>> deliberately fairly simple, and suitable for use in a CI system. >>> >>> You can see a webrev for the script at >>> http://cr.openjdk.java.net/~jjg/7902083/webrev.00/ >>> >>> Example of use: >>> >>> $ which ant >>> /opt/ant/1.9.4/bin/ant >>> $ which java >>> /opt/jdk/1.8.0/bin/java >>> $ sh make/build-all.sh /opt/jdk/1.8.0 >>> ... build output ... >>> $ ls build/images/jtreg >>> bin? COPYRIGHT? doc? legal? lib? LICENSE? README? release >>> $ >>> >>> >>> Once this settles down a bit, I'll update the public docs on the >>> jtreg web pages. >>> >>> -- Jon >>> >>> >> > From alexandre.iline at oracle.com Mon Dec 18 21:13:27 2017 From: alexandre.iline at oracle.com (Alexandre (Shura) Iline) Date: Mon, 18 Dec 2017 13:13:27 -0800 Subject: RFC: add starred module(s) In-Reply-To: References: <5A2B418E.9000607@oracle.com> Message-ID: Hi. I just wanted to commend on enhancing JTreg to automatically calculate module dependencies. Yes, compiler knows the direct static dependencies of the compiler code, but that is not all that is needed to be known. @module annotation is used for a few not completely related things. Besides requesting "--add-exports?, it can also request "--add-opens" and it can influence test selection during execution. Of this three usages, only one could be covered by static dependency analysis. Shura. > On Dec 14, 2017, at 7:56 AM, Jiri Vanek wrote: > > Hi Jonathan! > > Thank you very much for great answer. Few remarks inline. > > > On 12/09/2017 02:51 AM, Jonathan Gibbons wrote: >> Jiri, Mila, >> There are three significant questions here. >> 1. @modules all-needed >> This is a non-starter. @modules participates in a relatively light-weight test selection mechanism > > Sure. It is last step, if it will be ever started. > >> ... i.e. tests are not selected if the specified modules are not available in the system image. Having jtreg analyse the source code to determine the set of necessary modules is just not practical. >> 2. Starred modules, as in @modules java.security.jgss/sun.security.krb5.internal.* >> Setting aside whether this is desirable or not, this is not necessarily an easy thing to do. It requires that we can list the (internal) packages of a module. Yes, there may be a attribute that provides the info, but the attribute is not guaranteed to be available, and if it's not, you're > terrible truth. see at bottom. > >> reduced to scanning the module contents. On the desirability point of view, the use of this sort of syntax was discussed, and rejected, for module declarations, and while that is separate from what is > > I was reading most of this discussion, and I can agree with it for final deployment, but not for testing. >> proposed here, it does lend guidance. Neither is the '*' syntax supported by the options for the Java launcher or javac, and this construct is intended to be a thinly-veiled wrapper for those options. > > This is probably the only sentence I moreover disagree with you. Jtreg is far away fro being tinny wrapper, and it always did huge help for tests authors. So helping testers with setting up module path a bit, may be good step. >> One minor comment ... you can reduce the "wordiness" of your examples by almost 50% by just having a single @modules directive with many arg values, possibly spanning many lines, as in ... >> * .... >> * @modules java.security.jgss/sun.security.krb5.internal >> * java.security.jgss/sun.security.krb5.internal.ccache >> * java.security.jgss/sun.security.krb5.internal.crypto >> * java.security.jgss/sun.security.krb5.internal.ktab >> * java.base/sun.security.util >> * java.security.jgss/sun.security.jgss > > Still you need to enumerate them all. That mean to run javac and jmod in loops one by one, untill you get collect them. >> 3. Shell scripts. >> Using shell scripts for jtreg tests is generally discouraged, these days, to the point that we have made efforts to convert many/most JDK shell tests to Java code. The general experience was that such tests were very fragile, and were often wrong/broken. They typically execute slower than equivalent Java code, especially when using libraries providing commonly-used or domain-specific functionality. > > Well, shell lunchers have theirs dark sides, thats right. But are awesome feature without replacement. >> And as you note below, processing variables like TESTMODULES is problematic. (It is a bug if present for JDK 8 tests). > > Its a bug :) >> When using Java code instead of shell scripts, you can look to libraries in the various test suites for suggestions on useful methods to provide, such as invoking generating and compiling source code, providing simple equivalents for regex search (simple grep), comparison (simple diff), etc, as well as support for running subprocesses when necessary. One common pattern is to use Java code to validate whether it is appropriate to run a test in the current configuration and to then launch a JVM with a selected combination of options. This sort of mode has explicit support in jtreg: "@run driver" is similar to "@run main" for running a class, but it is not run with any JVM options intended for test JVMs. This makes it suitable for running "test driver" classes which spawn JVMs to run the "real" test code. And if you're just writing API tests, then I recommend using plain old Java code and "agentvm" mode to have the tests as fast as possible. > > > You are mostly right. But consider this: The locating of modules is painful when you are dealing with private apis. And that is what you do in jtregs for half of the time... > So naturally, the help would be easy. > On contrary, the help do not come from JDK itself in any "supported" way (or am I missing something?) > Still the javac can do so. So it would be natural to enahnce javac to help with this a bit more via some more solid api. Maybe you know something here? > > One would say, that writing private api jtreg is one or two modules usage only. Unluckily, oposite is true, and Mila's * idea is another proof of it. And If I look to past to my recent work, I was facing the same. Just got angry later. > > > So generally - some help should be provided in JDK to deal with it. And as JDK looks to have its reasons to not to do so, Jtregs should. > > > Thanx for again for your reply! > J. > > > > > > > From jonathan.gibbons at oracle.com Tue Dec 19 19:42:02 2017 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Tue, 19 Dec 2017 19:42:02 +0000 Subject: hg: code-tools/jtreg: Update internal defaults to use JT Harness 5.0 Message-ID: <201712191942.vBJJg28l012466@aojmv0008.oracle.com> Changeset: a13ec77e7adc Author: jjg Date: 2017-12-19 11:37 -0800 URL: http://hg.openjdk.java.net/code-tools/jtreg/rev/a13ec77e7adc Update internal defaults to use JT Harness 5.0 ! make/Defs.gmk From sadhak001 at gmail.com Tue Dec 19 23:33:17 2017 From: sadhak001 at gmail.com (Mani Sarkar) Date: Tue, 19 Dec 2017 23:33:17 +0000 Subject: CODETOOLS-7902083: Simplify building jtreg In-Reply-To: <43aac4d2-b252-06ac-b900-bd6746013d47@oracle.com> References: <5A31C69F.4090800@oracle.com> <7b8de36f-dbb2-9ddc-5f68-049c60bce314@oracle.com> <43aac4d2-b252-06ac-b900-bd6746013d47@oracle.com> Message-ID: Hi Jon, Amended the scripts to use the latest build-all.sh from the tip, and got this - https://ci.adoptopenjdk.net/view/Dependencies/job/jtreg/. Still using our old script to build from the last tag. Both the artifacts do contain asmtools.jar - let me know if it passes your sanity check. Thanks again. Cheers, Mani On Mon, 18 Dec 2017 at 10:18 Maurizio Cimadamore < maurizio.cimadamore at oracle.com> wrote: > > > On 18/12/17 01:32, Jonathan Gibbons wrote: > > Maurizio, > > > > If you can do this in a way that makes it optional, that would be > > great. Having put effort into pruning the set of dependencies, I've > > no desire to see the set creep up again unnecessarily, although I > > admit the usefulness of the plugin. > Message understood :-) > > Btw, I'm bringing this up because, currently, the only way to build the > plugin is through the IDE itself, which, while not unreasonable (after > all you have to have an IDE if you want to use the plugin :-)), it > require some configuration and I've seen people getting stuck quite > frequently - a build command would probably mitigate some of those > concerns. > > Maurizio > > > > -- Jon > > > > > > On 12/17/17 1:04 PM, Maurizio Cimadamore wrote: > >> Looks great - thanks for doing this. > >> > >> If there's interest, I could also put some effort in order to > >> integrate the plugins build into the system. In principle, it should > >> be doable, by adding a bunch of env variables (to point at the IDEA > >> runtime jar). Of course that would be an optional part of the build. > >> > >> Cheers > >> Maurizio > >> > >> > >> On 14/12/17 00:32, Jonathan Gibbons wrote: > >>> This is for folk who are interested in building jtreg from source. > >>> > >>> As some of you have (rightfully) commented over the past years, > >>> jtreg has not been an easy tool to build from source. > >>> > >>> And, as some of you may have noticed, there has been some amount of > >>> activity over the past weeks and months to address this issue. This > >>> work has been led by Erik Helin (thanks, Erik!) and we're now > >>> getting to the point where we can show what we have been working > >>> towards. > >>> > >>> The core of the work to build jtreg is still the Makefiles as > >>> before, although as was recently noted, we've been simplifying the > >>> specification of the dependencies. > >>> > >>> Separately, Erik has helped provide updates to the way that some of > >>> the Code Tools dependencies can be built. > >>> > >>> Building on all that work, we can now get to the next stage, to > >>> provide a script that will download binaries for some components > >>> (JUnit, TestNG) and will download and build source for other > >>> components (AsmTools, JCov, JTHarness), for which there are no > >>> official binaries. > >>> > >>> To run the script, you just need to have Ant and a suitable "java" > >>> on your path, and to specify the location of an install of JDK 1.8 > >>> as an argument to the script. wget is used to download files, which > >>> honors proxy settings for those that need to use them. The script is > >>> deliberately fairly simple, and suitable for use in a CI system. > >>> > >>> You can see a webrev for the script at > >>> http://cr.openjdk.java.net/~jjg/7902083/webrev.00/ > >>> > >>> Example of use: > >>> > >>> $ which ant > >>> /opt/ant/1.9.4/bin/ant > >>> $ which java > >>> /opt/jdk/1.8.0/bin/java > >>> $ sh make/build-all.sh /opt/jdk/1.8.0 > >>> ... build output ... > >>> $ ls build/images/jtreg > >>> bin COPYRIGHT doc legal lib LICENSE README release > >>> $ > >>> > >>> > >>> Once this settles down a bit, I'll update the public docs on the > >>> jtreg web pages. > >>> > >>> -- Jon > >>> > >>> > >> > > > > -- @theNeomatrix369 | Blog | @adoptopenjdk | Dev communities Meet-a-Project - MutabilityDetector | Github | Slideshare | LinkedIn Come to Devoxx UK 2018: http://www.devoxx.co.uk/ Don't chase success, rather aim for "Excellence", and success will come chasing after you! From jonathan.gibbons at oracle.com Tue Dec 19 23:57:09 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 19 Dec 2017 15:57:09 -0800 Subject: CODETOOLS-7902083: Simplify building jtreg In-Reply-To: References: <5A31C69F.4090800@oracle.com> <7b8de36f-dbb2-9ddc-5f68-049c60bce314@oracle.com> <43aac4d2-b252-06ac-b900-bd6746013d47@oracle.com> Message-ID: <44c82008-98df-44d0-b065-c15ea9558bdc@oracle.com> Sounds good;? I expect to promote (and tag) a new version tomorrow, getting ready for JDK 11. -- Jon On 12/19/17 3:33 PM, Mani Sarkar wrote: > Hi Jon, > > Amended the scripts to use the latest build-all.sh from the tip, and > got this - https://ci.adoptopenjdk.net/view/Dependencies/job/jtreg/. > > Still using our old script to build from the last tag. > > Both the?artifacts do contain asmtools.jar - let me know if it passes > your sanity check. > > Thanks again. > > Cheers, > Mani > > On Mon, 18 Dec 2017 at 10:18 Maurizio Cimadamore > > wrote: > > > > On 18/12/17 01:32, Jonathan Gibbons wrote: > > Maurizio, > > > > If you can do this in a way that makes it optional, that would be > > great.?? Having put effort into pruning the set of dependencies, > I've > > no desire to see the set creep up again unnecessarily, although I > > admit the usefulness of the plugin. > Message understood :-) > > Btw, I'm bringing this up because, currently, the only way to > build the > plugin is through the IDE itself, which, while not unreasonable (after > all you have to have an IDE if you want to use the plugin :-)), it > require some configuration and I've seen people getting stuck quite > frequently - a build command would probably mitigate some of those > concerns. > > Maurizio > > > > -- Jon > > > > > > On 12/17/17 1:04 PM, Maurizio Cimadamore wrote: > >> Looks great - thanks for doing this. > >> > >> If there's interest, I could also put some effort in order to > >> integrate the plugins build into the system. In principle, it > should > >> be doable, by adding a bunch of env variables (to point at the IDEA > >> runtime jar). Of course that would be an optional part of the > build. > >> > >> Cheers > >> Maurizio > >> > >> > >> On 14/12/17 00:32, Jonathan Gibbons wrote: > >>> This is for folk who are interested in building jtreg from source. > >>> > >>> As some of you have (rightfully) commented over the past years, > >>> jtreg has not been an easy tool to build from source. > >>> > >>> And, as some of you may have noticed, there has been some > amount of > >>> activity over the past weeks and months to address this issue. > This > >>> work has been led by Erik Helin (thanks, Erik!) and we're now > >>> getting to the point where we can show what we have been working > >>> towards. > >>> > >>> The core of the work to build jtreg is still the Makefiles as > >>> before, although as was recently noted, we've been simplifying the > >>> specification of the dependencies. > >>> > >>> Separately, Erik has helped provide updates to the way that > some of > >>> the Code Tools dependencies can be built. > >>> > >>> Building on all that work, we can now get to the next stage, to > >>> provide a script that will download binaries for some components > >>> (JUnit, TestNG) and will download and build source for other > >>> components (AsmTools, JCov, JTHarness), for which there are no > >>> official binaries. > >>> > >>> To run the script, you just need to have Ant and a suitable "java" > >>> on your path, and to specify the location of an install of JDK 1.8 > >>> as an argument to the script. wget is used to download files, > which > >>> honors proxy settings for those that need to use them. The > script is > >>> deliberately fairly simple, and suitable for use in a CI system. > >>> > >>> You can see a webrev for the script at > >>> http://cr.openjdk.java.net/~jjg/7902083/webrev.00/ > > >>> > >>> Example of use: > >>> > >>> $ which ant > >>> /opt/ant/1.9.4/bin/ant > >>> $ which java > >>> /opt/jdk/1.8.0/bin/java > >>> $ sh make/build-all.sh /opt/jdk/1.8.0 > >>> ... build output ... > >>> $ ls build/images/jtreg > >>> bin? COPYRIGHT? doc? legal? lib? LICENSE? README release > >>> $ > >>> > >>> > >>> Once this settles down a bit, I'll update the public docs on the > >>> jtreg web pages. > >>> > >>> -- Jon > >>> > >>> > >> > > > > -- > > @theNeomatrix369 ?| Blog > ?| @adoptopenjdk | Dev communities > > Meet-a-Project - MutabilityDetector > ?| Github > ?| Slideshare > ?|LinkedIn > > > Come to Devoxx UK 2018:http://www.devoxx.co.uk/ > > > Don't chase success, rather aim for "Excellence", and success will > come chasing after you! > From jvanek at redhat.com Wed Dec 20 16:35:52 2017 From: jvanek at redhat.com (Jiri Vanek) Date: Wed, 20 Dec 2017 17:35:52 +0100 Subject: Bugfix: do not set TESTMODULES environment variable if JDK is not modular In-Reply-To: References: Message-ID: <991930f2-0f30-f8c5-179a-8f9b12c8b4e0@redhat.com> On 12/15/2017 11:37 AM, Miloslav Zezulka wrote: > This is a very small patch fixing the issue pointed out in $subject. I've > added checks for both compile and test JDK - is this an overkill, since > most of the time the implication goes COMPILEJDK.modular => > TESTJDK.modular, or a necessary thing to have for foolproofness? Works fine. Johnatan, can you push it? Or do you wont mila to create regular webrev? Is there some palce to add test for it? Tahnx a lot! J. -- Jiri Vanek Senior QE engineer, OpenJDK QE lead, Mgr. Red Hat Czech jvanek at redhat.com M: +420775390109 From jvanek at redhat.com Wed Dec 20 17:14:11 2017 From: jvanek at redhat.com (Jiri Vanek) Date: Wed, 20 Dec 2017 18:14:11 +0100 Subject: RFC: add starred module(s) In-Reply-To: References: <5A2B418E.9000607@oracle.com> Message-ID: On 12/18/2017 10:13 PM, Alexandre (Shura) Iline wrote: > Hi. > > I just wanted to commend on enhancing JTreg to automatically calculate module dependencies. Yes, compiler knows the direct static dependencies of the compiler code, but that is not all that is needed to be known. @module annotation is used for a few not completely related things. Besides requesting "--add-exports?, it can also request "--add-opens" and it can influence test selection during execution. Of this three usages, only one could be covered by static dependency analysis. > Thank you very much for this input! From what you are saying, the need for more support of @module-whatever is needed - and doable. Current @modules is adding --add-exports and --add-opens of the modules you specified to the command. If there will be way to add exports and opens of those, which can be covered by static analyse, then it will be already more then helpfull! Especially if you will be able to add some more manually. Of course more granular support like @modules-export and @modules-opens and similar would be nice, but Thats more far away from this proposal. J. > >> On Dec 14, 2017, at 7:56 AM, Jiri Vanek wrote: >> >> Hi Jonathan! >> >> Thank you very much for great answer. Few remarks inline. >> >> >> On 12/09/2017 02:51 AM, Jonathan Gibbons wrote: >>> Jiri, Mila, >>> There are three significant questions here. >>> 1. @modules all-needed >>> This is a non-starter. @modules participates in a relatively light-weight test selection mechanism >> >> Sure. It is last step, if it will be ever started. >> >>> ... i.e. tests are not selected if the specified modules are not available in the system image. Having jtreg analyse the source code to determine the set of necessary modules is just not practical. >>> 2. Starred modules, as in @modules java.security.jgss/sun.security.krb5.internal.* >>> Setting aside whether this is desirable or not, this is not necessarily an easy thing to do. It requires that we can list the (internal) packages of a module. Yes, there may be a attribute that provides the info, but the attribute is not guaranteed to be available, and if it's not, you're >> terrible truth. see at bottom. >> >>> reduced to scanning the module contents. On the desirability point of view, the use of this sort of syntax was discussed, and rejected, for module declarations, and while that is separate from what is >> >> I was reading most of this discussion, and I can agree with it for final deployment, but not for testing. >>> proposed here, it does lend guidance. Neither is the '*' syntax supported by the options for the Java launcher or javac, and this construct is intended to be a thinly-veiled wrapper for those options. >> >> This is probably the only sentence I moreover disagree with you. Jtreg is far away fro being tinny wrapper, and it always did huge help for tests authors. So helping testers with setting up module path a bit, may be good step. >>> One minor comment ... you can reduce the "wordiness" of your examples by almost 50% by just having a single @modules directive with many arg values, possibly spanning many lines, as in ... >>> * .... >>> * @modules java.security.jgss/sun.security.krb5.internal >>> * java.security.jgss/sun.security.krb5.internal.ccache >>> * java.security.jgss/sun.security.krb5.internal.crypto >>> * java.security.jgss/sun.security.krb5.internal.ktab >>> * java.base/sun.security.util >>> * java.security.jgss/sun.security.jgss >> >> Still you need to enumerate them all. That mean to run javac and jmod in loops one by one, untill you get collect them. >>> 3. Shell scripts. >>> Using shell scripts for jtreg tests is generally discouraged, these days, to the point that we have made efforts to convert many/most JDK shell tests to Java code. The general experience was that such tests were very fragile, and were often wrong/broken. They typically execute slower than equivalent Java code, especially when using libraries providing commonly-used or domain-specific functionality. >> >> Well, shell lunchers have theirs dark sides, thats right. But are awesome feature without replacement. >>> And as you note below, processing variables like TESTMODULES is problematic. (It is a bug if present for JDK 8 tests). >> >> Its a bug :) >>> When using Java code instead of shell scripts, you can look to libraries in the various test suites for suggestions on useful methods to provide, such as invoking generating and compiling source code, providing simple equivalents for regex search (simple grep), comparison (simple diff), etc, as well as support for running subprocesses when necessary. One common pattern is to use Java code to validate whether it is appropriate to run a test in the current configuration and to then launch a JVM with a selected combination of options. This sort of mode has explicit support in jtreg: "@run driver" is similar to "@run main" for running a class, but it is not run with any JVM options intended for test JVMs. This makes it suitable for running "test driver" classes which spawn JVMs to run the "real" test code. And if you're just writing API tests, then I recommend using plain old Java code and "agentvm" mode to have the tests as fast as possible. >> >> >> You are mostly right. But consider this: The locating of modules is painful when you are dealing with private apis. And that is what you do in jtregs for half of the time... >> So naturally, the help would be easy. >> On contrary, the help do not come from JDK itself in any "supported" way (or am I missing something?) >> Still the javac can do so. So it would be natural to enahnce javac to help with this a bit more via some more solid api. Maybe you know something here? >> >> One would say, that writing private api jtreg is one or two modules usage only. Unluckily, oposite is true, and Mila's * idea is another proof of it. And If I look to past to my recent work, I was facing the same. Just got angry later. >> >> >> So generally - some help should be provided in JDK to deal with it. And as JDK looks to have its reasons to not to do so, Jtregs should. >> >> >> Thanx for again for your reply! >> J. >> >> >> >> >> >> >> > -- Jiri Vanek Senior QE engineer, OpenJDK QE lead, Mgr. Red Hat Czech jvanek at redhat.com M: +420775390109 From jonathan.gibbons at oracle.com Wed Dec 20 17:27:28 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 20 Dec 2017 09:27:28 -0800 Subject: RFC: add starred module(s) In-Reply-To: References: <5A2B418E.9000607@oracle.com> Message-ID: <3c5632bb-c4f4-ad07-d5f8-17be92f247b6@oracle.com> On 12/20/17 9:14 AM, Jiri Vanek wrote: > On 12/18/2017 10:13 PM, Alexandre (Shura) Iline wrote: >> Hi. >> >> I just wanted to commend on enhancing JTreg to automatically >> calculate module dependencies. Yes, compiler knows the direct static >> dependencies of the compiler code, but that is not all that is needed >> to be known. @module annotation is used for a few not completely >> related things. Besides requesting "--add-exports?, it can also >> request "--add-opens" and it can influence test selection during >> execution. Of this three usages, only one could be covered by static >> dependency analysis. >> > > > Thank you very much for this input! > > From what you are saying, the need for more support of > @module-whatever is needed - and doable. > Current @modules is adding --add-exports and --add-opens? of the > modules you specified to the? command. > If there will be way to add exports and opens of those, which can be > covered by static analyse, then it will be already more then helpfull! > Especially if you will be able to add some more manually. > Of course more granular support like @modules-export and > @modules-opens and similar would be nice, but Thats more far away from > this proposal. > > J. Jiri, To be clear ... it is not reasonable to add such support for an enhanced @modules for use at the time the test is selected for execution and then subsequently executed.? If nothing else, there is a big chicken-and-egg problem here? ... you cannot analyse the test code until it has been compiled, and you cannot compile it until you know the module dependencies. In general, for existing JDK tests, the @modules have been determined. For new tests, I recommend you look to your IDE or other development-time tools, to help determine the dependencies of the test code, and then record the results in an @modules tag in the test description. -- Jon > >> >>> On Dec 14, 2017, at 7:56 AM, Jiri Vanek wrote: >>> >>> Hi Jonathan! >>> >>> Thank you very much for great answer. Few remarks inline. >>> >>> >>> On 12/09/2017 02:51 AM, Jonathan Gibbons wrote: >>>> Jiri, Mila, >>>> There are three significant questions here. >>>> 1. @modules all-needed >>>> This is a non-starter. @modules participates in a relatively >>>> light-weight test selection mechanism >>> >>> Sure. It is last step, if it will be ever started. >>> >>>> ... i.e. tests are not selected if the specified modules are not >>>> available in the system image. Having jtreg analyse the source code >>>> to determine the set of necessary modules is just not practical. >>>> 2. Starred modules, as in @modules >>>> java.security.jgss/sun.security.krb5.internal.* >>>> Setting aside whether this is desirable or not, this is not >>>> necessarily an easy thing to do. It requires that we can list the >>>> (internal) packages of a module. Yes, there may be a attribute that >>>> provides the info, but the attribute is not guaranteed to be >>>> available, and if it's not, you're >>> terrible truth. see at bottom. >>> >>>> reduced to scanning the module contents.? On the desirability point >>>> of view, the use of this sort of syntax was discussed, and >>>> rejected, for module declarations, and while that is separate from >>>> what is >>> >>> I was reading most of this discussion, and I can agree with it for >>> final deployment, but not for testing. >>>> proposed here, it does lend guidance. Neither is the '*' syntax >>>> supported by the options for the Java launcher or javac, and this >>>> construct is intended to be a thinly-veiled wrapper for those options. >>> >>> This is probably the only sentence I moreover disagree with you. >>> Jtreg is far away fro being tinny wrapper, and it always did huge >>> help for tests authors.? So helping testers with setting up module >>> path a bit, may be good step. >>>> One minor comment ... you can reduce the "wordiness" of your >>>> examples by almost 50% by just having a single @modules directive >>>> with many arg values, possibly spanning many lines, as in ... >>>> ?? * .... >>>> ?? * @modules java.security.jgss/sun.security.krb5.internal >>>> ?? * java.security.jgss/sun.security.krb5.internal.ccache >>>> ?? * java.security.jgss/sun.security.krb5.internal.crypto >>>> ?? * java.security.jgss/sun.security.krb5.internal.ktab >>>> ?? * java.base/sun.security.util >>>> ?? * java.security.jgss/sun.security.jgss >>> >>> Still you need to enumerate them all. That mean to run javac and >>> jmod in loops? one by one, untill you get collect them. >>>> 3. Shell scripts. >>>> Using shell scripts for jtreg tests is generally discouraged, these >>>> days, to the point that we have made efforts to convert many/most >>>> JDK shell tests to Java code. The general experience was that such >>>> tests were very fragile, and were often wrong/broken. They >>>> typically execute slower than equivalent Java code, especially when >>>> using libraries providing commonly-used or domain-specific >>>> functionality. >>> >>> Well, shell lunchers have theirs dark sides, thats right. But are >>> awesome feature without replacement. >>>> And as you note below, processing variables like TESTMODULES is >>>> problematic. (It is a bug if present for JDK 8 tests). >>> >>> Its a bug :) >>>> When using Java code instead of shell scripts, you can look to >>>> libraries in the various test suites for suggestions on useful >>>> methods to provide, such as invoking generating and compiling >>>> source code, providing simple equivalents for regex search (simple >>>> grep), comparison (simple diff), etc, as well as support for >>>> running subprocesses when necessary. One common pattern is to use >>>> Java code to validate whether it is appropriate to run a test in >>>> the current configuration and to then launch a JVM with a selected >>>> combination of options. This sort of mode has explicit support in >>>> jtreg:? "@run driver" is similar to "@run main" for running a >>>> class, but it is not run with any JVM options intended for test >>>> JVMs. This makes it suitable for running "test driver" classes >>>> which spawn JVMs to run the "real" test code.? And if you're just >>>> writing API tests, then I recommend using plain old Java code and >>>> "agentvm" mode to have the tests as fast as possible. >>> >>> >>> You are mostly right. But consider this: The locating of modules is >>> painful when you are dealing with private apis. And that is what you >>> do in jtregs for half of the time... >>> So naturally, the help would be easy. >>> On contrary, the help do not come from JDK itself in any "supported" >>> way (or am I missing something?) >>> Still the javac can do so. So it would be natural to enahnce javac >>> to help with this a bit more via some more solid api. Maybe you know >>> something here? >>> >>> One would say, that writing private api jtreg is one or two modules >>> usage only. Unluckily, oposite is true, and Mila's * idea is another >>> proof of it. And If I look to past to my recent work, I was facing >>> the same. Just got angry later. >>> >>> >>> So generally - some help should be provided in JDK to deal with it. >>> And as JDK looks to have its reasons to not to do so, Jtregs should. >>> >>> >>> Thanx for again for your reply! >>> ? J. >>> >>> >>> >>> >>> >>> >>> >> > > From alexandre.iline at oracle.com Wed Dec 20 19:55:06 2017 From: alexandre.iline at oracle.com (Alexandre (Shura) Iline) Date: Wed, 20 Dec 2017 11:55:06 -0800 Subject: RFC: add starred module(s) In-Reply-To: References: <5A2B418E.9000607@oracle.com> Message-ID: <155d0949-bbe7-adc3-74cd-be8fec3213e4@oracle.com> On 12/20/17 9:14 AM, Jiri Vanek wrote: > On 12/18/2017 10:13 PM, Alexandre (Shura) Iline wrote: >> Hi. >> >> I just wanted to commend on enhancing JTreg to automatically calculate >> module dependencies. Yes, compiler knows the direct static >> dependencies of the compiler code, but that is not all that is needed >> to be known. @module annotation is used for a few not completely >> related things. Besides requesting "--add-exports?, it can also >> request "--add-opens" and it can influence test selection during >> execution. Of this three usages, only one could be covered by static >> dependency analysis. >> > > > Thank you very much for this input! > > From what you are saying, the need for more support of @module-whatever > is needed - and doable. > Current @modules is adding --add-exports and --add-opens? of the modules > you specified to the? command. > If there will be way to add exports and opens of those, which can be > covered by static analyse, then it will be already more then helpfull! > Especially if you will be able to add some more manually. > Of course more granular support like @modules-export and @modules-opens > and similar would be nice, but Thats more far away from this proposal. The point I was trying to make was that it is impossible to statically compute what --add-opens should be added or what modules a test requires to be present. I am completely with Jonathan on this, sorry for not making it clear. Shura > > J. > >> >>> On Dec 14, 2017, at 7:56 AM, Jiri Vanek wrote: >>> >>> Hi Jonathan! >>> >>> Thank you very much for great answer. Few remarks inline. >>> >>> >>> On 12/09/2017 02:51 AM, Jonathan Gibbons wrote: >>>> Jiri, Mila, >>>> There are three significant questions here. >>>> 1. @modules all-needed >>>> This is a non-starter. @modules participates in a relatively >>>> light-weight test selection mechanism >>> >>> Sure. It is last step, if it will be ever started. >>> >>>> ... i.e. tests are not selected if the specified modules are not >>>> available in the system image. Having jtreg analyse the source code >>>> to determine the set of necessary modules is just not practical. >>>> 2. Starred modules, as in @modules >>>> java.security.jgss/sun.security.krb5.internal.* >>>> Setting aside whether this is desirable or not, this is not >>>> necessarily an easy thing to do. It requires that we can list the >>>> (internal) packages of a module. Yes, there may be a attribute that >>>> provides the info, but the attribute is not guaranteed to be >>>> available, and if it's not, you're >>> terrible truth. see at bottom. >>> >>>> reduced to scanning the module contents.? On the desirability point >>>> of view, the use of this sort of syntax was discussed, and rejected, >>>> for module declarations, and while that is separate from what is >>> >>> I was reading most of this discussion, and I can agree with it for >>> final deployment, but not for testing. >>>> proposed here, it does lend guidance.? Neither is the '*' syntax >>>> supported by the options for the Java launcher or javac, and this >>>> construct is intended to be a thinly-veiled wrapper for those options. >>> >>> This is probably the only sentence I moreover disagree with you. >>> Jtreg is far away fro being tinny wrapper, and it always? did huge >>> help for tests authors.? So helping testers with setting up module >>> path a bit, may be good step. >>>> One minor comment ... you can reduce the "wordiness" of your >>>> examples by almost 50% by just having a single @modules directive >>>> with many arg values, possibly spanning many lines, as in ... >>>> ?? * .... >>>> ?? * @modules java.security.jgss/sun.security.krb5.internal >>>> ?? * java.security.jgss/sun.security.krb5.internal.ccache >>>> ?? * java.security.jgss/sun.security.krb5.internal.crypto >>>> ?? * java.security.jgss/sun.security.krb5.internal.ktab >>>> ?? * java.base/sun.security.util >>>> ?? * java.security.jgss/sun.security.jgss >>> >>> Still you need to enumerate them all. That mean to run javac and jmod >>> in loops? one by one, untill you get collect them. >>>> 3. Shell scripts. >>>> Using shell scripts for jtreg tests is generally discouraged, these >>>> days, to the point that we have made efforts to convert many/most >>>> JDK shell tests to Java code. The general experience was that such >>>> tests were very fragile, and were often wrong/broken. They typically >>>> execute slower than equivalent Java code, especially when using >>>> libraries providing commonly-used or domain-specific functionality. >>> >>> Well, shell lunchers have theirs dark sides, thats right. But are >>> awesome feature without replacement. >>>> And as you note below, processing variables like TESTMODULES is >>>> problematic. (It is a bug if present for JDK 8 tests). >>> >>> Its a bug :) >>>> When using Java code instead of shell scripts, you can look to >>>> libraries in the various test suites for suggestions on useful >>>> methods to provide, such as invoking generating and compiling source >>>> code, providing simple equivalents for regex search (simple grep), >>>> comparison (simple diff), etc, as well as support for running >>>> subprocesses when necessary. One common pattern is to use Java code >>>> to validate whether it is appropriate to run a test in the current >>>> configuration and to then launch a JVM with a selected combination >>>> of options. This sort of mode has explicit support in jtreg:? "@run >>>> driver" is similar to "@run main" for running a class, but it is not >>>> run with any JVM options intended for test JVMs. This makes it >>>> suitable for running "test driver" classes which spawn JVMs to run >>>> the "real" test code.? And if you're just writing API tests, then I >>>> recommend using plain old Java code and "agentvm" mode to have the >>>> tests as fast as possible. >>> >>> >>> You are mostly right. But consider this: The locating of modules is >>> painful when you are dealing with private apis. And that is what you >>> do in jtregs for half of the time... >>> So naturally, the help would be easy. >>> On contrary, the help do not come from JDK itself in any "supported" >>> way (or am I missing something?) >>> Still the javac can do so. So it would be natural to enahnce javac to >>> help with this a bit more via some more solid api. Maybe you know >>> something here? >>> >>> One would say, that writing private api jtreg is one or two modules >>> usage only. Unluckily, oposite is true, and Mila's * idea is another >>> proof of it. And If I look to past to my recent work, I was facing >>> the same. Just got angry later. >>> >>> >>> So generally - some help should be provided in JDK to deal with it. >>> And as JDK looks to have its reasons to not to do so, Jtregs should. >>> >>> >>> Thanx for again for your reply! >>> ? J. >>> >>> >>> >>> >>> >>> >>> >> > > From jonathan.gibbons at oracle.com Wed Dec 20 22:15:56 2017 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Wed, 20 Dec 2017 22:15:56 +0000 Subject: hg: code-tools/jtreg: Added tag jtreg4.2-b11 for changeset a13ec77e7adc Message-ID: <201712202215.vBKMFuQV000786@aojmv0008.oracle.com> Changeset: 87c289a8a4fa Author: jjg Date: 2017-12-20 14:11 -0800 URL: http://hg.openjdk.java.net/code-tools/jtreg/rev/87c289a8a4fa Added tag jtreg4.2-b11 for changeset a13ec77e7adc ! .hgtags From jonathan.gibbons at oracle.com Wed Dec 20 23:57:44 2017 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Wed, 20 Dec 2017 23:57:44 +0000 Subject: hg: code-tools/jtreg: report version of AsmTools in -version Message-ID: <201712202357.vBKNviqJ006924@aojmv0008.oracle.com> Changeset: df3e4d854005 Author: jjg Date: 2017-12-20 15:53 -0800 URL: http://hg.openjdk.java.net/code-tools/jtreg/rev/df3e4d854005 report version of AsmTools in -version ! src/share/classes/com/sun/javatest/regtest/tool/Tool.java From jonathan.gibbons at oracle.com Thu Dec 21 01:09:12 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 20 Dec 2017 17:09:12 -0800 Subject: CODETOOLS-7902083: Simplify building jtreg In-Reply-To: References: <5A31C69F.4090800@oracle.com> <7b8de36f-dbb2-9ddc-5f68-049c60bce314@oracle.com> <43aac4d2-b252-06ac-b900-bd6746013d47@oracle.com> Message-ID: <5A3B09B8.5050905@oracle.com> I've posted a new tag (jtreg4.2-b11) on the jtreg repo, so I would expect to see a new build on your CI system soon. If you're using the new make/build-all.sh script, then everything should build as intended. If you're not using build-all.sh, note that you need to build jtreg with variables like TESTNG_HOME, JUNIT_HOME, ASMTOOLS_HOME etc defined at the time you run "make". It is not enough to copy the corresponding jar files into the lib directory; they must also be put in the Class-Path entry of the jtreg.jar MANIFEST.MF file (and the makefiles will take care of doing that.) It occurs to me you might still be using the (old) Ant build.xml file. If so, I recommend you convert to using the new build-all.sh script. -- Jon On 12/19/2017 03:33 PM, Mani Sarkar wrote: > Hi Jon, > > Amended the scripts to use the latest build-all.sh from the tip, and > got this - https://ci.adoptopenjdk.net/view/Dependencies/job/jtreg/. > > Still using our old script to build from the last tag. > > Both the artifacts do contain asmtools.jar - let me know if it passes > your sanity check. > > Thanks again. > > Cheers, > Mani > > On Mon, 18 Dec 2017 at 10:18 Maurizio Cimadamore > > wrote: > > > > On 18/12/17 01:32, Jonathan Gibbons wrote: > > Maurizio, > > > > If you can do this in a way that makes it optional, that would be > > great. Having put effort into pruning the set of dependencies, > I've > > no desire to see the set creep up again unnecessarily, although I > > admit the usefulness of the plugin. > Message understood :-) > > Btw, I'm bringing this up because, currently, the only way to > build the > plugin is through the IDE itself, which, while not unreasonable (after > all you have to have an IDE if you want to use the plugin :-)), it > require some configuration and I've seen people getting stuck quite > frequently - a build command would probably mitigate some of those > concerns. > > Maurizio > > > > -- Jon > > > > > > On 12/17/17 1:04 PM, Maurizio Cimadamore wrote: > >> Looks great - thanks for doing this. > >> > >> If there's interest, I could also put some effort in order to > >> integrate the plugins build into the system. In principle, it > should > >> be doable, by adding a bunch of env variables (to point at the IDEA > >> runtime jar). Of course that would be an optional part of the > build. > >> > >> Cheers > >> Maurizio > >> > >> > >> On 14/12/17 00:32, Jonathan Gibbons wrote: > >>> This is for folk who are interested in building jtreg from source. > >>> > >>> As some of you have (rightfully) commented over the past years, > >>> jtreg has not been an easy tool to build from source. > >>> > >>> And, as some of you may have noticed, there has been some > amount of > >>> activity over the past weeks and months to address this issue. > This > >>> work has been led by Erik Helin (thanks, Erik!) and we're now > >>> getting to the point where we can show what we have been working > >>> towards. > >>> > >>> The core of the work to build jtreg is still the Makefiles as > >>> before, although as was recently noted, we've been simplifying the > >>> specification of the dependencies. > >>> > >>> Separately, Erik has helped provide updates to the way that > some of > >>> the Code Tools dependencies can be built. > >>> > >>> Building on all that work, we can now get to the next stage, to > >>> provide a script that will download binaries for some components > >>> (JUnit, TestNG) and will download and build source for other > >>> components (AsmTools, JCov, JTHarness), for which there are no > >>> official binaries. > >>> > >>> To run the script, you just need to have Ant and a suitable "java" > >>> on your path, and to specify the location of an install of JDK 1.8 > >>> as an argument to the script. wget is used to download files, > which > >>> honors proxy settings for those that need to use them. The > script is > >>> deliberately fairly simple, and suitable for use in a CI system. > >>> > >>> You can see a webrev for the script at > >>> http://cr.openjdk.java.net/~jjg/7902083/webrev.00/ > > >>> > >>> Example of use: > >>> > >>> $ which ant > >>> /opt/ant/1.9.4/bin/ant > >>> $ which java > >>> /opt/jdk/1.8.0/bin/java > >>> $ sh make/build-all.sh /opt/jdk/1.8.0 > >>> ... build output ... > >>> $ ls build/images/jtreg > >>> bin COPYRIGHT doc legal lib LICENSE README release > >>> $ > >>> > >>> > >>> Once this settles down a bit, I'll update the public docs on the > >>> jtreg web pages. > >>> > >>> -- Jon > >>> > >>> > >> > > > > -- > > @theNeomatrix369 | Blog > | @adoptopenjdk | Dev communities > > Meet-a-Project - MutabilityDetector > | Github > | Slideshare > |LinkedIn > > > Come to Devoxx UK 2018:http://www.devoxx.co.uk/ > > > Don't chase success, rather aim for "Excellence", and success will > come chasing after you! > From jonathan.gibbons at oracle.com Thu Dec 21 01:12:29 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 20 Dec 2017 17:12:29 -0800 Subject: CODETOOLS-7902083: Simplify building jtreg In-Reply-To: <5A3B09B8.5050905@oracle.com> References: <5A31C69F.4090800@oracle.com> <7b8de36f-dbb2-9ddc-5f68-049c60bce314@oracle.com> <43aac4d2-b252-06ac-b900-bd6746013d47@oracle.com> <5A3B09B8.5050905@oracle.com> Message-ID: <5A3B0A7D.4030607@oracle.com> My previous message was intended for Mani. I'm sorry I did not make that clearer. -- Jon On 12/20/2017 05:09 PM, Jonathan Gibbons wrote: > I've posted a new tag (jtreg4.2-b11) on the jtreg repo, so I would > expect to see a new build on your CI system soon. > > If you're using the new make/build-all.sh script, then everything > should build as intended. > > If you're not using build-all.sh, note that you need to build jtreg > with variables like TESTNG_HOME, JUNIT_HOME, ASMTOOLS_HOME etc defined > at the time you run "make". It is not enough to copy the corresponding > jar files into the lib directory; they must also be put in the > Class-Path entry of the jtreg.jar MANIFEST.MF file (and the makefiles > will take care of doing that.) > > It occurs to me you might still be using the (old) Ant build.xml > file. If so, I recommend you convert to using the new build-all.sh > script. > > -- Jon > > On 12/19/2017 03:33 PM, Mani Sarkar wrote: >> Hi Jon, >> >> Amended the scripts to use the latest build-all.sh from the tip, and >> got this - https://ci.adoptopenjdk.net/view/Dependencies/job/jtreg/. >> >> Still using our old script to build from the last tag. >> >> Both the artifacts do contain asmtools.jar - let me know if it passes >> your sanity check. >> >> Thanks again. >> >> Cheers, >> Mani >> >> On Mon, 18 Dec 2017 at 10:18 Maurizio Cimadamore >> > > wrote: >> >> >> >> On 18/12/17 01:32, Jonathan Gibbons wrote: >> > Maurizio, >> > >> > If you can do this in a way that makes it optional, that would be >> > great. Having put effort into pruning the set of dependencies, >> I've >> > no desire to see the set creep up again unnecessarily, although I >> > admit the usefulness of the plugin. >> Message understood :-) >> >> Btw, I'm bringing this up because, currently, the only way to >> build the >> plugin is through the IDE itself, which, while not unreasonable >> (after >> all you have to have an IDE if you want to use the plugin :-)), it >> require some configuration and I've seen people getting stuck quite >> frequently - a build command would probably mitigate some of those >> concerns. >> >> Maurizio >> > >> > -- Jon >> > >> > >> > On 12/17/17 1:04 PM, Maurizio Cimadamore wrote: >> >> Looks great - thanks for doing this. >> >> >> >> If there's interest, I could also put some effort in order to >> >> integrate the plugins build into the system. In principle, it >> should >> >> be doable, by adding a bunch of env variables (to point at the >> IDEA >> >> runtime jar). Of course that would be an optional part of the >> build. >> >> >> >> Cheers >> >> Maurizio >> >> >> >> >> >> On 14/12/17 00:32, Jonathan Gibbons wrote: >> >>> This is for folk who are interested in building jtreg from >> source. >> >>> >> >>> As some of you have (rightfully) commented over the past years, >> >>> jtreg has not been an easy tool to build from source. >> >>> >> >>> And, as some of you may have noticed, there has been some >> amount of >> >>> activity over the past weeks and months to address this issue. >> This >> >>> work has been led by Erik Helin (thanks, Erik!) and we're now >> >>> getting to the point where we can show what we have been working >> >>> towards. >> >>> >> >>> The core of the work to build jtreg is still the Makefiles as >> >>> before, although as was recently noted, we've been >> simplifying the >> >>> specification of the dependencies. >> >>> >> >>> Separately, Erik has helped provide updates to the way that >> some of >> >>> the Code Tools dependencies can be built. >> >>> >> >>> Building on all that work, we can now get to the next stage, to >> >>> provide a script that will download binaries for some components >> >>> (JUnit, TestNG) and will download and build source for other >> >>> components (AsmTools, JCov, JTHarness), for which there are no >> >>> official binaries. >> >>> >> >>> To run the script, you just need to have Ant and a suitable >> "java" >> >>> on your path, and to specify the location of an install of >> JDK 1.8 >> >>> as an argument to the script. wget is used to download files, >> which >> >>> honors proxy settings for those that need to use them. The >> script is >> >>> deliberately fairly simple, and suitable for use in a CI system. >> >>> >> >>> You can see a webrev for the script at >> >>> http://cr.openjdk.java.net/~jjg/7902083/webrev.00/ >> >> >>> >> >>> Example of use: >> >>> >> >>> $ which ant >> >>> /opt/ant/1.9.4/bin/ant >> >>> $ which java >> >>> /opt/jdk/1.8.0/bin/java >> >>> $ sh make/build-all.sh /opt/jdk/1.8.0 >> >>> ... build output ... >> >>> $ ls build/images/jtreg >> >>> bin COPYRIGHT doc legal lib LICENSE README release >> >>> $ >> >>> >> >>> >> >>> Once this settles down a bit, I'll update the public docs on the >> >>> jtreg web pages. >> >>> >> >>> -- Jon >> >>> >> >>> >> >> >> > >> >> -- >> >> @theNeomatrix369 | Blog >> | @adoptopenjdk | Dev communities >> >> Meet-a-Project - MutabilityDetector >> | Github >> | Slideshare >> |LinkedIn >> >> >> Come to Devoxx UK 2018:http://www.devoxx.co.uk/ >> >> >> Don't chase success, rather aim for "Excellence", and success will >> come chasing after you! >> > From jonathan.gibbons at oracle.com Thu Dec 21 01:48:56 2017 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Thu, 21 Dec 2017 01:48:56 +0000 Subject: hg: code-tools/jtreg: update JCov support for JDK 9 (modules) Message-ID: <201712210148.vBL1mvfZ012340@aojmv0008.oracle.com> Changeset: cfe17a6137fa Author: jjg Date: 2017-12-20 17:45 -0800 URL: http://hg.openjdk.java.net/code-tools/jtreg/rev/cfe17a6137fa update JCov support for JDK 9 (modules) ! src/share/classes/com/sun/javatest/regtest/tool/JCovManager.java ! src/share/classes/com/sun/javatest/regtest/tool/Tool.java From jonathan.gibbons at oracle.com Fri Dec 22 15:49:25 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 22 Dec 2017 07:49:25 -0800 Subject: CODETOOLS-7902083: Simplify building jtreg In-Reply-To: References: <5A31C69F.4090800@oracle.com> <7b8de36f-dbb2-9ddc-5f68-049c60bce314@oracle.com> <43aac4d2-b252-06ac-b900-bd6746013d47@oracle.com> <5A3B09B8.5050905@oracle.com> <5A3B0A7D.4030607@oracle.com> Message-ID: <17b33335-30d0-8316-8200-6b0cebddfafe@oracle.com> Volker, Thanks for the feedback. I'll take a look at your webrev. -- Jon On 12/22/17 7:17 AM, Volker Simonis wrote: > Hi Jonathan, > > thanks a lot for improving the build. This is a huge step ahead and it > works great. I've just tried it and the build succeeded out of the > box! > > There's however one issue I still see. The default build will set the > version and build number to '4-2 dev b00'. Notice that such a build is > pretty useless, because such versions of JTreg will be rejected when > doing OpenJDK regression tests because the OpenJDK test have minimal > JTreg build requirements in their TEST.ROOT file like for example: > > # Minimum jtreg version > requiredVersion=4.2 b08 > > Before the introduction of build-all.sh it was possible to pass > BUILD_NUMBER through the environment to make. > > When using build-all.sh this is not possible any more, because > build-all.sh calls make without honoring if BUILD_NUMBER was set in > the environment. > > I've opened "CODETOOLS-7902089: build-all.sh should honor BUILD_NUMBER > from environment (and use a reasonable default)" > (https://bugs.openjdk.java.net/browse/CODETOOLS-7902089) and came up > with the following fix: > > http://cr.openjdk.java.net/~simonis/webrevs/2017/CODETOOLS-7902089 > > As an extension I propose to set the build number by default to the > latest available tag automatically, even if we're building tip because > I think that's what users actually want (and need) if they build JTreg > for executing the OpenJDK tests. This feature is already realized in > my webrev. > > Finally, we could set the build number to something like "b11+" if > "b11" was the latest tagged build, but we're several changes ahead > already (this would resemble the "hg id" output which prints a "+" > after the actual change hash if the working directory contains > additional local changes). > > I consider this to be the best solution, but in order to work we would > also have to update JTReg's build number parsing routine in > com.sun.javatest.regtest.tool.Version.getBuild() which currently only > accepts a plain build number (i.e. "b[0-9]+"). This feature is > currently not in my webrev but I'd be happy to add it if you'd > consider it useful. > > Can you please review and sponsor my change? > > Thank you and merry Christmas:) > Volker > > > > On Thu, Dec 21, 2017 at 2:12 AM, Jonathan Gibbons > wrote: >> My previous message was intended for Mani. I'm sorry I did not make that >> clearer. >> >> -- Jon >> >> On 12/20/2017 05:09 PM, Jonathan Gibbons wrote: >>> I've posted a new tag (jtreg4.2-b11) on the jtreg repo, so I would expect >>> to see a new build on your CI system soon. >>> >>> If you're using the new make/build-all.sh script, then everything should >>> build as intended. >>> >>> If you're not using build-all.sh, note that you need to build jtreg with >>> variables like TESTNG_HOME, JUNIT_HOME, ASMTOOLS_HOME etc defined at the >>> time you run "make". It is not enough to copy the corresponding jar files >>> into the lib directory; they must also be put in the Class-Path entry of the >>> jtreg.jar MANIFEST.MF file (and the makefiles will take care of doing that.) >>> >>> It occurs to me you might still be using the (old) Ant build.xml file. If >>> so, I recommend you convert to using the new build-all.sh script. >>> >>> -- Jon >>> >>> On 12/19/2017 03:33 PM, Mani Sarkar wrote: >>>> Hi Jon, >>>> >>>> Amended the scripts to use the latest build-all.sh from the tip, and got >>>> this - https://ci.adoptopenjdk.net/view/Dependencies/job/jtreg/. >>>> >>>> Still using our old script to build from the last tag. >>>> >>>> Both the artifacts do contain asmtools.jar - let me know if it passes >>>> your sanity check. >>>> >>>> Thanks again. >>>> >>>> Cheers, >>>> Mani >>>> >>>> On Mon, 18 Dec 2017 at 10:18 Maurizio Cimadamore >>>> > >>>> wrote: >>>> >>>> >>>> >>>> On 18/12/17 01:32, Jonathan Gibbons wrote: >>>> > Maurizio, >>>> > >>>> > If you can do this in a way that makes it optional, that would be >>>> > great. Having put effort into pruning the set of dependencies, >>>> I've >>>> > no desire to see the set creep up again unnecessarily, although I >>>> > admit the usefulness of the plugin. >>>> Message understood :-) >>>> >>>> Btw, I'm bringing this up because, currently, the only way to >>>> build the >>>> plugin is through the IDE itself, which, while not unreasonable >>>> (after >>>> all you have to have an IDE if you want to use the plugin :-)), it >>>> require some configuration and I've seen people getting stuck quite >>>> frequently - a build command would probably mitigate some of those >>>> concerns. >>>> >>>> Maurizio >>>> > >>>> > -- Jon >>>> > >>>> > >>>> > On 12/17/17 1:04 PM, Maurizio Cimadamore wrote: >>>> >> Looks great - thanks for doing this. >>>> >> >>>> >> If there's interest, I could also put some effort in order to >>>> >> integrate the plugins build into the system. In principle, it >>>> should >>>> >> be doable, by adding a bunch of env variables (to point at the >>>> IDEA >>>> >> runtime jar). Of course that would be an optional part of the >>>> build. >>>> >> >>>> >> Cheers >>>> >> Maurizio >>>> >> >>>> >> >>>> >> On 14/12/17 00:32, Jonathan Gibbons wrote: >>>> >>> This is for folk who are interested in building jtreg from >>>> source. >>>> >>> >>>> >>> As some of you have (rightfully) commented over the past years, >>>> >>> jtreg has not been an easy tool to build from source. >>>> >>> >>>> >>> And, as some of you may have noticed, there has been some >>>> amount of >>>> >>> activity over the past weeks and months to address this issue. >>>> This >>>> >>> work has been led by Erik Helin (thanks, Erik!) and we're now >>>> >>> getting to the point where we can show what we have been working >>>> >>> towards. >>>> >>> >>>> >>> The core of the work to build jtreg is still the Makefiles as >>>> >>> before, although as was recently noted, we've been simplifying >>>> the >>>> >>> specification of the dependencies. >>>> >>> >>>> >>> Separately, Erik has helped provide updates to the way that >>>> some of >>>> >>> the Code Tools dependencies can be built. >>>> >>> >>>> >>> Building on all that work, we can now get to the next stage, to >>>> >>> provide a script that will download binaries for some components >>>> >>> (JUnit, TestNG) and will download and build source for other >>>> >>> components (AsmTools, JCov, JTHarness), for which there are no >>>> >>> official binaries. >>>> >>> >>>> >>> To run the script, you just need to have Ant and a suitable >>>> "java" >>>> >>> on your path, and to specify the location of an install of JDK >>>> 1.8 >>>> >>> as an argument to the script. wget is used to download files, >>>> which >>>> >>> honors proxy settings for those that need to use them. The >>>> script is >>>> >>> deliberately fairly simple, and suitable for use in a CI system. >>>> >>> >>>> >>> You can see a webrev for the script at >>>> >>> http://cr.openjdk.java.net/~jjg/7902083/webrev.00/ >>>> >>>> >>> >>>> >>> Example of use: >>>> >>> >>>> >>> $ which ant >>>> >>> /opt/ant/1.9.4/bin/ant >>>> >>> $ which java >>>> >>> /opt/jdk/1.8.0/bin/java >>>> >>> $ sh make/build-all.sh /opt/jdk/1.8.0 >>>> >>> ... build output ... >>>> >>> $ ls build/images/jtreg >>>> >>> bin COPYRIGHT doc legal lib LICENSE README release >>>> >>> $ >>>> >>> >>>> >>> >>>> >>> Once this settles down a bit, I'll update the public docs on the >>>> >>> jtreg web pages. >>>> >>> >>>> >>> -- Jon >>>> >>> >>>> >>> >>>> >> >>>> > >>>> >>>> -- >>>> >>>> @theNeomatrix369 | Blog >>>> | @adoptopenjdk | Dev communities >>>> >>>> Meet-a-Project - MutabilityDetector >>>> | Github >>>> | Slideshare >>>> |LinkedIn >>>> >>>> >>>> Come to Devoxx UK 2018:http://www.devoxx.co.uk/ >>>> >>>> >>>> Don't chase success, rather aim for "Excellence", and success will come >>>> chasing after you! >>>> From martinrb at google.com Fri Dec 22 17:58:34 2017 From: martinrb at google.com (Martin Buchholz) Date: Fri, 22 Dec 2017 09:58:34 -0800 Subject: CODETOOLS-7902083: Simplify building jtreg In-Reply-To: References: <5A31C69F.4090800@oracle.com> <7b8de36f-dbb2-9ddc-5f68-049c60bce314@oracle.com> <43aac4d2-b252-06ac-b900-bd6746013d47@oracle.com> <5A3B09B8.5050905@oracle.com> <5A3B0A7D.4030607@oracle.com> Message-ID: I agree having to fiddle with the build number is a pain point, but it's shared with openjdk proper. You can't rely on mercurial tags; code can get moved out of mercurial (hg archive) or into a different source code system. I would prefer BUILD_NUMBER checked in, and write a little script that modified the source and hg tagged it at the same time. And then of course check in the script! On Fri, Dec 22, 2017 at 7:17 AM, Volker Simonis wrote: > Hi Jonathan, > > thanks a lot for improving the build. This is a huge step ahead and it > works great. I've just tried it and the build succeeded out of the > box! > > There's however one issue I still see. The default build will set the > version and build number to '4-2 dev b00'. Notice that such a build is > pretty useless, because such versions of JTreg will be rejected when > doing OpenJDK regression tests because the OpenJDK test have minimal > JTreg build requirements in their TEST.ROOT file like for example: > > # Minimum jtreg version > requiredVersion=4.2 b08 > > Before the introduction of build-all.sh it was possible to pass > BUILD_NUMBER through the environment to make. > > When using build-all.sh this is not possible any more, because > build-all.sh calls make without honoring if BUILD_NUMBER was set in > the environment. > > I've opened "CODETOOLS-7902089: build-all.sh should honor BUILD_NUMBER > from environment (and use a reasonable default)" > (https://bugs.openjdk.java.net/browse/CODETOOLS-7902089) and came up > with the following fix: > > http://cr.openjdk.java.net/~simonis/webrevs/2017/CODETOOLS-7902089 > > As an extension I propose to set the build number by default to the > latest available tag automatically, even if we're building tip because > I think that's what users actually want (and need) if they build JTreg > for executing the OpenJDK tests. This feature is already realized in > my webrev. > > Finally, we could set the build number to something like "b11+" if > "b11" was the latest tagged build, but we're several changes ahead > already (this would resemble the "hg id" output which prints a "+" > after the actual change hash if the working directory contains > additional local changes). > > I consider this to be the best solution, but in order to work we would > also have to update JTReg's build number parsing routine in > com.sun.javatest.regtest.tool.Version.getBuild() which currently only > accepts a plain build number (i.e. "b[0-9]+"). This feature is > currently not in my webrev but I'd be happy to add it if you'd > consider it useful. > > Can you please review and sponsor my change? > > Thank you and merry Christmas:) > Volker > > > > On Thu, Dec 21, 2017 at 2:12 AM, Jonathan Gibbons > wrote: > > My previous message was intended for Mani. I'm sorry I did not make that > > clearer. > > > > -- Jon > > > > On 12/20/2017 05:09 PM, Jonathan Gibbons wrote: > >> > >> I've posted a new tag (jtreg4.2-b11) on the jtreg repo, so I would > expect > >> to see a new build on your CI system soon. > >> > >> If you're using the new make/build-all.sh script, then everything should > >> build as intended. > >> > >> If you're not using build-all.sh, note that you need to build jtreg with > >> variables like TESTNG_HOME, JUNIT_HOME, ASMTOOLS_HOME etc defined at the > >> time you run "make". It is not enough to copy the corresponding jar > files > >> into the lib directory; they must also be put in the Class-Path entry > of the > >> jtreg.jar MANIFEST.MF file (and the makefiles will take care of doing > that.) > >> > >> It occurs to me you might still be using the (old) Ant build.xml file. > If > >> so, I recommend you convert to using the new build-all.sh script. > >> > >> -- Jon > >> > >> On 12/19/2017 03:33 PM, Mani Sarkar wrote: > >>> > >>> Hi Jon, > >>> > >>> Amended the scripts to use the latest build-all.sh from the tip, and > got > >>> this - https://ci.adoptopenjdk.net/view/Dependencies/job/jtreg/. > >>> > >>> Still using our old script to build from the last tag. > >>> > >>> Both the artifacts do contain asmtools.jar - let me know if it passes > >>> your sanity check. > >>> > >>> Thanks again. > >>> > >>> Cheers, > >>> Mani > >>> > >>> On Mon, 18 Dec 2017 at 10:18 Maurizio Cimadamore > >>> >> > >>> wrote: > >>> > >>> > >>> > >>> On 18/12/17 01:32, Jonathan Gibbons wrote: > >>> > Maurizio, > >>> > > >>> > If you can do this in a way that makes it optional, that would be > >>> > great. Having put effort into pruning the set of dependencies, > >>> I've > >>> > no desire to see the set creep up again unnecessarily, although I > >>> > admit the usefulness of the plugin. > >>> Message understood :-) > >>> > >>> Btw, I'm bringing this up because, currently, the only way to > >>> build the > >>> plugin is through the IDE itself, which, while not unreasonable > >>> (after > >>> all you have to have an IDE if you want to use the plugin :-)), it > >>> require some configuration and I've seen people getting stuck quite > >>> frequently - a build command would probably mitigate some of those > >>> concerns. > >>> > >>> Maurizio > >>> > > >>> > -- Jon > >>> > > >>> > > >>> > On 12/17/17 1:04 PM, Maurizio Cimadamore wrote: > >>> >> Looks great - thanks for doing this. > >>> >> > >>> >> If there's interest, I could also put some effort in order to > >>> >> integrate the plugins build into the system. In principle, it > >>> should > >>> >> be doable, by adding a bunch of env variables (to point at the > >>> IDEA > >>> >> runtime jar). Of course that would be an optional part of the > >>> build. > >>> >> > >>> >> Cheers > >>> >> Maurizio > >>> >> > >>> >> > >>> >> On 14/12/17 00:32, Jonathan Gibbons wrote: > >>> >>> This is for folk who are interested in building jtreg from > >>> source. > >>> >>> > >>> >>> As some of you have (rightfully) commented over the past years, > >>> >>> jtreg has not been an easy tool to build from source. > >>> >>> > >>> >>> And, as some of you may have noticed, there has been some > >>> amount of > >>> >>> activity over the past weeks and months to address this issue. > >>> This > >>> >>> work has been led by Erik Helin (thanks, Erik!) and we're now > >>> >>> getting to the point where we can show what we have been > working > >>> >>> towards. > >>> >>> > >>> >>> The core of the work to build jtreg is still the Makefiles as > >>> >>> before, although as was recently noted, we've been simplifying > >>> the > >>> >>> specification of the dependencies. > >>> >>> > >>> >>> Separately, Erik has helped provide updates to the way that > >>> some of > >>> >>> the Code Tools dependencies can be built. > >>> >>> > >>> >>> Building on all that work, we can now get to the next stage, to > >>> >>> provide a script that will download binaries for some > components > >>> >>> (JUnit, TestNG) and will download and build source for other > >>> >>> components (AsmTools, JCov, JTHarness), for which there are no > >>> >>> official binaries. > >>> >>> > >>> >>> To run the script, you just need to have Ant and a suitable > >>> "java" > >>> >>> on your path, and to specify the location of an install of JDK > >>> 1.8 > >>> >>> as an argument to the script. wget is used to download files, > >>> which > >>> >>> honors proxy settings for those that need to use them. The > >>> script is > >>> >>> deliberately fairly simple, and suitable for use in a CI > system. > >>> >>> > >>> >>> You can see a webrev for the script at > >>> >>> http://cr.openjdk.java.net/~jjg/7902083/webrev.00/ > >>> > >>> >>> > >>> >>> Example of use: > >>> >>> > >>> >>> $ which ant > >>> >>> /opt/ant/1.9.4/bin/ant > >>> >>> $ which java > >>> >>> /opt/jdk/1.8.0/bin/java > >>> >>> $ sh make/build-all.sh /opt/jdk/1.8.0 > >>> >>> ... build output ... > >>> >>> $ ls build/images/jtreg > >>> >>> bin COPYRIGHT doc legal lib LICENSE README release > >>> >>> $ > >>> >>> > >>> >>> > >>> >>> Once this settles down a bit, I'll update the public docs on > the > >>> >>> jtreg web pages. > >>> >>> > >>> >>> -- Jon > >>> >>> > >>> >>> > >>> >> > >>> > > >>> > >>> -- > >>> > >>> @theNeomatrix369 | Blog > >>> | @adoptopenjdk | Dev communities > >>> > >>> Meet-a-Project - MutabilityDetector > >>> | Github > >>> | Slideshare > >>> |LinkedIn > >>> > >>> > >>> Come to Devoxx UK 2018:http://www.devoxx.co.uk/ > >>> > >>> > >>> Don't chase success, rather aim for "Excellence", and success will come > >>> chasing after you! > >>> > >> > > > From jonathan.gibbons at oracle.com Fri Dec 22 19:28:57 2017 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Fri, 22 Dec 2017 19:28:57 +0000 Subject: hg: code-tools/jtreg: 7902089: build-all.sh should honor BUILD_NUMBER from environment (and use a reasonable default) Message-ID: <201712221928.vBMJSvMJ022525@aojmv0008.oracle.com> Changeset: 8ca4454391c8 Author: jjg Date: 2017-12-22 11:22 -0800 URL: http://hg.openjdk.java.net/code-tools/jtreg/rev/8ca4454391c8 7902089: build-all.sh should honor BUILD_NUMBER from environment (and use a reasonable default) Contributed-by: volker.simonis at gmail.com ! make/build-all.sh From jonathan.gibbons at oracle.com Fri Dec 22 19:47:32 2017 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Fri, 22 Dec 2017 19:47:32 +0000 Subject: hg: code-tools/jtreg: tweak syntax in build-all.sh Message-ID: <201712221947.vBMJlX4K028796@aojmv0008.oracle.com> Changeset: 42ffd91009af Author: jjg Date: 2017-12-22 11:43 -0800 URL: http://hg.openjdk.java.net/code-tools/jtreg/rev/42ffd91009af tweak syntax in build-all.sh ! make/build-all.sh From jonathan.gibbons at oracle.com Fri Dec 22 19:40:14 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 22 Dec 2017 11:40:14 -0800 Subject: CODETOOLS-7902083: Simplify building jtreg In-Reply-To: References: <5A31C69F.4090800@oracle.com> <7b8de36f-dbb2-9ddc-5f68-049c60bce314@oracle.com> <43aac4d2-b252-06ac-b900-bd6746013d47@oracle.com> <5A3B09B8.5050905@oracle.com> <5A3B0A7D.4030607@oracle.com> Message-ID: <5A3D5F9E.6080905@oracle.com> Volker, Thank you for noting the BUILD_NUMBER problem. I've pushed your fix (with a minor tweak to the syntax for consistency). I think there may be more changes to come, but your patch at least addresses the ability to pass through the BUILD_* info. I don't think that patching the code for the build number is the way to go. I think the "milestone" field is a better field to indicate deviations from a standard build. We might also want to look at aligning the syntax of tags and version strings with OpenJDK. Various folk have suggested some other minor improvements to the script in general, and I'll look at incorporating those changes as well. -- Jon On 12/22/2017 07:17 AM, Volker Simonis wrote: > Hi Jonathan, > > thanks a lot for improving the build. This is a huge step ahead and it > works great. I've just tried it and the build succeeded out of the > box! > > There's however one issue I still see. The default build will set the > version and build number to '4-2 dev b00'. Notice that such a build is > pretty useless, because such versions of JTreg will be rejected when > doing OpenJDK regression tests because the OpenJDK test have minimal > JTreg build requirements in their TEST.ROOT file like for example: > > # Minimum jtreg version > requiredVersion=4.2 b08 > > Before the introduction of build-all.sh it was possible to pass > BUILD_NUMBER through the environment to make. > > When using build-all.sh this is not possible any more, because > build-all.sh calls make without honoring if BUILD_NUMBER was set in > the environment. > > I've opened "CODETOOLS-7902089: build-all.sh should honor BUILD_NUMBER > from environment (and use a reasonable default)" > (https://bugs.openjdk.java.net/browse/CODETOOLS-7902089) and came up > with the following fix: > > http://cr.openjdk.java.net/~simonis/webrevs/2017/CODETOOLS-7902089 > > As an extension I propose to set the build number by default to the > latest available tag automatically, even if we're building tip because > I think that's what users actually want (and need) if they build JTreg > for executing the OpenJDK tests. This feature is already realized in > my webrev. > > Finally, we could set the build number to something like "b11+" if > "b11" was the latest tagged build, but we're several changes ahead > already (this would resemble the "hg id" output which prints a "+" > after the actual change hash if the working directory contains > additional local changes). > > I consider this to be the best solution, but in order to work we would > also have to update JTReg's build number parsing routine in > com.sun.javatest.regtest.tool.Version.getBuild() which currently only > accepts a plain build number (i.e. "b[0-9]+"). This feature is > currently not in my webrev but I'd be happy to add it if you'd > consider it useful. > > Can you please review and sponsor my change? > > Thank you and merry Christmas:) > Volker > > > > On Thu, Dec 21, 2017 at 2:12 AM, Jonathan Gibbons > wrote: >> My previous message was intended for Mani. I'm sorry I did not make that >> clearer. >> >> -- Jon >> >> On 12/20/2017 05:09 PM, Jonathan Gibbons wrote: >>> I've posted a new tag (jtreg4.2-b11) on the jtreg repo, so I would expect >>> to see a new build on your CI system soon. >>> >>> If you're using the new make/build-all.sh script, then everything should >>> build as intended. >>> >>> If you're not using build-all.sh, note that you need to build jtreg with >>> variables like TESTNG_HOME, JUNIT_HOME, ASMTOOLS_HOME etc defined at the >>> time you run "make". It is not enough to copy the corresponding jar files >>> into the lib directory; they must also be put in the Class-Path entry of the >>> jtreg.jar MANIFEST.MF file (and the makefiles will take care of doing that.) >>> >>> It occurs to me you might still be using the (old) Ant build.xml file. If >>> so, I recommend you convert to using the new build-all.sh script. >>> >>> -- Jon >>> >>> On 12/19/2017 03:33 PM, Mani Sarkar wrote: >>>> Hi Jon, >>>> >>>> Amended the scripts to use the latest build-all.sh from the tip, and got >>>> this - https://ci.adoptopenjdk.net/view/Dependencies/job/jtreg/. >>>> >>>> Still using our old script to build from the last tag. >>>> >>>> Both the artifacts do contain asmtools.jar - let me know if it passes >>>> your sanity check. >>>> >>>> Thanks again. >>>> >>>> Cheers, >>>> Mani >>>> >>>> On Mon, 18 Dec 2017 at 10:18 Maurizio Cimadamore >>>> > >>>> wrote: >>>> >>>> >>>> >>>> On 18/12/17 01:32, Jonathan Gibbons wrote: >>>> > Maurizio, >>>> > >>>> > If you can do this in a way that makes it optional, that would be >>>> > great. Having put effort into pruning the set of dependencies, >>>> I've >>>> > no desire to see the set creep up again unnecessarily, although I >>>> > admit the usefulness of the plugin. >>>> Message understood :-) >>>> >>>> Btw, I'm bringing this up because, currently, the only way to >>>> build the >>>> plugin is through the IDE itself, which, while not unreasonable >>>> (after >>>> all you have to have an IDE if you want to use the plugin :-)), it >>>> require some configuration and I've seen people getting stuck quite >>>> frequently - a build command would probably mitigate some of those >>>> concerns. >>>> >>>> Maurizio >>>> > >>>> > -- Jon >>>> > >>>> > >>>> > On 12/17/17 1:04 PM, Maurizio Cimadamore wrote: >>>> >> Looks great - thanks for doing this. >>>> >> >>>> >> If there's interest, I could also put some effort in order to >>>> >> integrate the plugins build into the system. In principle, it >>>> should >>>> >> be doable, by adding a bunch of env variables (to point at the >>>> IDEA >>>> >> runtime jar). Of course that would be an optional part of the >>>> build. >>>> >> >>>> >> Cheers >>>> >> Maurizio >>>> >> >>>> >> >>>> >> On 14/12/17 00:32, Jonathan Gibbons wrote: >>>> >>> This is for folk who are interested in building jtreg from >>>> source. >>>> >>> >>>> >>> As some of you have (rightfully) commented over the past years, >>>> >>> jtreg has not been an easy tool to build from source. >>>> >>> >>>> >>> And, as some of you may have noticed, there has been some >>>> amount of >>>> >>> activity over the past weeks and months to address this issue. >>>> This >>>> >>> work has been led by Erik Helin (thanks, Erik!) and we're now >>>> >>> getting to the point where we can show what we have been working >>>> >>> towards. >>>> >>> >>>> >>> The core of the work to build jtreg is still the Makefiles as >>>> >>> before, although as was recently noted, we've been simplifying >>>> the >>>> >>> specification of the dependencies. >>>> >>> >>>> >>> Separately, Erik has helped provide updates to the way that >>>> some of >>>> >>> the Code Tools dependencies can be built. >>>> >>> >>>> >>> Building on all that work, we can now get to the next stage, to >>>> >>> provide a script that will download binaries for some components >>>> >>> (JUnit, TestNG) and will download and build source for other >>>> >>> components (AsmTools, JCov, JTHarness), for which there are no >>>> >>> official binaries. >>>> >>> >>>> >>> To run the script, you just need to have Ant and a suitable >>>> "java" >>>> >>> on your path, and to specify the location of an install of JDK >>>> 1.8 >>>> >>> as an argument to the script. wget is used to download files, >>>> which >>>> >>> honors proxy settings for those that need to use them. The >>>> script is >>>> >>> deliberately fairly simple, and suitable for use in a CI system. >>>> >>> >>>> >>> You can see a webrev for the script at >>>> >>> http://cr.openjdk.java.net/~jjg/7902083/webrev.00/ >>>> >>>> >>> >>>> >>> Example of use: >>>> >>> >>>> >>> $ which ant >>>> >>> /opt/ant/1.9.4/bin/ant >>>> >>> $ which java >>>> >>> /opt/jdk/1.8.0/bin/java >>>> >>> $ sh make/build-all.sh /opt/jdk/1.8.0 >>>> >>> ... build output ... >>>> >>> $ ls build/images/jtreg >>>> >>> bin COPYRIGHT doc legal lib LICENSE README release >>>> >>> $ >>>> >>> >>>> >>> >>>> >>> Once this settles down a bit, I'll update the public docs on the >>>> >>> jtreg web pages. >>>> >>> >>>> >>> -- Jon >>>> >>> >>>> >>> >>>> >> >>>> > >>>> >>>> -- >>>> >>>> @theNeomatrix369 | Blog >>>> | @adoptopenjdk | Dev communities >>>> >>>> Meet-a-Project - MutabilityDetector >>>> | Github >>>> | Slideshare >>>> |LinkedIn >>>> >>>> >>>> Come to Devoxx UK 2018:http://www.devoxx.co.uk/ >>>> >>>> >>>> Don't chase success, rather aim for "Excellence", and success will come >>>> chasing after you! >>>> From martinrb at google.com Wed Dec 27 23:17:13 2017 From: martinrb at google.com (Martin Buchholz) Date: Wed, 27 Dec 2017 15:17:13 -0800 Subject: CODETOOLS-7902083: Simplify building jtreg In-Reply-To: <5A3D5F9E.6080905@oracle.com> References: <5A31C69F.4090800@oracle.com> <7b8de36f-dbb2-9ddc-5f68-049c60bce314@oracle.com> <43aac4d2-b252-06ac-b900-bd6746013d47@oracle.com> <5A3B09B8.5050905@oracle.com> <5A3B0A7D.4030607@oracle.com> <5A3D5F9E.6080905@oracle.com> Message-ID: Because TEST.ROOT files contain lines like: requiredVersion=4.2 b11 the BUILD_NUMBER is effectively a public API that cannot be changed. The architected way might be to bump the "4.2" number every time there's a feature release, but it's probably too late for that. So I would still put BUILD_NUMBER = 11 into the Makefile every time it's tagged. Extra work for jjg, but only for jjg. On Fri, Dec 22, 2017 at 11:40 AM, Jonathan Gibbons < jonathan.gibbons at oracle.com> wrote: > Volker, > > Thank you for noting the BUILD_NUMBER problem. > I've pushed your fix (with a minor tweak to the syntax for consistency). > I think there may be more changes to come, but your patch at least > addresses the ability to pass through the BUILD_* info. > > I don't think that patching the code for the build number is the way > to go. I think the "milestone" field is a better field to indicate > deviations from a standard build. We might also want to look at > aligning the syntax of tags and version strings with OpenJDK. > > Various folk have suggested some other minor improvements to the > script in general, and I'll look at incorporating those changes as well. > > -- Jon > > > On 12/22/2017 07:17 AM, Volker Simonis wrote: > >> Hi Jonathan, >> >> thanks a lot for improving the build. This is a huge step ahead and it >> works great. I've just tried it and the build succeeded out of the >> box! >> >> There's however one issue I still see. The default build will set the >> version and build number to '4-2 dev b00'. Notice that such a build is >> pretty useless, because such versions of JTreg will be rejected when >> doing OpenJDK regression tests because the OpenJDK test have minimal >> JTreg build requirements in their TEST.ROOT file like for example: >> >> # Minimum jtreg version >> requiredVersion=4.2 b08 >> >> Before the introduction of build-all.sh it was possible to pass >> BUILD_NUMBER through the environment to make. >> >> When using build-all.sh this is not possible any more, because >> build-all.sh calls make without honoring if BUILD_NUMBER was set in >> the environment. >> >> I've opened "CODETOOLS-7902089: build-all.sh should honor BUILD_NUMBER >> from environment (and use a reasonable default)" >> (https://bugs.openjdk.java.net/browse/CODETOOLS-7902089) and came up >> with the following fix: >> >> http://cr.openjdk.java.net/~simonis/webrevs/2017/CODETOOLS-7902089 >> >> As an extension I propose to set the build number by default to the >> latest available tag automatically, even if we're building tip because >> I think that's what users actually want (and need) if they build JTreg >> for executing the OpenJDK tests. This feature is already realized in >> my webrev. >> >> Finally, we could set the build number to something like "b11+" if >> "b11" was the latest tagged build, but we're several changes ahead >> already (this would resemble the "hg id" output which prints a "+" >> after the actual change hash if the working directory contains >> additional local changes). >> >> I consider this to be the best solution, but in order to work we would >> also have to update JTReg's build number parsing routine in >> com.sun.javatest.regtest.tool.Version.getBuild() which currently only >> accepts a plain build number (i.e. "b[0-9]+"). This feature is >> currently not in my webrev but I'd be happy to add it if you'd >> consider it useful. >> >> Can you please review and sponsor my change? >> >> Thank you and merry Christmas:) >> Volker >> >> >> >> On Thu, Dec 21, 2017 at 2:12 AM, Jonathan Gibbons >> wrote: >> >>> My previous message was intended for Mani. I'm sorry I did not make that >>> clearer. >>> >>> -- Jon >>> >>> On 12/20/2017 05:09 PM, Jonathan Gibbons wrote: >>> >>>> I've posted a new tag (jtreg4.2-b11) on the jtreg repo, so I would >>>> expect >>>> to see a new build on your CI system soon. >>>> >>>> If you're using the new make/build-all.sh script, then everything should >>>> build as intended. >>>> >>>> If you're not using build-all.sh, note that you need to build jtreg with >>>> variables like TESTNG_HOME, JUNIT_HOME, ASMTOOLS_HOME etc defined at the >>>> time you run "make". It is not enough to copy the corresponding jar >>>> files >>>> into the lib directory; they must also be put in the Class-Path entry >>>> of the >>>> jtreg.jar MANIFEST.MF file (and the makefiles will take care of doing >>>> that.) >>>> >>>> It occurs to me you might still be using the (old) Ant build.xml file. >>>> If >>>> so, I recommend you convert to using the new build-all.sh script. >>>> >>>> -- Jon >>>> >>>> On 12/19/2017 03:33 PM, Mani Sarkar wrote: >>>> >>>>> Hi Jon, >>>>> >>>>> Amended the scripts to use the latest build-all.sh from the tip, and >>>>> got >>>>> this - https://ci.adoptopenjdk.net/view/Dependencies/job/jtreg/. >>>>> >>>>> Still using our old script to build from the last tag. >>>>> >>>>> Both the artifacts do contain asmtools.jar - let me know if it passes >>>>> your sanity check. >>>>> >>>>> Thanks again. >>>>> >>>>> Cheers, >>>>> Mani >>>>> >>>>> On Mon, 18 Dec 2017 at 10:18 Maurizio Cimadamore >>>>> >>>> >> >>>>> wrote: >>>>> >>>>> >>>>> >>>>> On 18/12/17 01:32, Jonathan Gibbons wrote: >>>>> > Maurizio, >>>>> > >>>>> > If you can do this in a way that makes it optional, that would >>>>> be >>>>> > great. Having put effort into pruning the set of dependencies, >>>>> I've >>>>> > no desire to see the set creep up again unnecessarily, although >>>>> I >>>>> > admit the usefulness of the plugin. >>>>> Message understood :-) >>>>> >>>>> Btw, I'm bringing this up because, currently, the only way to >>>>> build the >>>>> plugin is through the IDE itself, which, while not unreasonable >>>>> (after >>>>> all you have to have an IDE if you want to use the plugin :-)), it >>>>> require some configuration and I've seen people getting stuck >>>>> quite >>>>> frequently - a build command would probably mitigate some of those >>>>> concerns. >>>>> >>>>> Maurizio >>>>> > >>>>> > -- Jon >>>>> > >>>>> > >>>>> > On 12/17/17 1:04 PM, Maurizio Cimadamore wrote: >>>>> >> Looks great - thanks for doing this. >>>>> >> >>>>> >> If there's interest, I could also put some effort in order to >>>>> >> integrate the plugins build into the system. In principle, it >>>>> should >>>>> >> be doable, by adding a bunch of env variables (to point at the >>>>> IDEA >>>>> >> runtime jar). Of course that would be an optional part of the >>>>> build. >>>>> >> >>>>> >> Cheers >>>>> >> Maurizio >>>>> >> >>>>> >> >>>>> >> On 14/12/17 00:32, Jonathan Gibbons wrote: >>>>> >>> This is for folk who are interested in building jtreg from >>>>> source. >>>>> >>> >>>>> >>> As some of you have (rightfully) commented over the past >>>>> years, >>>>> >>> jtreg has not been an easy tool to build from source. >>>>> >>> >>>>> >>> And, as some of you may have noticed, there has been some >>>>> amount of >>>>> >>> activity over the past weeks and months to address this issue. >>>>> This >>>>> >>> work has been led by Erik Helin (thanks, Erik!) and we're now >>>>> >>> getting to the point where we can show what we have been >>>>> working >>>>> >>> towards. >>>>> >>> >>>>> >>> The core of the work to build jtreg is still the Makefiles as >>>>> >>> before, although as was recently noted, we've been simplifying >>>>> the >>>>> >>> specification of the dependencies. >>>>> >>> >>>>> >>> Separately, Erik has helped provide updates to the way that >>>>> some of >>>>> >>> the Code Tools dependencies can be built. >>>>> >>> >>>>> >>> Building on all that work, we can now get to the next stage, >>>>> to >>>>> >>> provide a script that will download binaries for some >>>>> components >>>>> >>> (JUnit, TestNG) and will download and build source for other >>>>> >>> components (AsmTools, JCov, JTHarness), for which there are no >>>>> >>> official binaries. >>>>> >>> >>>>> >>> To run the script, you just need to have Ant and a suitable >>>>> "java" >>>>> >>> on your path, and to specify the location of an install of JDK >>>>> 1.8 >>>>> >>> as an argument to the script. wget is used to download files, >>>>> which >>>>> >>> honors proxy settings for those that need to use them. The >>>>> script is >>>>> >>> deliberately fairly simple, and suitable for use in a CI >>>>> system. >>>>> >>> >>>>> >>> You can see a webrev for the script at >>>>> >>> http://cr.openjdk.java.net/~jjg/7902083/webrev.00/ >>>>> >>>>> >>> >>>>> >>> Example of use: >>>>> >>> >>>>> >>> $ which ant >>>>> >>> /opt/ant/1.9.4/bin/ant >>>>> >>> $ which java >>>>> >>> /opt/jdk/1.8.0/bin/java >>>>> >>> $ sh make/build-all.sh /opt/jdk/1.8.0 >>>>> >>> ... build output ... >>>>> >>> $ ls build/images/jtreg >>>>> >>> bin COPYRIGHT doc legal lib LICENSE README release >>>>> >>> $ >>>>> >>> >>>>> >>> >>>>> >>> Once this settles down a bit, I'll update the public docs on >>>>> the >>>>> >>> jtreg web pages. >>>>> >>> >>>>> >>> -- Jon >>>>> >>> >>>>> >>> >>>>> >> >>>>> > >>>>> >>>>> -- >>>>> >>>>> @theNeomatrix369 | Blog >>>>> | @adoptopenjdk | Dev communities >>>>> >>>>> Meet-a-Project - MutabilityDetector >>>>> | Github >>>>> | Slideshare >>>>> |LinkedIn >>>>> >>>>> >>>>> Come to Devoxx UK 2018:http://www.devoxx.co.uk/ >>>>> >>>>> >>>>> Don't chase success, rather aim for "Excellence", and success will come >>>>> chasing after you! >>>>> >>>>> > From volker.simonis at gmail.com Fri Dec 22 15:21:29 2017 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 22 Dec 2017 15:21:29 -0000 Subject: CODETOOLS-7902083: Simplify building jtreg In-Reply-To: <5A3B0A7D.4030607@oracle.com> References: <5A31C69F.4090800@oracle.com> <7b8de36f-dbb2-9ddc-5f68-049c60bce314@oracle.com> <43aac4d2-b252-06ac-b900-bd6746013d47@oracle.com> <5A3B09B8.5050905@oracle.com> <5A3B0A7D.4030607@oracle.com> Message-ID: Hi Jonathan, thanks a lot for improving the build. This is a huge step ahead and it works great. I've just tried it and the build succeeded out of the box! There's however one issue I still see. The default build will set the version and build number to '4-2 dev b00'. Notice that such a build is pretty useless, because such versions of JTreg will be rejected when doing OpenJDK regression tests because the OpenJDK test have minimal JTreg build requirements in their TEST.ROOT file like for example: # Minimum jtreg version requiredVersion=4.2 b08 Before the introduction of build-all.sh it was possible to pass BUILD_NUMBER through the environment to make. When using build-all.sh this is not possible any more, because build-all.sh calls make without honoring if BUILD_NUMBER was set in the environment. I've opened "CODETOOLS-7902089: build-all.sh should honor BUILD_NUMBER from environment (and use a reasonable default)" (https://bugs.openjdk.java.net/browse/CODETOOLS-7902089) and came up with the following fix: http://cr.openjdk.java.net/~simonis/webrevs/2017/CODETOOLS-7902089 As an extension I propose to set the build number by default to the latest available tag automatically, even if we're building tip because I think that's what users actually want (and need) if they build JTreg for executing the OpenJDK tests. This feature is already realized in my webrev. Finally, we could set the build number to something like "b11+" if "b11" was the latest tagged build, but we're several changes ahead already (this would resemble the "hg id" output which prints a "+" after the actual change hash if the working directory contains additional local changes). I consider this to be the best solution, but in order to work we would also have to update JTReg's build number parsing routine in com.sun.javatest.regtest.tool.Version.getBuild() which currently only accepts a plain build number (i.e. "b[0-9]+"). This feature is currently not in my webrev but I'd be happy to add it if you'd consider it useful. Can you please review and sponsor my change? Thank you and merry Christmas:) Volker On Thu, Dec 21, 2017 at 2:12 AM, Jonathan Gibbons wrote: > My previous message was intended for Mani. I'm sorry I did not make that > clearer. > > -- Jon > > On 12/20/2017 05:09 PM, Jonathan Gibbons wrote: >> >> I've posted a new tag (jtreg4.2-b11) on the jtreg repo, so I would expect >> to see a new build on your CI system soon. >> >> If you're using the new make/build-all.sh script, then everything should >> build as intended. >> >> If you're not using build-all.sh, note that you need to build jtreg with >> variables like TESTNG_HOME, JUNIT_HOME, ASMTOOLS_HOME etc defined at the >> time you run "make". It is not enough to copy the corresponding jar files >> into the lib directory; they must also be put in the Class-Path entry of the >> jtreg.jar MANIFEST.MF file (and the makefiles will take care of doing that.) >> >> It occurs to me you might still be using the (old) Ant build.xml file. If >> so, I recommend you convert to using the new build-all.sh script. >> >> -- Jon >> >> On 12/19/2017 03:33 PM, Mani Sarkar wrote: >>> >>> Hi Jon, >>> >>> Amended the scripts to use the latest build-all.sh from the tip, and got >>> this - https://ci.adoptopenjdk.net/view/Dependencies/job/jtreg/. >>> >>> Still using our old script to build from the last tag. >>> >>> Both the artifacts do contain asmtools.jar - let me know if it passes >>> your sanity check. >>> >>> Thanks again. >>> >>> Cheers, >>> Mani >>> >>> On Mon, 18 Dec 2017 at 10:18 Maurizio Cimadamore >>> > >>> wrote: >>> >>> >>> >>> On 18/12/17 01:32, Jonathan Gibbons wrote: >>> > Maurizio, >>> > >>> > If you can do this in a way that makes it optional, that would be >>> > great. Having put effort into pruning the set of dependencies, >>> I've >>> > no desire to see the set creep up again unnecessarily, although I >>> > admit the usefulness of the plugin. >>> Message understood :-) >>> >>> Btw, I'm bringing this up because, currently, the only way to >>> build the >>> plugin is through the IDE itself, which, while not unreasonable >>> (after >>> all you have to have an IDE if you want to use the plugin :-)), it >>> require some configuration and I've seen people getting stuck quite >>> frequently - a build command would probably mitigate some of those >>> concerns. >>> >>> Maurizio >>> > >>> > -- Jon >>> > >>> > >>> > On 12/17/17 1:04 PM, Maurizio Cimadamore wrote: >>> >> Looks great - thanks for doing this. >>> >> >>> >> If there's interest, I could also put some effort in order to >>> >> integrate the plugins build into the system. In principle, it >>> should >>> >> be doable, by adding a bunch of env variables (to point at the >>> IDEA >>> >> runtime jar). Of course that would be an optional part of the >>> build. >>> >> >>> >> Cheers >>> >> Maurizio >>> >> >>> >> >>> >> On 14/12/17 00:32, Jonathan Gibbons wrote: >>> >>> This is for folk who are interested in building jtreg from >>> source. >>> >>> >>> >>> As some of you have (rightfully) commented over the past years, >>> >>> jtreg has not been an easy tool to build from source. >>> >>> >>> >>> And, as some of you may have noticed, there has been some >>> amount of >>> >>> activity over the past weeks and months to address this issue. >>> This >>> >>> work has been led by Erik Helin (thanks, Erik!) and we're now >>> >>> getting to the point where we can show what we have been working >>> >>> towards. >>> >>> >>> >>> The core of the work to build jtreg is still the Makefiles as >>> >>> before, although as was recently noted, we've been simplifying >>> the >>> >>> specification of the dependencies. >>> >>> >>> >>> Separately, Erik has helped provide updates to the way that >>> some of >>> >>> the Code Tools dependencies can be built. >>> >>> >>> >>> Building on all that work, we can now get to the next stage, to >>> >>> provide a script that will download binaries for some components >>> >>> (JUnit, TestNG) and will download and build source for other >>> >>> components (AsmTools, JCov, JTHarness), for which there are no >>> >>> official binaries. >>> >>> >>> >>> To run the script, you just need to have Ant and a suitable >>> "java" >>> >>> on your path, and to specify the location of an install of JDK >>> 1.8 >>> >>> as an argument to the script. wget is used to download files, >>> which >>> >>> honors proxy settings for those that need to use them. The >>> script is >>> >>> deliberately fairly simple, and suitable for use in a CI system. >>> >>> >>> >>> You can see a webrev for the script at >>> >>> http://cr.openjdk.java.net/~jjg/7902083/webrev.00/ >>> >>> >>> >>> >>> Example of use: >>> >>> >>> >>> $ which ant >>> >>> /opt/ant/1.9.4/bin/ant >>> >>> $ which java >>> >>> /opt/jdk/1.8.0/bin/java >>> >>> $ sh make/build-all.sh /opt/jdk/1.8.0 >>> >>> ... build output ... >>> >>> $ ls build/images/jtreg >>> >>> bin COPYRIGHT doc legal lib LICENSE README release >>> >>> $ >>> >>> >>> >>> >>> >>> Once this settles down a bit, I'll update the public docs on the >>> >>> jtreg web pages. >>> >>> >>> >>> -- Jon >>> >>> >>> >>> >>> >> >>> > >>> >>> -- >>> >>> @theNeomatrix369 | Blog >>> | @adoptopenjdk | Dev communities >>> >>> Meet-a-Project - MutabilityDetector >>> | Github >>> | Slideshare >>> |LinkedIn >>> >>> >>> Come to Devoxx UK 2018:http://www.devoxx.co.uk/ >>> >>> >>> Don't chase success, rather aim for "Excellence", and success will come >>> chasing after you! >>> >> > From volker.simonis at gmail.com Sat Dec 23 17:26:09 2017 From: volker.simonis at gmail.com (Volker Simonis) Date: Sat, 23 Dec 2017 17:26:09 -0000 Subject: CODETOOLS-7902083: Simplify building jtreg In-Reply-To: <5A3D5F9E.6080905@oracle.com> References: <5A31C69F.4090800@oracle.com> <7b8de36f-dbb2-9ddc-5f68-049c60bce314@oracle.com> <43aac4d2-b252-06ac-b900-bd6746013d47@oracle.com> <5A3B09B8.5050905@oracle.com> <5A3B0A7D.4030607@oracle.com> <5A3D5F9E.6080905@oracle.com> Message-ID: Thanks for pushing! Jonathan Gibbons schrieb am Fr. 22. Dez. 2017 um 20:44: > Volker, > > Thank you for noting the BUILD_NUMBER problem. > I've pushed your fix (with a minor tweak to the syntax for consistency). > I think there may be more changes to come, but your patch at least > addresses the ability to pass through the BUILD_* info. > > I don't think that patching the code for the build number is the way > to go. I think the "milestone" field is a better field to indicate > deviations from a standard build. We might also want to look at > aligning the syntax of tags and version strings with OpenJDK. > > Various folk have suggested some other minor improvements to the > script in general, and I'll look at incorporating those changes as well. > > -- Jon > > On 12/22/2017 07:17 AM, Volker Simonis wrote: > > Hi Jonathan, > > > > thanks a lot for improving the build. This is a huge step ahead and it > > works great. I've just tried it and the build succeeded out of the > > box! > > > > There's however one issue I still see. The default build will set the > > version and build number to '4-2 dev b00'. Notice that such a build is > > pretty useless, because such versions of JTreg will be rejected when > > doing OpenJDK regression tests because the OpenJDK test have minimal > > JTreg build requirements in their TEST.ROOT file like for example: > > > > # Minimum jtreg version > > requiredVersion=4.2 b08 > > > > Before the introduction of build-all.sh it was possible to pass > > BUILD_NUMBER through the environment to make. > > > > When using build-all.sh this is not possible any more, because > > build-all.sh calls make without honoring if BUILD_NUMBER was set in > > the environment. > > > > I've opened "CODETOOLS-7902089: build-all.sh should honor BUILD_NUMBER > > from environment (and use a reasonable default)" > > (https://bugs.openjdk.java.net/browse/CODETOOLS-7902089) and came up > > with the following fix: > > > > http://cr.openjdk.java.net/~simonis/webrevs/2017/CODETOOLS-7902089 > > > > As an extension I propose to set the build number by default to the > > latest available tag automatically, even if we're building tip because > > I think that's what users actually want (and need) if they build JTreg > > for executing the OpenJDK tests. This feature is already realized in > > my webrev. > > > > Finally, we could set the build number to something like "b11+" if > > "b11" was the latest tagged build, but we're several changes ahead > > already (this would resemble the "hg id" output which prints a "+" > > after the actual change hash if the working directory contains > > additional local changes). > > > > I consider this to be the best solution, but in order to work we would > > also have to update JTReg's build number parsing routine in > > com.sun.javatest.regtest.tool.Version.getBuild() which currently only > > accepts a plain build number (i.e. "b[0-9]+"). This feature is > > currently not in my webrev but I'd be happy to add it if you'd > > consider it useful. > > > > Can you please review and sponsor my change? > > > > Thank you and merry Christmas:) > > Volker > > > > > > > > On Thu, Dec 21, 2017 at 2:12 AM, Jonathan Gibbons > > wrote: > >> My previous message was intended for Mani. I'm sorry I did not make that > >> clearer. > >> > >> -- Jon > >> > >> On 12/20/2017 05:09 PM, Jonathan Gibbons wrote: > >>> I've posted a new tag (jtreg4.2-b11) on the jtreg repo, so I would > expect > >>> to see a new build on your CI system soon. > >>> > >>> If you're using the new make/build-all.sh script, then everything > should > >>> build as intended. > >>> > >>> If you're not using build-all.sh, note that you need to build jtreg > with > >>> variables like TESTNG_HOME, JUNIT_HOME, ASMTOOLS_HOME etc defined at > the > >>> time you run "make". It is not enough to copy the corresponding jar > files > >>> into the lib directory; they must also be put in the Class-Path entry > of the > >>> jtreg.jar MANIFEST.MF file (and the makefiles will take care of doing > that.) > >>> > >>> It occurs to me you might still be using the (old) Ant build.xml > file. If > >>> so, I recommend you convert to using the new build-all.sh script. > >>> > >>> -- Jon > >>> > >>> On 12/19/2017 03:33 PM, Mani Sarkar wrote: > >>>> Hi Jon, > >>>> > >>>> Amended the scripts to use the latest build-all.sh from the tip, and > got > >>>> this - https://ci.adoptopenjdk.net/view/Dependencies/job/jtreg/. > >>>> > >>>> Still using our old script to build from the last tag. > >>>> > >>>> Both the artifacts do contain asmtools.jar - let me know if it passes > >>>> your sanity check. > >>>> > >>>> Thanks again. > >>>> > >>>> Cheers, > >>>> Mani > >>>> > >>>> On Mon, 18 Dec 2017 at 10:18 Maurizio Cimadamore > >>>> maurizio.cimadamore at oracle.com>> > >>>> wrote: > >>>> > >>>> > >>>> > >>>> On 18/12/17 01:32, Jonathan Gibbons wrote: > >>>> > Maurizio, > >>>> > > >>>> > If you can do this in a way that makes it optional, that would > be > >>>> > great. Having put effort into pruning the set of > dependencies, > >>>> I've > >>>> > no desire to see the set creep up again unnecessarily, > although I > >>>> > admit the usefulness of the plugin. > >>>> Message understood :-) > >>>> > >>>> Btw, I'm bringing this up because, currently, the only way to > >>>> build the > >>>> plugin is through the IDE itself, which, while not unreasonable > >>>> (after > >>>> all you have to have an IDE if you want to use the plugin :-)), > it > >>>> require some configuration and I've seen people getting stuck > quite > >>>> frequently - a build command would probably mitigate some of > those > >>>> concerns. > >>>> > >>>> Maurizio > >>>> > > >>>> > -- Jon > >>>> > > >>>> > > >>>> > On 12/17/17 1:04 PM, Maurizio Cimadamore wrote: > >>>> >> Looks great - thanks for doing this. > >>>> >> > >>>> >> If there's interest, I could also put some effort in order to > >>>> >> integrate the plugins build into the system. In principle, it > >>>> should > >>>> >> be doable, by adding a bunch of env variables (to point at the > >>>> IDEA > >>>> >> runtime jar). Of course that would be an optional part of the > >>>> build. > >>>> >> > >>>> >> Cheers > >>>> >> Maurizio > >>>> >> > >>>> >> > >>>> >> On 14/12/17 00:32, Jonathan Gibbons wrote: > >>>> >>> This is for folk who are interested in building jtreg from > >>>> source. > >>>> >>> > >>>> >>> As some of you have (rightfully) commented over the past > years, > >>>> >>> jtreg has not been an easy tool to build from source. > >>>> >>> > >>>> >>> And, as some of you may have noticed, there has been some > >>>> amount of > >>>> >>> activity over the past weeks and months to address this > issue. > >>>> This > >>>> >>> work has been led by Erik Helin (thanks, Erik!) and we're now > >>>> >>> getting to the point where we can show what we have been > working > >>>> >>> towards. > >>>> >>> > >>>> >>> The core of the work to build jtreg is still the Makefiles as > >>>> >>> before, although as was recently noted, we've been > simplifying > >>>> the > >>>> >>> specification of the dependencies. > >>>> >>> > >>>> >>> Separately, Erik has helped provide updates to the way that > >>>> some of > >>>> >>> the Code Tools dependencies can be built. > >>>> >>> > >>>> >>> Building on all that work, we can now get to the next stage, > to > >>>> >>> provide a script that will download binaries for some > components > >>>> >>> (JUnit, TestNG) and will download and build source for other > >>>> >>> components (AsmTools, JCov, JTHarness), for which there are > no > >>>> >>> official binaries. > >>>> >>> > >>>> >>> To run the script, you just need to have Ant and a suitable > >>>> "java" > >>>> >>> on your path, and to specify the location of an install of > JDK > >>>> 1.8 > >>>> >>> as an argument to the script. wget is used to download files, > >>>> which > >>>> >>> honors proxy settings for those that need to use them. The > >>>> script is > >>>> >>> deliberately fairly simple, and suitable for use in a CI > system. > >>>> >>> > >>>> >>> You can see a webrev for the script at > >>>> >>> http://cr.openjdk.java.net/~jjg/7902083/webrev.00/ > >>>> > >>>> >>> > >>>> >>> Example of use: > >>>> >>> > >>>> >>> $ which ant > >>>> >>> /opt/ant/1.9.4/bin/ant > >>>> >>> $ which java > >>>> >>> /opt/jdk/1.8.0/bin/java > >>>> >>> $ sh make/build-all.sh /opt/jdk/1.8.0 > >>>> >>> ... build output ... > >>>> >>> $ ls build/images/jtreg > >>>> >>> bin COPYRIGHT doc legal lib LICENSE README release > >>>> >>> $ > >>>> >>> > >>>> >>> > >>>> >>> Once this settles down a bit, I'll update the public docs on > the > >>>> >>> jtreg web pages. > >>>> >>> > >>>> >>> -- Jon > >>>> >>> > >>>> >>> > >>>> >> > >>>> > > >>>> > >>>> -- > >>>> > >>>> @theNeomatrix369 | Blog > >>>> | @adoptopenjdk | Dev > communities > >>>> > >>>> Meet-a-Project - MutabilityDetector > >>>> | Github > >>>> | Slideshare > >>>> |LinkedIn > >>>> > >>>> > >>>> Come to Devoxx UK 2018:http://www.devoxx.co.uk/ > >>>> > >>>> > >>>> Don't chase success, rather aim for "Excellence", and success will > come > >>>> chasing after you! > >>>> > > From volker.simonis at gmail.com Sat Dec 23 17:31:43 2017 From: volker.simonis at gmail.com (Volker Simonis) Date: Sat, 23 Dec 2017 17:31:43 -0000 Subject: CODETOOLS-7902083: Simplify building jtreg In-Reply-To: References: <5A31C69F.4090800@oracle.com> <7b8de36f-dbb2-9ddc-5f68-049c60bce314@oracle.com> <43aac4d2-b252-06ac-b900-bd6746013d47@oracle.com> <5A3B09B8.5050905@oracle.com> <5A3B0A7D.4030607@oracle.com> Message-ID: Martin Buchholz schrieb am Fr. 22. Dez. 2017 um 18:58: > I agree having to fiddle with the build number is a pain point, but it's > shared with openjdk proper. > > You can't rely on mercurial tags; code can get moved out of mercurial (hg > archive) or into a different source code system. > I agree, but this change should at least help the average user who starts by cloning the Mercurial repo. That doesn?t mean I?m not open for further improvements ;) > I would prefer BUILD_NUMBER checked in, and write a little script that > modified the source and hg tagged it at the same time. And then of course > check in the script! > > On Fri, Dec 22, 2017 at 7:17 AM, Volker Simonis > wrote: > >> Hi Jonathan, >> >> thanks a lot for improving the build. This is a huge step ahead and it >> works great. I've just tried it and the build succeeded out of the >> box! >> >> There's however one issue I still see. The default build will set the >> version and build number to '4-2 dev b00'. Notice that such a build is >> pretty useless, because such versions of JTreg will be rejected when >> doing OpenJDK regression tests because the OpenJDK test have minimal >> JTreg build requirements in their TEST.ROOT file like for example: >> >> # Minimum jtreg version >> requiredVersion=4.2 b08 >> >> Before the introduction of build-all.sh it was possible to pass >> BUILD_NUMBER through the environment to make. >> >> When using build-all.sh this is not possible any more, because >> build-all.sh calls make without honoring if BUILD_NUMBER was set in >> the environment. >> >> I've opened "CODETOOLS-7902089: build-all.sh should honor BUILD_NUMBER >> from environment (and use a reasonable default)" >> (https://bugs.openjdk.java.net/browse/CODETOOLS-7902089) and came up >> with the following fix: >> >> http://cr.openjdk.java.net/~simonis/webrevs/2017/CODETOOLS-7902089 >> >> As an extension I propose to set the build number by default to the >> latest available tag automatically, even if we're building tip because >> I think that's what users actually want (and need) if they build JTreg >> for executing the OpenJDK tests. This feature is already realized in >> my webrev. >> >> Finally, we could set the build number to something like "b11+" if >> "b11" was the latest tagged build, but we're several changes ahead >> already (this would resemble the "hg id" output which prints a "+" >> after the actual change hash if the working directory contains >> additional local changes). >> >> I consider this to be the best solution, but in order to work we would >> also have to update JTReg's build number parsing routine in >> com.sun.javatest.regtest.tool.Version.getBuild() which currently only >> accepts a plain build number (i.e. "b[0-9]+"). This feature is >> currently not in my webrev but I'd be happy to add it if you'd >> consider it useful. >> >> Can you please review and sponsor my change? >> >> Thank you and merry Christmas:) >> Volker >> >> >> >> On Thu, Dec 21, 2017 at 2:12 AM, Jonathan Gibbons >> wrote: >> > My previous message was intended for Mani. I'm sorry I did not make that >> > clearer. >> > >> > -- Jon >> > >> > On 12/20/2017 05:09 PM, Jonathan Gibbons wrote: >> >> >> >> I've posted a new tag (jtreg4.2-b11) on the jtreg repo, so I would >> expect >> >> to see a new build on your CI system soon. >> >> >> >> If you're using the new make/build-all.sh script, then everything >> should >> >> build as intended. >> >> >> >> If you're not using build-all.sh, note that you need to build jtreg >> with >> >> variables like TESTNG_HOME, JUNIT_HOME, ASMTOOLS_HOME etc defined at >> the >> >> time you run "make". It is not enough to copy the corresponding jar >> files >> >> into the lib directory; they must also be put in the Class-Path entry >> of the >> >> jtreg.jar MANIFEST.MF file (and the makefiles will take care of doing >> that.) >> >> >> >> It occurs to me you might still be using the (old) Ant build.xml >> file. If >> >> so, I recommend you convert to using the new build-all.sh script. >> >> >> >> -- Jon >> >> >> >> On 12/19/2017 03:33 PM, Mani Sarkar wrote: >> >>> >> >>> Hi Jon, >> >>> >> >>> Amended the scripts to use the latest build-all.sh from the tip, and >> got >> >>> this - https://ci.adoptopenjdk.net/view/Dependencies/job/jtreg/. >> >>> >> >>> Still using our old script to build from the last tag. >> >>> >> >>> Both the artifacts do contain asmtools.jar - let me know if it passes >> >>> your sanity check. >> >>> >> >>> Thanks again. >> >>> >> >>> Cheers, >> >>> Mani >> >>> >> >>> On Mon, 18 Dec 2017 at 10:18 Maurizio Cimadamore >> >>> > maurizio.cimadamore at oracle.com>> >> >>> wrote: >> >>> >> >>> >> >>> >> >>> On 18/12/17 01:32, Jonathan Gibbons wrote: >> >>> > Maurizio, >> >>> > >> >>> > If you can do this in a way that makes it optional, that would >> be >> >>> > great. Having put effort into pruning the set of dependencies, >> >>> I've >> >>> > no desire to see the set creep up again unnecessarily, although >> I >> >>> > admit the usefulness of the plugin. >> >>> Message understood :-) >> >>> >> >>> Btw, I'm bringing this up because, currently, the only way to >> >>> build the >> >>> plugin is through the IDE itself, which, while not unreasonable >> >>> (after >> >>> all you have to have an IDE if you want to use the plugin :-)), it >> >>> require some configuration and I've seen people getting stuck >> quite >> >>> frequently - a build command would probably mitigate some of those >> >>> concerns. >> >>> >> >>> Maurizio >> >>> > >> >>> > -- Jon >> >>> > >> >>> > >> >>> > On 12/17/17 1:04 PM, Maurizio Cimadamore wrote: >> >>> >> Looks great - thanks for doing this. >> >>> >> >> >>> >> If there's interest, I could also put some effort in order to >> >>> >> integrate the plugins build into the system. In principle, it >> >>> should >> >>> >> be doable, by adding a bunch of env variables (to point at the >> >>> IDEA >> >>> >> runtime jar). Of course that would be an optional part of the >> >>> build. >> >>> >> >> >>> >> Cheers >> >>> >> Maurizio >> >>> >> >> >>> >> >> >>> >> On 14/12/17 00:32, Jonathan Gibbons wrote: >> >>> >>> This is for folk who are interested in building jtreg from >> >>> source. >> >>> >>> >> >>> >>> As some of you have (rightfully) commented over the past >> years, >> >>> >>> jtreg has not been an easy tool to build from source. >> >>> >>> >> >>> >>> And, as some of you may have noticed, there has been some >> >>> amount of >> >>> >>> activity over the past weeks and months to address this issue. >> >>> This >> >>> >>> work has been led by Erik Helin (thanks, Erik!) and we're now >> >>> >>> getting to the point where we can show what we have been >> working >> >>> >>> towards. >> >>> >>> >> >>> >>> The core of the work to build jtreg is still the Makefiles as >> >>> >>> before, although as was recently noted, we've been simplifying >> >>> the >> >>> >>> specification of the dependencies. >> >>> >>> >> >>> >>> Separately, Erik has helped provide updates to the way that >> >>> some of >> >>> >>> the Code Tools dependencies can be built. >> >>> >>> >> >>> >>> Building on all that work, we can now get to the next stage, >> to >> >>> >>> provide a script that will download binaries for some >> components >> >>> >>> (JUnit, TestNG) and will download and build source for other >> >>> >>> components (AsmTools, JCov, JTHarness), for which there are no >> >>> >>> official binaries. >> >>> >>> >> >>> >>> To run the script, you just need to have Ant and a suitable >> >>> "java" >> >>> >>> on your path, and to specify the location of an install of JDK >> >>> 1.8 >> >>> >>> as an argument to the script. wget is used to download files, >> >>> which >> >>> >>> honors proxy settings for those that need to use them. The >> >>> script is >> >>> >>> deliberately fairly simple, and suitable for use in a CI >> system. >> >>> >>> >> >>> >>> You can see a webrev for the script at >> >>> >>> http://cr.openjdk.java.net/~jjg/7902083/webrev.00/ >> >>> >> >>> >>> >> >>> >>> Example of use: >> >>> >>> >> >>> >>> $ which ant >> >>> >>> /opt/ant/1.9.4/bin/ant >> >>> >>> $ which java >> >>> >>> /opt/jdk/1.8.0/bin/java >> >>> >>> $ sh make/build-all.sh /opt/jdk/1.8.0 >> >>> >>> ... build output ... >> >>> >>> $ ls build/images/jtreg >> >>> >>> bin COPYRIGHT doc legal lib LICENSE README release >> >>> >>> $ >> >>> >>> >> >>> >>> >> >>> >>> Once this settles down a bit, I'll update the public docs on >> the >> >>> >>> jtreg web pages. >> >>> >>> >> >>> >>> -- Jon >> >>> >>> >> >>> >>> >> >>> >> >> >>> > >> >>> >> >>> -- >> >>> >> >>> @theNeomatrix369 | Blog >> >>> | @adoptopenjdk | Dev >> communities >> >>> >> >>> Meet-a-Project - MutabilityDetector >> >>> | Github >> >>> | Slideshare >> >>> |LinkedIn >> >>> >> >>> >> >>> Come to Devoxx UK 2018:http://www.devoxx.co.uk/ >> >>> >> >>> >> >>> Don't chase success, rather aim for "Excellence", and success will >> come >> >>> chasing after you! >> >>> >> >> >> > >> > >