Build failures differ on appveyor and travis

[westonal]

Trying to get my locally working PR #34 to build on the build servers.

Travis says:

[WARNING] Unused declared dependencies found:
org.apache.commons:commons-lang3:jar:3.3.2:compile

While appveyor says:

Tests in error: 
  OverridingVersionTest.overridesVersionInEbt:76 � NullPointer

I've tried removing the POM entry for org.apache.commons:commons-lang3 but I get a different NPE test failure.

Tests in error: 
  EnvironmentTest.checksReadinessOfEnvironment:108 » NullPointer

Looks like a log4J thing, but I've not changed anything in that area and like I said, it all works locally. That sounds like "well it works on my machine" talk, but the very fact that two build systems can't agree on the failure points to something funny going on.

[westonal]

Note these commits are identical 08ebdd2 and e46f526 At first it failed, then I tried loads of stuff eventually ending full circle and it passed

[dmarkov]

@yegor256 please do something about this issue

[yegor256]

@westonized I do see a problem here, but you need to find one what exactly is it, in order to turn it into a real ticket. Now it looks more like "food for thought". check this: http:https://www.yegor256.com/2014/11/24/principles-of-bug-tracking.html

[westonal]

@yegor256 I have read that, I saw "Every bug has to be reproducible." that does ignore the fact that some bugs are intermittent, and reproduceability is not always possible.

I've given examples of identical code that has failed to build and not failed to build, differing exception messages, now surely it's down to the bug fixer to find out the cause?

[yegor256]

@westonized if that bug (even not always reproducible) would be in the master branch - yes, I would assign it to someone and then the job of that person would either be to fix it or prove that it doesn't exist (no money wasted in either case). In this case, you're talking about your own branch, which makes it even more "risky" for us. Maybe it's just a bug in your branch, introduced by yourself. In that case, we will simply waste time/money to prove you that there is a bug in your branch. See?

[westonal]

@yegor256 I accept that in general, yes. But in this case the build system has been show to give different results for the same source, so my code just cannot be to blame. We all rely on the build system to give accurate and consistent results, so it should be of general/great concern to the project that this could have happened.

Anyway, you just merged #31, so it is in master now.

[yegor256]

@westonized it's solved? please, close the issue than

[westonal]

@yegor256 No it's not solved. When you tried to merged #34 you saw rultor fail, then you tried again and it passed. My point was simply that is that this issue now is in master and though yet to be seen after the merge, I can't see any reason it would have gone away:

if that bug (even not always reproducible) would be in the master branch - yes, I would assign it to someone and then the job of that person would either be to fix it or prove that it doesn't exist (no money wasted in either case)

[yegor256]

@westonized make sense. can you please modify the description of this ticket and remove everything that is related to "your branch"?