mvn test fails to start on HEAD

[gdgib]

If I checkout 192e21a9fcacf4dffc975156bcf5e8ff7bf297b1 (HEAD right now), and run mvn test I see a ClassNotFoundException. It cannot even report success or failure of individual tests.

I believe this is related to #388 which upgraded jgit, but maybe not all of the unit tests. Specifically LifecycleTest references UsernamePasswordCredentialsProvider which is no longer in the newer versions of jgit.

I'll be honest, as I tried to fix this I kept getting some unexpected classpath errors related to jgit (first this one, then one about GitAPIException, etc), and much as I know my way around a super complex build, I didn't feel like learning about the maven plugin for bridge method generation, and everything else it might take me to sort this out. Is there something basic I missed for setting up a working development environment for this project? I feel like I must have missed something simple for mvn test not to work.

The surefire log shows:

-------------------------------------------------------
 T E S T S
-------------------------------------------------------
org.apache.maven.surefire.util.SurefireReflectionException: java.lang.reflect.InvocationTargetException; nested exception is java.lang.reflect.InvocationTargetException: null
java.lang.reflect.InvocationTargetException
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:498)
        at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
        at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
        at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
        at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115)
        at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75)
Caused by: java.lang.NoClassDefFoundError: org/eclipse/jgit/transport/CredentialsProvider
        at java.lang.Class.getDeclaredMethods0(Native Method)
        at java.lang.Class.privateGetDeclaredMethods(Class.java:2701)
        at java.lang.Class.privateGetMethodRecursive(Class.java:3048)
        at java.lang.Class.getMethod0(Class.java:3018)
        at java.lang.Class.getMethod(Class.java:1784)
        at org.apache.maven.surefire.util.ReflectionUtils.tryGetMethod(ReflectionUtils.java:57)
        at org.apache.maven.surefire.common.junit3.JUnit3TestChecker.isSuiteOnly(JUnit3TestChecker.java:64)
        at org.apache.maven.surefire.common.junit3.JUnit3TestChecker.isValidJUnit3Test(JUnit3TestChecker.java:59)
        at org.apache.maven.surefire.common.junit3.JUnit3TestChecker.accept(JUnit3TestChecker.java:54)
        at org.apache.maven.surefire.common.junit4.JUnit4TestChecker.accept(JUnit4TestChecker.java:51)
        at org.apache.maven.surefire.util.DefaultScanResult.applyFilter(DefaultScanResult.java:97)
        at org.apache.maven.surefire.junit4.JUnit4Provider.scanClassPath(JUnit4Provider.java:194)
        at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:92)
        ... 9 more
Caused by: java.lang.ClassNotFoundException: org.eclipse.jgit.transport.CredentialsProvider
        at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
        at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
        ... 22 more

Results :

Tests run: 0, Failures: 0, Errors: 0, Skipped: 0

Maven version:

Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T08:41:47-08:00)
Maven home: C:\Program Files\Maven
Java version: 1.8.0_121, vendor: Oracle Corporation
Java home: C:\Program Files\Java\jdk1.8.0_121\jre
Default locale: en_US, platform encoding: Cp1252
OS name: "windows nt (unknown)", version: "10.0", arch: "amd64", family: "dos"

[kohsuke]

Not sure what's going on, but "mvn test" does work for me, so I'm inclined to believe there's some local maven repo corruption on your side, maybe Maven version problem on Windows, or something like that.

It's been a while since this error is reported. Is this still a problem?

[gdgib]

Which branch and tag works for you? What's your build environment?

Why would you think this is windows specific or related to maven repository corruption? Is there a history of such problems on this project?

[gdgib]

Just pulled from upstream and tried again. Still a problem. Almost exactly the same exception too.

I'm happy to debug, but is there any chance you could offer ANY insight into why I'd be getting a classpath exception in a maven project? That's usually sign of something unusual in code generation or non-compile scoped dependencies. Since there's a bridge method generator plugin I'm inclined to wonder if it's related.

[gdgib]

Perhaps you could share your own maven version for reference so I can try duplicating that?

[kohsuke]

I have no reasons to suspect this to be a Windows specific issue, and there's no history of such problems on this project. I guess I just wanted this problem to go away, and I'm sorry if that annoyed you.

It's just that the problem is really odd. The entire jgit is one jar AFAICT, so there cannot be a kind of version mismatch problem within different jars of the same library. The version of jgit used does contain org.eclipse.jgit.transport.CredentialsProvider, and in any case if the test code is really referencing a class that doesn't exist, it should fail to compile.

So the only thing I can think of is that somehow surefire is not setting up the classpath correctly, and that happens outside the code in this library.

My suggestion is to enable the debug switch on Maven to observe the classpath it's setting up, and to jar tf the jar file to make sure your local copy actually contains the class in question.

[gdgib]

Yeah... That's why I'm up to now...

[kohsuke]

By the way my environment:

% mvn --version
Apache Maven 3.5.4 (1edded0938998edf8bf061f1ceb3cfdeccf443fe; 2018-06-17T11:33:14-07:00)
Maven home: /usr/local/maven3
Java version: 1.8.0_144, vendor: Oracle Corporation, runtime: /usr/local/jdk1.8.0_144/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "4.4.0-130-generic", arch: "amd64", family: "unix"

[gdgib]

Sorry I got grumpy, 6mo was a long wait. I don't blame you for wanting it to go away! Me too!

Looks like your guess was good. Forcing a rebuild shows some weird warnings (why not errors, maven, seriously?) about stapler. I deleted that entry from the maven cache and things are at least running.

How in the HECK did you guess that? I've never seen a corrupt JAR in the maven cache before... Not that I fully understand their SHA1 sum mechanism, but apparently it aint good enough. That'll be a problem for another day.

I was on the wrong track completely with bridge methods. I tried getting Eclipse to help debug this a bit, but the m2e integration doesn't support that plugin. Red herring, my mistake.

For now, thank you so much sticking with me, and for the excellent guess. I'll wonder more about maven cache corruption in the future, with classpath errors.