Clean up version numbers from all system test prereq jars and their references

Question

Clean up version numbers from all system test prereq jars and their references

Mesbah-Alam opened this issue 4 years ago · comments

Copying @llxia 's comment from #97 (comment):

"Could we not include the version in the jar name? Instead of downloading into asm-9.0/asm-9.0.jar, just use a generic name. For example, asm.jar. If we do it this way, we do not need to update the folder and file name for every version update in adoptium/aqa-systemtest#387 and https://github.com/AdoptOpenJDK/openjdk-tests/pull/2126/files "

We can update the logic in top.xml and have a generic name for the destination file for asm.jar and use that in all places where it's referenced.

This will indeed make it easier to update ASM Jar.

FYI @lumpfish

Simon Rushton · Answer 1 · Thu Dec 17 2020 22:23:38 GMT+0800 (China Standard Time)

My main reservation is that this change it would no longer be obvious which version was present in systemtest-prereqs,

Mesbah Alam · Answer 2 · Thu Dec 17 2020 22:44:56 GMT+0800 (China Standard Time)

My main reservation is that this change it would no longer be obvious which version was present in systemtest-prereqs

Agreed. I expressed the same concern here: #97 (comment)

I guess we'd have to decide which con we all agree to accept:

Remove version number in asm jar - so that it's NOT obvious any longer in build output as to which version of ASM we are using (Note, this also is inconsistent with the rest of the prereq jars)
Keep the version number in ASM jar as is, and accept that we'd have to come up with 3 PRs every time we update ASM library.

@llxia @lumpfish

Simon Rushton · Answer 3 · Mon Dec 21 2020 18:56:01 GMT+0800 (China Standard Time)

Maybe create a metadata file in systemtest-prereqs next to the asm.jar file in the build after the download is successful (e.g. version-info.txt)? Perhaps the download URL would be sufficient (to identify the version)?

Mesbah Alam · Answer 4 · Wed Dec 23 2020 01:25:44 GMT+0800 (China Standard Time)

