Maven plugin incompatible with 3.3.9

[phillipuniverse]

Summary of problem

Using the Spotless plugin in a Maven project and applying with Maven 3.3.9 throws an exception when I mvn spotless:check.

It looks like this is only in 1.21.1, this was fine in 1.20.0.

• Gradle or maven version - Maven 3.3.9
• spotless version - 1.21.1
• operating system and version - Macos 10.14.3
• copy-paste your full Spotless configuration block(s), and a link to a public git repo that reproduces the problem if possible

<plugin>
    <groupId>com.diffplug.spotless</groupId>
    <artifactId>spotless-maven-plugin</artifactId>
    <version>1.21.1</version>
    <executions>
        <execution>
            <id>check</id>
            <goals>
                <goal>check</goal>
            </goals>
        </execution>
    </executions>
    <configuration>
        <java>
            <eclipse>
                <version>4.10.0</version>
                <file>path/to/eclipse-formatter.xml</file>
            </eclipse>
            <importOrder>
                <file>path/to/java.importorder</file>
            </importOrder>
            <removeUnusedImports />
        </java>
        <formats>
            <format>
                <!-- XML files -->
                <includes>
                    <include>src/main/**/*.xml</include>
                    <include>**/pom.xml</include>
                </includes>
                <excludes>
                    <exclude>src/main/resources/rebel-remote.xml</exclude>
                    <exclude>src/main/resources/rebel.xml</exclude>
                    <exclude>**/target/**/pom.xml</exclude>
                </excludes>
                <indent>
                    <spaces>true</spaces>
                    <spacesPerTab>4</spacesPerTab>
                </indent>
                <trimTrailingWhitespace />
            </format>
            <format>
                <includes>
                    <!-- YAML -->
                    <include>src/main/**/*.yml</include>
                    <include>src/main/**/*.yaml</include>
                    <!-- JS within Java projects -->
                    <include>src/main/**/*.js</include>
                    <!-- SQL imports -->
                    <include>src/main/**/*.sql</include>
                </includes>
                <indent>
                    <spaces>true</spaces>
                    <spacesPerTab>2</spacesPerTab>
                </indent>
                <trimTrailingWhitespace />
            </format>
        </formats>
    </configuration>
</plugin>

• copy-paste the full content of any console errors emitted by gradlew spotless[Apply/Check] --stacktrace

https://gist.github.com/phillipuniverse/db14a796ffb4e8392da89c790537fd02

[phillipuniverse]

Some preliminary research led me to jeremylong/DependencyCheck#1054.

The only thing that seems suspect from the stack trace is maybe the SLF4j support? The comparison between versions is pretty light, not a ton of things that could have caused the regression.

[phillipuniverse]

Also worth noting that I updated to Maven 3.6 and it was no longer an issue.

[fvgh]

Sorry, I am afraid that was my mistake. When I did a research for #342, I focused on Gradle and saw that Maven also provides a SLF4J support for plugins. I assumed, but did not check, that like for Gradle, Maven uses SLF4J it since ages. Now I see that Maven actually introduced it with Maven 3.5.0 (released 2017-04-07). The previous Maven release version was 3.3.9 (released 2015-11-14) hadn't had it in.

@phillipuniverse Can you live with the newer version of Maven?
@nedtwigg For build tools that do not support SLF4J, I foresaw that the Spotless plugin provides SLF4J. We could provide the maven-plugin with a SLF4J SimpleLogger implementation and dependent on the Maven version, just log to standard out/err. Its a little bit ugly.

[nedtwigg]

Its a little bit ugly.

But only for maven versions older than 3.5.0, correct? I think that's okay. Especially if the first thing we log is something like

spotless eclipse-based formatters log to stdout for old versions of maven. Upgrade to Maven 3.5.0 or newer for standard SLF4J log integration

And in the meantime, our compat ranges are:

• we have always required Maven >= 3.1.0
• we require Maven >= 3.5.0 starting with plugin 1.21.0

I think it's reasonable to just require 3.5.0: #259

But best of all would be to degrade to stdout logging, if that's not too difficult.

[fvgh]

Something puzzles me. The documentation states that we support Maven 3.1.0. But it seems that the testing is only using 3.5.2. Am I missing something?

[nedtwigg]

@lutovich might be able to correct me, but it might be as simple as 3.5.2 was the version that he or I were using when we set up mvnw. But it should be 3.1.0 since we claim to support it.

[fvgh]

I have to have another look at Maven.
The logging description clearly states that SLF4J is supported with 3.1.x. My assumption about 3.5 was just based on quick scan of Maven release notes...

But I think we should start by correcting the Maven version in the tests and find a test case to reproduce the problem.

[phillipuniverse]

@phillipuniverse Can you live with the newer version of Maven?

