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

Old Forum Archive
1

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.

2

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é

3
  • 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.

4

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.

5

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?

6

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.

7

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. 

8
  • 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’.
9

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é