Missing directory entries in testng jar #1677
Comments
|
I can see one opened issue #1640 which is related to jar. Maybe while fixing this we should consider that as well |
|
@dipak-pawar - There's a new version of TestNG that is scheduled for release. For now @cbeust has created a RC (Release candidate) for this and he will be publishing the actual version pretty soon. Its currently available here : http://jcenter.bintray.com/org/testng/testng/6.14.0-RC1/ I quickly ran a few checks that are mentioned in this bug and I seem to get through just fine. I guess your issue will get addressed when @cbeust releases Running the same project.
09:01 $ git diff pom.xml
diff --git a/pom.xml b/pom.xml
index 0a27422..dac6647 100644
--- a/pom.xml
+++ b/pom.xml
@@ -31,6 +31,17 @@
</dependencies>
<profiles>
+ <profile>
+ <id>testng-fixed</id>
+ <dependencies>
+ <dependency>
+ <groupId>org.testng</groupId>
+ <artifactId>testng</artifactId>
+ <version>6.14.0-RC1</version>
+ <scope>test</scope>
+ </dependency>
+ </dependencies>
+ </profile>
<profile>
<id>testng-patched</id>
<dependencies>
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Building testng-classloading 1.0.0-SNAPSHOT
[INFO] ------------------------------------------------------------------------
[INFO]
[INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ testng-classloading ---
[INFO] Deleting /Users/krmahadevan/temp/testng-classloading/target
[INFO]
[INFO] --- maven-resources-plugin:2.6:resources (default-resources) @ testng-classloading ---
[WARNING] Using platform encoding (UTF-8 actually) to copy filtered resources, i.e. build is platform dependent!
[INFO] skip non existing resourceDirectory /Users/krmahadevan/temp/testng-classloading/src/main/resources
[INFO]
[INFO] --- maven-compiler-plugin:3.1:compile (default-compile) @ testng-classloading ---
[INFO] No sources to compile
[INFO]
[INFO] --- maven-resources-plugin:2.6:testResources (default-testResources) @ testng-classloading ---
[WARNING] Using platform encoding (UTF-8 actually) to copy filtered resources, i.e. build is platform dependent!
[INFO] skip non existing resourceDirectory /Users/krmahadevan/temp/testng-classloading/src/test/resources
[INFO]
[INFO] --- maven-compiler-plugin:3.1:testCompile (default-testCompile) @ testng-classloading ---
[INFO] Changes detected - recompiling the module!
[WARNING] File encoding has not been set, using platform encoding UTF-8, i.e. build is platform dependent!
[INFO] Compiling 1 source file to /Users/krmahadevan/temp/testng-classloading/target/test-classes
[INFO]
[INFO] --- maven-surefire-plugin:2.20.1:test (default-test) @ testng-classloading ---
[INFO]
[INFO] -------------------------------------------------------
[INFO] T E S T S
[INFO] -------------------------------------------------------
[INFO] Running com.bartoszmajsak.groovy.ClassLoadingTest
[INFO] Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.044 s - in com.bartoszmajsak.groovy.ClassLoadingTest
[INFO]
[INFO] Results:
[INFO]
[INFO] Tests run: 2, Failures: 0, Errors: 0, Skipped: 0
[INFO]
[INFO]
[INFO] --- maven-jar-plugin:2.4:jar (default-jar) @ testng-classloading ---
[WARNING] JAR will be empty - no content was marked for inclusion!
[INFO] Building jar: /Users/krmahadevan/temp/testng-classloading/target/testng-classloading-1.0.0-SNAPSHOT.jar
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 2.962 s
[INFO] Finished at: 2018-01-31T09:10:51+05:30
[INFO] Final Memory: 17M/216M
[INFO] ------------------------------------------------------------------------Inspecting the jar contents. Here's the partial output 09:12 $ jar -tf testng-6.14.0-RC1.jar | head
META-INF/
META-INF/MANIFEST.MF
com/
com/beust/
com/beust/testng/
com/beust/testng/TestNG.class
org/
org/testng/
org/testng/annotations/
org/testng/annotations/AfterClass.classThe complete output is here |
|
I just now cross checked. TestNG 6.14 has been released and it fixes your problem. I am closing off this issue. While the artifact gets synced to maven central, please do the following to consume TestNG from JCenter
<repository>
<id>jcenter</id>
<name>jcenter</name>
<url>http://jcenter.bintray.com</url>
</repository>
<dependency>
<groupId>org.testng</groupId>
<artifactId>testng</artifactId>
<version>6.14.0</version>
<scope>test</scope>
</dependency> |
|
@cbeust , if 6.14 released, the git tag is missing. |
|
@krmahadevan Looks like TestNG [INFO] +- org.testng:testng:jar:6.14.0:compile
[INFO] | +- org.apache-extras.beanshell:bsh:jar:2.0b6:runtime
[INFO] | +- com.beust:jcommander:jar:1.66:runtime
[INFO] | \- org.apache.ant:ant:jar:1.9.7:runtime
[INFO] | \- org.apache.ant:ant-launcher:jar:1.9.7:runtimeThis causes again Arquillian integration to break with latest TestNG. Can you reopen this? |
|
Indeed :-( There's something wrong in |
|
This is now fixed in TestNG Here's the output |
|
@krmahadevan Looks like issue is still there. You can see output of I believe we have same issue with Can you reopen this issue @krmahadevan? |
|
@dipak-pawar - I dont understand what directory is missing ? Can you please help call out ? The most important directories are available in your gist post For issues with JCommander, I would request you to please log an issue here |
|
It is the entries for the directories that are missing for the JAR file, as listed in the "Expected behaviour". E.g., but it should give something like this instead: I confirm that this causes a problem with Arquillian. If you merely unzip the testng-6.14.2.jar file to extract its contents, then use zip to create a new JAR file with the same contents, that JAR file does contain the directory entries, and it does then work with Arquillian. |
|
@dipak-pawar @rwalkerands - I think this perhaps could be an issue with kobalt because that's the build tool that is involved here. So maybe we need to open up an additional issue there as well ? ping @cbeust Please let me know your thoughts on this. I am re-opening this issue, but there's nothing that needs to be done from the TestNG codebase itself. Its more of a fix that is needed in the build tool (kobalt in this case) |
I already reported it there for JCommander cbeust/jcommander#430 |
|
This should be fixed in TestNG 6.14.3 (JCenter only right now). Please confirm. |
|
@rwalkerands @dipak-pawar - Can you please confirm ? Here's what I see 08:38 $ unzip -l testng-6.14.3.jar | head -n20
Archive: testng-6.14.3.jar
Length Date Time Name
--------- ---------- ----- ----
0 02-23-2018 08:34 META-INF/
1333 02-23-2018 08:34 META-INF/MANIFEST.MF
0 02-23-2018 08:34 kobaltBuild/
0 02-23-2018 08:34 kobaltBuild/classes/
0 02-23-2018 08:34 kobaltBuild/classes/com/
0 02-23-2018 08:34 kobaltBuild/classes/com/beust/
0 02-23-2018 08:34 kobaltBuild/classes/com/beust/testng/
0 02-23-2018 08:34 com/
0 02-23-2018 08:34 com/beust/
0 02-23-2018 08:34 com/beust/testng/
288 02-23-2018 08:34 com/beust/testng/TestNG.class
0 02-23-2018 08:34 kobaltBuild/classes/META-INF/
0 02-23-2018 08:34 kobaltBuild/classes/META-INF/services/
0 02-23-2018 08:34 META-INF/services/
30 02-23-2018 08:34 META-INF/services/org.testng.xml.ISuiteParser
0 02-23-2018 08:34 kobaltBuild/classes/org/
0 02-23-2018 08:34 kobaltBuild/classes/org/testng/The full output is available below |
|
@krmahadevan , @cbeust This issue is not fixed. Looks like released version of TestNG [INFO] \- org.testng:testng:jar:6.14.3:test
[INFO] +- com.beust:jcommander:jar:1.72:test
[INFO] \- org.apache-extras.beanshell:bsh:jar:2.0b6:testBut cbeust/jcommander#430 is fixed in jcommander Steps To Reproduce
Result
|
|
@dipak-pawar - Can you not just update your pom file to add an exclusion of the older jcommander version from testng dependency and explicitly depend on the newer version to get past this ? Just trying to understand as to why do you expect TestNG to include the latest JCommander version ? |
|
@krmahadevan , I have updated code in https://github.com/dipak-pawar/testng-classloading. |
|
@dipak-pawar - It works for me. I dont see any failures. Here's the output |
|
@krmahadevan , Is it working for |
|
You need to fix your pom file to get this to work when you run |
|
@krmahadevan Looks like there is some misunderstanding.
<dependencies>
<dependency>
<groupId>org.testng</groupId>
<artifactId>testng</artifactId>
<version>6.14.3</version>
<scope>test</scope>
<exclusions>
<exclusion>
<groupId>com.beust</groupId>
<artifactId>jcommander</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>com.beust</groupId>
<artifactId>jcommander</artifactId>
<version>1.73</version>
</dependency>
</dependencies>So this should pass ideally. It's passing. So Ideally if you release testng with jcommander |
|
So Ideally if you release testng with jcommander 1.73. user don't have to
exclude it from testng and add it as extra dependency.
TestNG may or maynot move over to using JCommander 1.73 at all because :
1. TestNG doesnt have a new requirement that JCommander 1.73 is solving
2. TestNG functionality per se is not impacted by NOT using JCommander
1.73
Its like the case with any other library out on the internet. Libraries use
what versions work for them. If there's a bug that got fixed in the newer
version of that dependency, then you as a consumer should still be able to
add appropriate exclusions and then move forward.
I am basically saying that as of now, your issue has been resolved by
having Kobalt (build tool used by both JCommander and TestNG) fixed and new
versions released using the updated Kobalt version. So you should still be
able to move forward by applying exclusions no ?
I am not sure I quite understand why wont applying exclusions work for you
? Am I missing something here ? Please let me know.
@cbeust @juherr please correct me if I am wrong here.
|
|
I think we should upgrade our dependencies when they fix known issues. |
|
@krmahadevan, @cbeust We are using So as per above workaround, every user has to explicitly remove jcommander from his testng and use another version of jcommander(> 1.73 as 1.73 has cbeust/jcommander#434), which is not good user experience in my opinion. <dependencies>
<dependency>
<groupId>com.beust</groupId>
<artifactId>jcommander</artifactId>
<version>latest</version> <!-- greater than 1.73 -->
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.testng</groupId>
<artifactId>testng</artifactId>
<version>6.14.3</version>
<scope>test</scope>
<exclusions>
<exclusion>
<groupId>com.beust</groupId>
<artifactId>jcommander</artifactId>
</exclusion>
</exclusions>
</dependency>
</dependencies>It'll be really appreciated if you can release testng with new version of jcommander having cbeust/jcommander#434 fixed in coming days. |
|
I confirmed that testng-6.14.3.jar works (with Arquillian 1.1.15). (I do my own, manual dependencies, which in this case means I'm using an older jcommander JAR that was not affected.) Looking forward to an update to the Eclipse plugin so that I can switch over all together ... |
|
ping @missedone for the Eclipse plug-in. |
|
@rwalkerands , you can go direct to "Help -> Check for Updates...", there will be a update for 'testng-p2' 6.14.3. Note: testng-p2 is the osgified testng. |
|
How can i get TestNG jar absolute path when TestNG is used in test case ? Anyone can tell me ? Thanks a lot. |
|
@SomberOfShadow - Check if this helps URL loc = TestNG.class.getProtectionDomain().getCodeSource().getLocation();
File file = new File(loc.toURI()); |
|
@SomberOfShadow You can easily get using Look for sample example here |
I will have a try . Thanks a lot. |
Ok , thanks , i will try. And maybe i need to state my question again. My question is that there are several testNG versions in project, but which version is really used in test case and how to get the really used testNG version. Am i clear ? I will appreciate it if you can give me help. |
|
@SomberOfShadow - The code snippet I shared will automatically ensure that the version of TestNG that is being resolved to is what will be used to obtain the path. |
I dont know why, i use the code snippet in transform (), but NullPointerException occured. |
hi， I have had a try. but the result is not my expected. Anyway, thanks a lot. |
Maybe I made something wrong, and I will have another try. Thanks you very much. |
hi, thank you very much . It works. But now i have another question. I will very appreciate it if you can give me help. Case One: In TestNG.jar (such as testng-6.14.12.jar) , there is a MATA-INF/MANIFEST.MF file , we can get Bundle-Version from MANIFEST.MF to get TestNG version. Case Two: Assume there are two Maven projects, named A and B. In A project , there is no TestNG dependency, but in B project, TestNG dependency is included. Now , B.jar is included in A project. We still want to get TestNG version in A, but we can not find MANIFEST.MF about TestNG.jar in B.jar, so we can we do to get TestNG version in this case ? Looking forward to your reply. Best Regards /// |
|
Fyi, maybe you can use |
Thanks you a lot. It works . And the code snippet is different from Version.VERSION. If using Version.VERSION to get TestNG version, the result may be not the correct version used in test cases in run time. |
TestNG Version
Description:
jar -tf testng-6.13.1.jarExpected behavior
Actual behavior
Test case sample
The text was updated successfully, but these errors were encountered: