CODETOOLS-7902083: Simplify building jtreg
Volker Simonis
volker.simonis at gmail.com
Sat Dec 23 17:22:11 UTC 2017
Thanks for pushing!
Jonathan Gibbons <jonathan.gibbons at oracle.com> 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
> > <jonathan.gibbons at oracle.com> 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 <mailto:
> 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/
> >>>> <http://cr.openjdk.java.net/%7Ejjg/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 <http://twitter.com/theNeomatrix369> | Blog
> >>>> <http://neomatrix369.wordpress.com/> | @adoptopenjdk | Dev
> communities
> >>>>
> >>>> Meet-a-Project - MutabilityDetector
> >>>> <https://github.com/MutabilityDetector> | Github
> >>>> <https://github.com/neomatrix369> | Slideshare
> >>>> <https://www.slideshare.net/neomatrix369> |LinkedIn
> >>>> <http://uk.linkedin.com/pub/mani-sarkar/71/a77/39b>
> >>>>
> >>>> 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!
> >>>>
>
>
More information about the code-tools-dev
mailing list