Home Original page

Initial version of Spotless Maven plugin by lutovich · Pull Request #188 · diffplug/spotless

@lutovich 

Commit introduces a prototype of the Maven plugin which is able to
apply Eclipse formatter step to all java files in the project. It
only takes a single parameter - 'eclipseFormatFile' which is a path
to the formatter configuration.

Maven plugin is build and packaged using Maven which is executed from
the Gradle build script via Exec plugin. This seems to be the simplest
way to get a JAR with "maven-plugin" packaging. Gradle does not have
a native plugin to do this.

This change just adds a bare minimum to verify the approach.

@nedtwigg

@lutovich 

Exposed `encoding` and `lineEndings` in the plugin xml configuration.
Renamed `eclipseFormatFile` to `eclipseConfigFile` and moved it inside
the `<java>` tag. Maven plugins can handle nested configs using Plexus
dependency injection and POJO objects. Thus introduced a dedicated
class for all java related configuration called `Java`.

Plugin xml configuration can now look like:

```
<plugin>
  <groupId>com.diffplug.spotless</groupId>
  <artifactId>spotless-maven-plugin</artifactId>
  <version>${spotless.version}</version>
  <configuration>
    <encoding>UTF-8</encoding>
    <lineEndings>UNIX</lineEndings>
    <java>
      <eclipseConfigFile>${basedir}/eclipse-fmt.xml</eclipseConfigFile>
    </java>
  </configuration>
</plugin>
```

Extracted an abstract `AbstractSpotlessMojo` to hold all injected
dependencies. It can be potentially used in future to implement
the `check` goal.

Changed name of `SpotlessMojo` from "spotless" to "apply" so that
it can be invoked with `mvn spotless:apply`.
Injected `MavenProject` is now replaced by injection of multiple
primitive values, like `project.basedir`.
Removed shading & local repository for `lib` and `lib-extra`. Instead
made plugin directly depend on stable version denoted
by `project.stableLib`.

Made all maven plugin API dependencies provided and their versions
injected by the Gradle build script.

@lutovich 

These don't match the current implementation exactly, but
I think they're close.  I don't know much about maven, lets
get the docs right, and then build to the docs.

@nedtwigg

@nedtwigg

@nedtwigg

@nedtwigg 

Gradle build script will now use Mustache template to create pom.xml
with needed versions. This should be more reliable and future-proof
than previously used `String#replace()`.

@lutovich 

Restructured code to better support addition of new formatter steps and
formatters. Spotless mojo now accepts java configuration with list of
steps. It is also possible to specify global encoding, line endings
and override them for java.

New `pom.xml` config looks like:

```
<configuration>
  <encoding>UTF-8</encoding>
  <lineEndings>UNIX</lineEndings>

  <java>
    <encoding>US-ASCII</encoding>
    <lineEndings>WINDOWS</lineEndings>
    <steps>
      <eclipse>
        <file>${basedir}/build/eclipse-format.xml</file>
        <version>4.7.1</version>
      </eclipse>
    </steps>
  </java>
</configuration>
```
…older location as 'plugin-maven'.

@nedtwigg

@nedtwigg

@nedtwigg

jbduncan

jbduncan

@lutovich 

It is not needed because maven plugin and tests specify custom
local repository via `-Dmaven.repo.local` system property.

@lutovich 

….spotless group before caching.

@nedtwigg

@nedtwigg 

…r maven-install-plugin and the wrapper.

@nedtwigg

@nedtwigg 

This commit makes it possible to configure includes and excludes for
paths/files with Ant style pattern in configuration groups (currently
Java and Scala). It also changes the default source roots for scanning.

Default policy for scanning used to recursively start from the `basedir`
and include files with needed extensions, like "*.java" or "*.scala".
This worked fine for simple maven projects but resulted in a lot of
extra work for multi-module maven projects. Same files had to be
scanned more than once during parent and then child module scanning.
Now scanning will use most common source roots for supported languages.
They are "scr/main/java/**/*.java", "scr/test/java/**/*.java" for Java
and "scr/main/scala/**/*.scala", "scr/main/scala/**/*.sc",
"scr/test/scala/**/*.scala", "scr/test/scala/**/*.sc" for Scala. So
only these common source roots will be scanned by default.

Mentioned patters form default includes. Default excludes are empty,
except output directory (usually "target"), temporary files and VCS
files are always skipped. It is possible to override includes and add
excludes. This can be done like this:

```
<java>
  <includes>
    <!-- include all java files in "java" folders under "src" -->
    <include>src/**/java/**/*.java</include>

    <!-- include all java files in "java" folders under "other" -->
    <include>other/java/**/*.java</include>
  </includes>

  <excludes>
    <!-- exclude examples from formatting -->
    <exclude>src/test/java/**/*Example.java</exclude>
  </excludes>
</java>
```

Similar configuration is possible for Scala. Custom includes completely
override default includes. Default excludes of output directory,
temporary and VCS files can't be overridden.

@lutovich

@lutovich 

Generic formatting steps, like LicenseHeader can be defined both
globally and inside language configs. Example:

```
<configuration>
<!-- global license header config -->
<licenseHeader>...</licenseHeader>

<java>
  <!-- overridden license header for java -->
  <licenseHeader>...</licenseHeader>
</java>
</configuration>
```

Previously global config had no effect. This commit fixes the problem
by passing globally configured generic steps down to `FormatterFactory`
which creates steps and uses globally configured ones, unless
overridden.

@lutovich 

License header is a generic step that is applicable to both `Java` and
`Scala`. This commit moves adder for it to `FormatterFactory`, which
is super class of both `Java` and `Scala`. Code duplication is thus a
bit reduced.