[rfc] jtreg's jenkins out of sync?

Sun Apr 19 18:07:04 UTC 2015

Hi all,

For those wondering, this resolved itself.

Cheers,
Martijn

On 17 April 2015 at 18:09, Jiri Vanek <jvanek at redhat.com> wrote:

>
> Hi!
>
> Maybe I'm wrong, but it seems to me that jenkins is not pulling latest
> changesets as expected:
>
> Look to the:
> https://adopt-openjdk.ci.cloudbees.com/job/jtreg/265/
> It is now latest build. It clearly says that it was started by scm change,
> last change is the jdk.version.major bla bla bal...
>
> But - download the jar and you will find my changeset missing.
> Looking to the output:
> https://adopt-openjdk.ci.cloudbees.com/job/jtreg/265/consoleText
>
> It clearly says:
> $ hg clone --rev default --noupdate
> http://hg.openjdk.java.net/code-tools/jtreg
> /scratch/jenkins/workspace/jtreg
> adding changesets
> adding manifests
> adding file changes
> added 157 changesets with 1542 changes to 650 files
> [jtreg] $ hg update --rev default
> 623 files updated, 0 files merged, 0 files removed, 0 files unresolved
> [jtreg] $ hg log --rev . --template {node}
> [jtreg] $ hg log --rev . --template {rev}
> [jtreg] $ hg log --rev e88738b571dee0fb28e40ef14260b78fa267e4f3
> changeset:   155:e88738b571de
> user:        jjg
> date:        Mon Mar 30 17:56:11 2015 -0700
> summary:     Improved asmtools handling
>
>
> Which is the my_comit-1. And is Also a bit surprising. Because my
> Changeset had id 156. The clone cloned 157 chnagesets but as tip was used
> 155.
>
> So maybe there is -2 instead -1 somewhere :))
>
> Nope, joking... If you may fix/reschedule whatever I will be glad. I do
> not wont to upload on my machines my self built version.
>
>
> TY and sorry if I'm wrong...
>
> J.
>
>
>
>> -- Jon
>>
>> On 04/16/2015 12:16 AM, Jiri Vanek wrote:
>>
>>> On 04/15/2015 06:51 PM, Jonathan Gibbons wrote:
>>>
>>>> Jiri,
>>>>
>>>> Thanks.
>>>>
>>>> On the build.xml, I note that "make" is the preferred way to build and
>>>> test jtreg; the Ant file is
>>>>
>>>
>>> Yes. I understand it.
>>>
>>>> provided as a convenience for use while working in an IDE like
>>>> NetBeans. It was not practical to
>>>>
>>> And it is very cool :)
>>>
>>>  port all the tests from the "make" world into the Ant world, and so
>>>> "make" remains the definitive
>>>>
>>>
>>> Sure.
>>>
>>>> build tool.  Looking at your build change, while jh.jar is required, it
>>>> is normally pulled in
>>>> because of a Class-Path reference in javatest.jar, but perhaps you
>>>> don't have that reference in your
>>>> build of javatest.jar.
>>>>
>>>
>>> Thats weird. It have:
>>>
>>>  unzip -p /opt/jtharness/4.3/lib/javatest.jar META-INF/MANIFEST.MF |
>>> grep Class-Path
>>> Class-Path: jh.jar
>>>
>>> Is the change acceptable (no meter of build.xml hunk)? If so, when it
>>> can be expected to be seen in jenkins build?
>>>
>>> J
>>>
>>>
>>>> -- Jon
>>>>
>>>> On 04/15/2015 08:40 AM, Jiri Vanek wrote:
>>>>
>>>>> Hi Jonatan.
>>>>>
>>>>>
>>>>> So here you have pacth with this functionality. Tested on jdk 7 and 8
>>>>> and works fine.
>>>>>
>>>>> The change was really minimalistical - your engine eems to be prepared
>>>>> for it! Grate:)
>>>>>
>>>>> You may note one change in build.xml - feel free to discard it, but I
>>>>> was not able to build
>>>>> without it.
>>>>>
>>>>>
>>>>> Thanx!
>>>>>
>>>>>  J.
>>>>>
>>>>> On 04/11/2015 03:26 AM, Jonathan Gibbons wrote:
>>>>>
>>>>>> Jiri,
>>>>>>
>>>>>> How about a variant of 0, which is to define a new property, perhaps
>>>>>> called "jdk.version.major" or
>>>>>> something like that, which is defined to be a simple integer, for
>>>>>> easy use with the existing
>>>>>> comparison mechanism.  That leaves open the use for jdk.version to be
>>>>>> a more detailed string, with
>>>>>> potentially the possibility of doing version comparisons later on, if
>>>>>> that should prove necessary.
>>>>>>
>>>>>> -- Jon
>>>>>>
>>>>>>
>>>>>> On 04/10/2015 03:11 AM, Jiri Vanek wrote:
>>>>>>
>>>>>>> On 04/09/2015 05:30 PM, Jonathan Gibbons wrote:
>>>>>>>
>>>>>>>> The current behavior of the jdk.version has been to return 1.major
>>>>>>>> for existing releases, with
>>>>>>>> the
>>>>>>>> proposal to go to something beginning with 9 for JDK 9 onwards.
>>>>>>>>
>>>>>>>>
>>>>>>> 0. Yes. Thats definitely the right thing to do.
>>>>>>>
>>>>>>> So why not to "just keep backward compatibility for jdk5-8" ? If
>>>>>>> returned version would match
>>>>>>> 1.{5,6,7,8}.X consider it as 5,6,7 or 8?
>>>>>>>
>>>>>>> The touch in code will be minimalist, we will be in safe integers,
>>>>>>>
>>>>>>>  I don't think it is right to renumber releases in hindsight.
>>>>>>>> jdk.version should stay "reasonably
>>>>>>>> close" to the beginning of the string obtained from "java -version".
>>>>>>>>
>>>>>>>> So that means we have the following possibilities:
>>>>>>>> 1. only allow one dot, and treat these numbers as floating point.
>>>>>>>> That's pretty hacky.
>>>>>>>>
>>>>>>>
>>>>>>> I like this:) But yes.. it is hacky :(  And you will still need
>>>>>>> handle other possible dots after
>>>>>>> first (eg removal of all no digit chars?)
>>>>>>>
>>>>>>> Although it may be pretty powerfull at the end, it may be confusing
>>>>>>> even misleading
>>>>>>> (eg 1.7.a5 will suddenly be lower hiogher then 1.7.b4 and many
>>>>>>> similar and much less visible)
>>>>>>>
>>>>>>>  2. introduce "version types" into the @requires expression engine,
>>>>>>>> and make the relation operators
>>>>>>>> polymorphic
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Well this may be pretty cool, and will solve the issue with jtregs
>>>>>>> testing features like nimbus
>>>>>>> (mentioned somewhere in this thread..)
>>>>>>>
>>>>>>>
>>>>>>> So long story short.  I vote for *0* for it simplicity. But if you
>>>>>>> think 2 is worthy of effort
>>>>>>> then why not . But design will need much more thinking then I
>>>>>>> originally hoped to sacrifice. But I
>>>>>>> think it is not worthy.
>>>>>>>
>>>>>>>
>>>>>>> Also I guess I can not have final word as you are an guru here. So
>>>>>>> whatever you suppose is good, I
>>>>>>> can start to work on it.
>>>>>>>
>>>>>>> Thanx!
>>>>>>>
>>>>>>>   J.
>>>>>>>
>>>>>>>>
>>>>>>>> -- Jon
>>>>>>>>
>>>>>>>> On 04/09/2015 12:53 AM, Jiri Vanek wrote:
>>>>>>>>
>>>>>>>>> ping?
>>>>>>>>>
>>>>>>>>> If the most simple way is the way to go, then - as your initial
>>>>>>>>> impl is based on jdk9, so it
>>>>>>>>> expect one number on each side, then simple extending for backward
>>>>>>>>> ocmpatibility to change
>>>>>>>>> 1.{8,7,6,5}.whatever to simple number should be right thing to do
>>>>>>>>> an easy way to go.
>>>>>>>>>
>>>>>>>>> Any more granular thoughts may come in later.
>>>>>>>>>
>>>>>>>>> Can I proceed with this patch?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Thank you,
>>>>>>>>>   J.
>>>>>>>>>
>>>>>>>>> On 04/02/2015 01:12 PM, Jiri Vanek wrote:
>>>>>>>>>
>>>>>>>>>> One more hint.
>>>>>>>>>>
>>>>>>>>>> When I originally read
>>>>>>>>>>
>>>>>>>>>>  > 4. @requires. This is a relatively new feature. You can put a
>>>>>>>>>> declarative tag in a test
>>>>>>>>>> description
>>>>>>>>>>  > of the form "@requires expr" where there is a variety of
>>>>>>>>>> terminals, of which jdk.version
>>>>>>>>>> is but
>>>>>>>>>>  > one.   So you could add a line like
>>>>>>>>>>  >      @requires  jdk.version <=1.6 || jdk.version >1.7 ||
>>>>>>>>>> jdk.version = "1.4.2"
>>>>>>>>>>  > Not as compact as your proposal, but it exists today.
>>>>>>>>>>
>>>>>>>>>> It seemed to me that full version sort is included.
>>>>>>>>>>
>>>>>>>>>> so eg  1.4.2 < 1.8 < 9 < 9.2
>>>>>>>>>> but also 1.7.0_20 < 1.7.0_40
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Also my original impression from jep was, that backward
>>>>>>>>>> compatibility returnnig 1.9.0_X will be
>>>>>>>>>> preserved.
>>>>>>>>>>
>>>>>>>>>> Currently I do not need this, but my colleague mentioned cases
>>>>>>>>>> where it can be useful.
>>>>>>>>>> Eg nimbus  was introduced in uSomething. So any tests to nimbus
>>>>>>>>>> would have @requires >=
>>>>>>>>>> 1.7.0_Something (instead of programmed failback "if no nimbus
>>>>>>>>>> then exit 0" :)
>>>>>>>>>>
>>>>>>>>>> Maybe it is really not needed, but when such an nice feature
>>>>>>>>>> started to exists, it would be
>>>>>>>>>> nice to
>>>>>>>>>> have it as capable as possible.
>>>>>>>>>>
>>>>>>>>>> J.
>>>>>>>>>>
>>>>>>>>>> On 04/02/2015 11:19 AM, Jiri Vanek wrote:
>>>>>>>>>>
>>>>>>>>>>> On 04/01/2015 08:32 PM, Jonathan Gibbons wrote:
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On 04/01/2015 10:34 AM, Jiri Vanek wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>>   * @requires jdk.version <= 7
>>>>>>>>>>>>>> leads to
>>>>>>>>>>>>>> test result: Error. Error evaluating expression: invalid
>>>>>>>>>>>>>> numeric value: 1.8
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Is it expected bahviour? I tried also with various
>>>>>>>>>>>>>> spaces/nospace....
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>  ping? Is it expected? If not, I will provide you a fix.
>>>>>>>>>>>>>
>>>>>>>>>>>>> J.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> With hindsight, I can see that this is to be expected, which is
>>>>>>>>>>>> not to say that it is good.
>>>>>>>>>>>>
>>>>>>>>>>>> Going forward, I'm not sure what the correct fix will be,
>>>>>>>>>>>> especially given the upcoming JEP
>>>>>>>>>>>> for
>>>>>>>>>>>> semantic versioning.
>>>>>>>>>>>> http://openjdk.java.net/jeps/223
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Yes, I'm aware of this jep.
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Before you provide a fix, I'd be interested to hear suggestions
>>>>>>>>>>>> on what the fix should be.
>>>>>>>>>>>> One
>>>>>>>>>>>> solution is that we should just allow numbers to be represented
>>>>>>>>>>>> as Double as well as Long. A
>>>>>>>>>>>> different solution would be to introduce a "version" type
>>>>>>>>>>>> somehow.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> When I saw the behavior, And realized that jep 233 was target, I
>>>>>>>>>>> was thinking  that
>>>>>>>>>>>  >>>   * @requires jdk.version <= 7
>>>>>>>>>>>  >>> leads to
>>>>>>>>>>>  >>> test result: Error. Error evaluating expression: invalid
>>>>>>>>>>> numeric value: 1.8
>>>>>>>>>>>
>>>>>>>>>>> Is correct way to do. And so, if this Error is hit, try to
>>>>>>>>>>> remove leading 1. and strip all
>>>>>>>>>>> behind
>>>>>>>>>>> next dot including that dot.
>>>>>>>>>>>
>>>>>>>>>>> For jdk9+ single number is expected.
>>>>>>>>>>>
>>>>>>>>>>> Otherwise the qeustion is a bit different. What is expected from
>>>>>>>>>>> "jdk.version" Only mayor
>>>>>>>>>>> number
>>>>>>>>>>> like 1.4.2, 1.7.0, 1.8.0, 9, 10, or more detailed version?
>>>>>>>>>>>
>>>>>>>>>>> I would vote for that simple approach, but probably only because
>>>>>>>>>>> it suits my needs now.
>>>>>>>>>>> Cases like 1.4.2 in past 1.4.0 may be expected... But still, non
>>>>>>>>>>> of those should causes
>>>>>>>>>>> compilation
>>>>>>>>>>> incompatibility.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Thank you very much for cooperation!
>>>>>>>>>>>   J.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
>
>