Can we simply have ASM version number defined as a property somewhere at the beginning of top.xml?
(We'd need it to build the download URL anyway).

Users interested in knowing the exact version of ASM can just look that up in top.xml. This sounds simpler than going into the systemtest_prereqs directory and looking for version-info.txt.

In either case, we'd have to update the documentation to tell users where to look for ASM jar's version number.

@lumpfish

Simon Rushton · Answer 5 · Wed Dec 23 2020 03:25:04 GMT+0800 (China Standard Time)

The version number will have to be in the build files somewhere anyway so the correct version is downloaded.

I was coming from the point of view of someone having run the build, looking at the systemtest-prereqs folder and seeing the asm folder with the asm.jar in it.
If there was a version-info.txt next to it you might infer that would tell you something about the version.
It might be a challenge to someone going through the build files looking for the version number they are not familiar with how the build works.

Anyway, it was only a suggestion.

Mesbah Alam · Answer 6 · Fri Jan 08 2021 05:28:44 GMT+0800 (China Standard Time)

We can add a version-info.txt under the asm folder, as suggested by @lumpfish above, and get rid of the version number from all the rest of the places.

@llxia - are you alright with this solution?

Just wanted to confirm with everyone before implementing this.

Lan Xia · Answer 7 · Fri Jan 08 2021 22:30:25 GMT+0800 (China Standard Time)

In the console output, there is info about the download URL and version. Do we really need extra version-info.txt file?

  [echo] Executing macro download-file
     [echo] File to download: https://repository.ow2.org/nexus/content/repositories/releases/org/ow2/asm/asm/9.0/asm-9.0.jar
     [echo] Destination: /home/jenkins/workspace/systemtest.getDependency/systemtest_prereqs/asm-9.0/asm-9.0.jar
     [echo] Download tool: wget
    [mkdir] Created dir: /home/jenkins/workspace/systemtest.getDependency/systemtest_prereqs/asm-9.0
     [exec] --2020-12-27 13:16:40--  https://repository.ow2.org/nexus/content/repositories/releases/org/ow2/asm/asm/9.0/asm-9.0.jar
     [exec] Resolving repository.ow2.org (repository.ow2.org)... 81.200.36.105
     [exec] Connecting to repository.ow2.org (repository.ow2.org)|81.200.36.105|:443... connected.
     [exec] HTTP request sent, awaiting response... 200 OK
     [exec] Length: 121783 (119K) [application/java-archive]
     [exec] Saving to: ‘/home/jenkins/workspace/systemtest.getDependency/systemtest_prereqs/asm-9.0/asm-9.0.jar’
     [exec] 
     [exec]      0K .......... .......... .......... .......... .......... 42%  233K 0s
     [exec]     50K .......... .......... .......... .......... .......... 84%  467K 0s
     [exec]    100K .......... ........                                   100%  172M=0.3s
     [exec] 
     [exec] 2020-12-27 13:16:41 (369 KB/s) - ‘/home/jenkins/workspace/systemtest.getDependency/systemtest_prereqs/asm-9.0/asm-9.0.jar’ saved

Mesbah Alam · Answer 8 · Sat Jan 09 2021 00:07:07 GMT+0800 (China Standard Time)

Quoting from Simon's comment above:

I was coming from the point of view of someone having run the build, looking at the systemtest-prereqs folder and seeing the asm folder with the asm.jar in it.
If there was a version-info.txt next to it you might infer that would tell you something about the version.

@lumpfish - can the user look up the ASM version in the build output, as Lan mentioned above?

As for me, I've only ever looked up ASM version when it has been time to upgrade the ASM library, e.g., to enable ASM dependent tests for new JDK versions. So, I am okay with having the ASM version only printed out in build output.

Lan Xia · Answer 9 · Sat Jan 09 2021 02:00:09 GMT+0800 (China Standard Time)

For the users who do not have access to the build output (very unlikely), they should be able to check top.xml for the version.

Simon Rushton · Answer 10 · Tue Jan 12 2021 17:38:59 GMT+0800 (China Standard Time)

My issue was not that the information about the asm version being used isn't available (you can see it in the build files which do the download as well as the build output), but I don't think that's necessarily the most obvious place to look. If you've run the build previously and have the systemtest-prereqs directory then the version of the dependent packages (junit_4.2 etc.) is obvious from the name. So one might expect the same for the asm version which after this proposed change would no longer be the case. Adding a metadata file inside the directory containing the jar would make it easy to find out which version from the location of the jar itself.
As @Mesbah-Alam says though - how many users (other than ourselves) have actually ever looked for or needed to care about the asm version - I don't know the answer to that, but obviously we've had cases where things don't work because the version needs to be changed.

Mesbah Alam · Answer 11 · Fri Jan 15 2021 02:58:58 GMT+0800 (China Standard Time)

After reading the discussion above, I feel there is more disadvantage in keeping the version number in the prereq jar name and its folder name; since updating a prereq jar (e.g. ASM) is something we do more often than looking for its current version number in file/folder name.

Here's what I propose :

Clean up version number from jar file name and folder name of all prereq jars with version numbers (e.g. ASM, log-4j, junit, ant and hamcrest).
List the version numbers clearly in top.xml as properties.
Update documentation so that users know where to check for version numbers of a particular prereq jar if needed.
Print out the version number of all prereqs in System test build output.

This way we can: (a) Update prereq libraries easily, (b) not have to hardcode prereq version numebrs in systemtest.getDependency script.

Mesbah Alam · Answer 12 · Sat Jan 16 2021 03:08:16 GMT+0800 (China Standard Time)

The following 4 PRs will remove version numbers from system test prereq jars:

#99 contains:
- The actual changes in top.xml where logic to download, expand and store prereq jars in systemtest_prereq location has been updated.
- Removal of version numbers from prereq jar references in STF repo.
adoptium/aqa-tests#2176 contains:
- Removal of version number from prerq jar references in getDependency script that's used by systemtest.getDependency Jenkins job instances.
adoptium/aqa-systemtest#392 contains:
- Removal of version number from prereq jar references in test projects in openjdk-systemtest repo.
adoptium/openj9-systemtest#123 contains:
- Removal of version number from prerq jar references in test projects in openj9-systemtest repo.

Testing on Jenkins:

A dummy.systemtest.getDependency job which points to adoptium/aqa-tests#2176 has been created in internal Jenkins (so that the original systemtest.getDependency job on which the live builds depend remains untouched).
A temporary change has been added to adoptium/aqa-tests#2176 to force the test grinder to pull the new prereq jars (that do not contain version numbers) from dummy.systemtest.getDependency (this change will be removed from the PR before final delivery of course).
A sanity.system Grinder build using the 4 PRs has been started (internal-Grinder/13187).

Testing locally:

Local testing is done by building system test and stf using the make layer and running test targets to ensure tests are all working normally with the changes.

Mesbah Alam · Answer 13 · Sat Jan 23 2021 09:03:12 GMT+0800 (China Standard Time)

The related PRs have been merged.