[2.3-rc-1] Regression: NPE in uploadArchives

uploadArchives of one of our modules fails with this NPE: http://pastebin.com/SBk65Zfp

Unfortunately, I wasn’t able to pinpoint the problem, i.e. most other modules upload without problem and I failed to find the crucial difference or what’s so special about that failing module.

Please let me know if I can help locating the problem in any way. Or if you find out what’s causing this, please let me know for my personal peace of mind.

Hey, thanks for reporting this issue. From a first quick glance it is not clear where this nullpointer comes from. A couple of questions:

  • is this a deterministic reproducable issue?

  • how do how do invoke gradle (with parallel enabled?)

    • do you use dynamic versions (1.2.+, +, …)

    • is there something special in the dependencies of foo or the version of foo itself compared to other subprojects in your build?

cheers, René

  • yes, this happens always and always in the same module - happens with both parallel enabled and disabled (enabled on my machine, disabled on the build server) - no dynamic versions - I searched very hard for any possible reason but failed. There were some strange dependencies but removing them did not fix the problem, even after a clean rebuild.

The dependencies I suspected were “com.trilead:trilead-ssh2:build213-svnkit-1.3-patch” (strange version “number”) and “radeox:radeox-oro:0.9” (strange pom).

‘foo/build/poms/pom-default.xml’ has a size of zero bytes - but I don’t know why and I don’t know if this is the reason for the NPE or caused by it.

I think the zero byte pom-default.xml is a result of the nullpointer you see in the stacktrace. I added dependencies to “radeox:radeox-oro:0.9” and "“com.trilead:trilead-ssh2:build213-svnkit-1.3-patch” in my test project, but that doesn’t cause uploadArchives to fail.

still trying to reproduce this issue with no luck atm.
- what OS are you using?
- what jdk are you using?
- does this foo build also fail as a single project?
- do you have project dependencies in foo?

I know… Removing them didn’t fix the issue. What could cause this in DefaultVersionSelectorScheme:21? I could provide you with a ‘dependencies’ output via mail (to keep the data private) but I didn’t see anything suspicious regarding versions beyond the ones mentioned above.

the only way to force a nullpointer here imo is to inject a null value as selector string. but even then the nullpointer is thrown in the Pattern class and not this line. my email is rene.groeschke@gradleware.com

  • upload fails on OS X (my machine) and Linux (build server). - if I only try to ‘uploadArchives’ for ‘foo’ instead of the whole multi-module project? Yes, same error. - yes, there are internal project dependencies referencing other modules of the same build. But they all have a defined ‘group’ and ‘version’.

this issue can be tracked in our issue tracker at https://issues.gradle.org/browse/GRADLE-3233

cheers and again many many thanks for helping us figuring out the root cause here!

cheers, René