Livable, but not great because it was a surprise (which I'm sure is something we all agree on). We had some other developers using the older version of Maven.

IIRC, Maven 3.3 was the last LTS (somewhat assuming from the bolded versions at https://maven.apache.org/docs/history.html), it would probably be better to have compatibility with at least that. Unfortunate that true SLF4j support wasn't added until 3.5.

[fvgh]

I am affraid my previous comments contain a mistake:
Spotless Eclipse-JDT was the only plugin where I had not introduced the SLF4 logger (yet).

I was not able to reproduce the problem using Maven 3.1.0 and Maven 3.6.0 with Spotless Eclipse-JDT (similar to the configuration provided by @phillipuniverse above) nor with Spotless Eclipse-WTP (which uses SLF4 logger).

It seems that the problem can occur due to dependency mediation in combination with other plugins.
The spotless-maven-plugin has some flaws in its dependencies addressed by #397.

@phillipuniverse Could you provide a list of all plugins and versions you used, or a stripped down version of your POM, to help me reproducing the issue and see whether #397 solves it?

[nedtwigg]

Bump @phillipuniverse:

Could you provide a list of all plugins and versions you used, or a stripped down version of your POM, to help me reproducing the issue and see whether #397 solves it?

[phillipuniverse]

Sorry for the late reply here, this fell off my radar.

Well now I don't know what to think. I switched back over to Maven 3.3.9, ran a mvn spotless:check and it worked just fine. I had already updated to 1.23.0, so I even tried going back to 1.21.1 and now even that succeeds.

[phillipuniverse]

Ok wow so this one was a doozy. Did more due diligence and it turns out this is uniquely because of the presence of the Dockerfile Maven plugin.

I added a reproduction case with instructions at https://github.com/phillipuniverse/spotless-bug-example.

[fvgh]

@phillipuniverse Thanks for providing the example. Right at the moment I have no time for a further investigation. But I your example should give me sufficient input whether we should improve our Maven dependencies.

[fvgh]

As I see it, the problem was never SLF4J / spotless-eclipse-base related.
Spotless mixes provided and own Aether versions. With mvn 3.3.9, I could not reproduce the error, but with 3.1.0, I get:

SEVERE: Step 'eclipse jdt formatter' found problem in 'src/test/java/com/example/demo/DemoApplicationTests.java':
'org.eclipse.aether.collection.VersionFilter org.eclipse.aether.RepositorySystemSession.getVersionFilter()'
java.lang.NoSuchMethodError: 'org.eclipse.aether.collection.VersionFilter org.eclipse.aether.RepositorySystemSession.getVersionFilter()'
	at org.eclipse.aether.internal.impl.DefaultDependencyCollector.collectDependencies(DefaultDependencyCollector.java:155)
	at org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveDependencies(DefaultRepositorySystem.java:341)
	at com.diffplug.spotless.maven.ArtifactResolver.resolveDependencies(ArtifactResolver.java:86)

Debugging the Maven process showed that actually the Aether version 1.1.0 (API + Impl) was used. Maven 3.1.0 requires 0.9.0.M2.
The only plugin with a runtime dependency to Aether, is

[INFO]    org.springframework.boot:spring-boot-maven-plugin:maven-plugin:1.5.21.RELEASE:runtime
...
[INFO]       org.eclipse.aether:aether-spi:jar:1.0.2.v20150114
[INFO]       org.eclipse.aether:aether-impl:jar:1.0.2.v20150114
[INFO]       org.eclipse.aether:aether-api:jar:1.0.2.v20150114
[INFO]       org.eclipse.aether:aether-util:jar:1.0.2.v20150114
...

The involved versions look like failed dependency mediation. So latest-greatest of Aether is used. But of course Maven class loader would prevent such a thing, and only Spotless seems to be affected.

I think the problem is here:

[INFO]    com.diffplug.spotless:spotless-maven-plugin:maven-plugin:2.17.3-SNAPSHOT:runtime
...
[INFO]       classworlds:classworlds:jar:1.1-alpha-2
...

We take an own version of the Maven Boot classloader on board. This does not feel right. First tests excluding the dependency from org.codehaus.plexus:plexus-resources seem to fix the issue.

I think the usage of the own boot class loader classes causes some hick-ups with the dependency separation for each plugin. That`s why the problem always occurred somewhere else, depending on the plugins used and the order their dependencies have been analyzed.

[fvgh]

Exclusion of classworlds:classworlds did not fix the problem. Using the latest org.codehaus.plexus:plexus-resources version 1.2.0 (which does not depend on classworlds), did not fix the problem.

The problem is not deterministic. But it has been found with the latest version, that it only occurred with the install goal, but not when calling the spotless plugin goals directly. Hence it seems unlikely that the problem is caused by spotless. It is assumed that Maven 3.1.0 has a bug.

Original problem with Maven 3.3.9 was not reproducible with reasonable effort.