The TestNG version is "[WORKING]" when we add TestNG into our shaded package.

[bobshie]

TestNG Version

Note: only the latest version is supported 7.5.x/7.6.x

Expected behavior

org.testng.internal.Version.VERSION should be correct

Actual behavior

org.testng.internal.Version.VERSION = "[WORKING]"

Is the issue reproducible on runner?

• [ ] Shell
• [x] Maven
• [ ] Gradle
• [ ] Ant
• [ ] Eclipse
• [ ] IntelliJ
• [ ] NetBeans

Test case sample

Please, share the test case (as small as possible) which shows the issue NO

Contribution guidelines

NO

in org.testng.internal.Version

private static String initVersion() {
    String version = Version.class.getPackage().getImplementationVersion();
}

when we use shaded package, there is no TestNG version in META-INF\MANIFEST.MF.

[bobshie]

There will be the other error when we use Eclipse TestNG plugin:

[failed to get TestNG version from class java.lang.IllegalArgumentException: invalid version "[WORKING": no-numeric "[WORKING]"

source code: https://github.com/testng-team/testng-remote/blob/master/remote/src/main/java/org/testng/remote/RemoteTestNG.java

[bobshie]

Can Gradle generate the pom.properties with TestNG class?

version=${testng.version} groupId=org.testng artifactId=testng

[juherr]

I think you'll have the same issue if you try to shade Hibernate: https://github.com/hibernate/hibernate-orm/blob/main/hibernate-core/src/main/java/org/hibernate/Version.java

Maybe you should not shade TestNG.

[bobshie]

Hello, we don't use hibernate and TestNG version is very important for our test framework and we use all-in-one shaded jar file in our CI flow for a long time. we can't change the way to run test cases.

[krmahadevan]

@bobshie -

Am guessing that you folks rely on this version class for some such purpose within your tests (perhaps log this data somewhere or capture it in the test reports maybe? )

If the TestNG jar is being shaded by a build pipeline, why not just have your own mechanism that would embed the TestNG version into a customised way for your project which can be retrieved by you?

For e.g., since you are shading the TestNG jar, a person would have to update the version in the build file (gradle/maven) and so they can also update a text file with the TestNG version which you can later use to retrieve the value.

The only reason why that version class exists within TestNG is to help us extract out the TestNG version information from our users when they share the logs. Beyond that there's no other use that I know of.

[bobshie]

hi @krmahadevan,

[failed to get TestNG version from class java.lang.IllegalArgumentException: invalid version "[WORKING": no-numeric "[WORKING]" is the log from RemoteTestNG plugin.

We work on a test framework(test-based.jar) that used in the other team, we provide a jar for them, and they can use it. but they also can use the other TestNG jar file if they want (it's not suggestion,but they still use it for the other reason), so we need to print version in log (as you said). the other thing, the RemoteTestNG plugin(for eclispe) depend on TestNG version to check the different interface.

  jar -cp test-based.jar:test-case.jar 

few testers using

 jar -cp TestNG.jar:test-based.jar:test-case.jar

Now we add add a pom.properties for testng, it can resolve most of the problem but not all.

[krmahadevan]

@bobshie - Can you please use the ManifestResourceTransformer to add the TestNG version by adding

Specification-Version: 7.6.1
Implementation-Version: 7.6.1

and see if that helps.

[bobshie]

hello @krmahadevan , I tried the solution before. the TestNG version will be in MANIFEST.inf, but it without testng package in the file. so the version of whole jar will be replaced.

the version of testbase jar

    Implementation-Version: 1.0.2310

I didn't find a way to add such information in Manifest.inf:

     Name: org/testng/testng
     Implementation-Version: 7.6.1

[krmahadevan]

@bobshie - Can you please help share a dummy project (which internally shades TestNG) so that I can try out something and share if I find something useful ?

[krmahadevan]

@bobshie

Alternatively I would suggest that you try the following

Create a class called Version.java under the package org.testng.internal

and modify its getVersionString() implementation to maybe return back and hard coded value, which later gets shaded into your uber jar and see if that helps ?

package org.testng.internal;

public final class Version {

  public static String getVersionString() {
    return "7.6.1";
  }

  public static void displayBanner() {
    System.out.println(
        "...\n... TestNG " + getVersionString() + " by Cédric Beust ([email protected])\n...\n");
  }
}

[bobshie]

hi @krmahadevan , Before we make patch file (org.testng.internal.Version.java) in our project. it works. but it's not accepted by the other Guardians of our project. so we now using the plugin to generate pom.properties

          <plugin>
            <!-- Generate a TestNG maven propertiesfile.java -->
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-antrun-plugin</artifactId>
            <version>${maven.antrun.plugin}</version>
            <executions>
                <execution>
                    <goals>
                        <goal>run</goal>
                    </goals>
                    <phase>generate-sources</phase>
                    <configuration>
                        <target>
                            <property name="whitespace" value=" " />
                            <property name="src.dir" value="${basedir}/target/generated-sources/properties" />
                            <property name="package.dir" value="META-INF/maven/org.testng/testng" />
                            <property name="buildtime" value="${maven.build.timestamp}" />
                            <property name="propertiesfile" value="${src.dir}/${package.dir}/pom.properties" />
                            <echo message="BUILDING : ${propertiesfile}" />
                            <echo file="${propertiesfile}" message="#Created automatically&#10;version=${testng.version}&#10;groupId=org.testng&#10;artifactId=testng" />
                            <echo message="BUILD ${buildtime} : ${propertiesfile}" />
                        </target>
                    </configuration>
                </execution>
            </executions>
        </plugin>

[krmahadevan]

@bobshie - In that case, can we close this issue? I dont think TestNG is going to deviate from the current mechanism in terms of embedding its version details in a simple way (Open to any suggestions though) by piggy backing on the manifest details.

[juherr]

I think we can close the issue because won't support the shaded usecase.

[bobshie]

testng-test.zip This is the example test cases. test-case project is based on test-base project which based on TestNG.

[bobshie]

hello @krmahadevan, I think you can close the ticket if you don't want to support such shaded user case. we will still use the workaround solution in our project.