Should we be reporting problems to the forum regarding build regressions with latest nightly releases?

(Doug Lethin) #1

A few days ago I picked up the latest milestone-7 nightly release to see if it resolved a bug I ran into (it did), but ended up regressing another part of my build which is working in milestone-6.

Just want to understand the protocol here – Should we be reporting to the forum regressions we run into with these nightly releases, or wait till there is a call for users to officially give their builds a try?

Also – Is there a particular recommended way perhaps using the gradle wrapper to automatically get the lastest available nightly release of Gradle? I’d like to throw that into a CI build to run nightly so that we can can proactively monitor our builds against the upcoming next milestone release?



PS – The regression I ran into occurs when running the compileTestJava task in my project where I use testng.

I get the following error:

FAILURE: Build failed with an exception.
  * What went wrong:
Could not resolve all dependencies for configuration ':GoPaymentServer:testCompile'.
Cause: Artifact 'org.testng:testng:6.1.1:jdk15@jar' not found
  * Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output.

No where in my dependency section do I have this particular dependency spec. Instead, I have:

testCompile "org.testng:testng:6.1.1"

I’m not sure where the jdk15 classifier is coming from? Perhaps there are some changes going on in milestone-7 for testng? Near as I can tell, testng 5.11 was the last version to use jdkXX classifiers.


If you’re on the dev list, that might be a better place to report regressions in the latest nightly. We definitely want to hear about problems you experience with these builds, but this information may not be all that useful published in the forum.

Regarding your particular problem: Milestone 7 will fail to resolve if a declared artifact is missing. The question is how that artifact is getting declared. I just tried a trivial build retrieving testng 6.1.1 and it works ok, so we need to know where in your build the classifier artifact is getting introduced. (Our TestNG support may be at fault here)

Any chance you can do a bit more investigation? We’ll be releasing Milestone 7 snapshot very soon, and the sooner we can iron out potential issues, the better.

(Doug Lethin) #3

OK, I’ll use the dev mailing list any issues I might run into with the daily nightly build.

In the meantime, I did as you suggest try to track down the problem a bit more. It seems not to be a problem per say with testng, but when using testng and the uncommons-reportng jar as outlined in the cookbook:

This dependency declaration fails for me (which did work through milestone 6)

testCompile "org.testng:testng:6.1.1"
  testCompile 'org.uncommons:reportng:1.1.2'
  * What went wrong:
Could not resolve all dependencies for configuration ':myproject:testCompile'.
Cause: Artifact 'org.testng:testng:6.1.1:jdk15@jar' not found

If I add an exclude like so, it works:

testCompile "org.testng:testng:6.1.1"
  testCompile('org.uncommons:reportng:1.1.2') {
      exclude group:"org.testng"

Seems something has been changed in milestone 7 related to conflict management that is causing this to break.

Adding the exclude works for both milestone 6 and 7, so I’ll leave that in and I’m good to go. Might just need to update the cookbook instructions.

Hope this information helps you. Thanks again.

(Adam Murdoch) #4

‘reportng’ declares a dependency on ‘testng’ with classifier ‘jdk15’. So, this has always been a problem. The only difference is that milestone 7 will now complain that the requested artifact does not exist, whereas earlier releases will silently ignore the problem.

A slightly better workaround in this instance would be to use a client module to override reportng’s dependencies:

testCompile "org.testng:testng:6.1.1"
testCompile module("org.uncommons:reportng:1.1.2") {
    dependency "org.testng:testng:6.1.1"