This plugin enables you to publish "clean" POM files after interpolating values for the Scala version and Scala binary version.

A common way to vary Scala binary versions is to use Maven profiles, declaring one profile for each binary version you want to cross compile to. Then you run Maven once for each binary version, activating the appropriate profile, to build and deploy artifacts.

However, the published POMs end up not working so well:

• Maven doesn't like it when you use variable substitution in artifact IDs (and will warn you of this on startup).
• The published POMs will require consumers to know about (and duplicate) the use of your profile IDs in order to interpolate the correct variables.
• Many developers set one of the Scala-version profiles to be activated by default, which:
  • can cause confusing (silent) failures if a new developer runs Maven without explicitly specifying the desired profile.
  • can cause confusing issues if the set of property names in each Scala-version profile is not exactly the same.
• If one of the Scala-version profiles is not set as activated by default, often default values for the Scala version and binary/compat version are specified outside the profile, which can cause similar problems to those outlined in the previous point.

• There's a fine discussion of the perils of using Maven for Scala builds by Ryan Williams of Hammer Lab.
• The flatten-maven-plugin almost does what we want, but is difficult to configure so that it makes the fewest modifications necessary to the POM file.

To make this work, ideally your POM and build should conform to a convention like so:

• You have a separate profile for each Scala binary/compat version, named like scala-2.11, scala-2.12, etc.
• None of these scala-* profiles are active by default.
• You use properties named scala.version and scala.binary.version (or scala.compat.version) to determine which Scala versions to use.
• You have artifact (and possibly group) IDs that require the binary/compat version to be interpolated into them.
• You do not put defaults for the above properties in the POM's main properties section. (Note: Some IDEs, like IntelliJ IDEA, won't work properly without a default for scala.binary.version, even if you properly select the correct profile to use. Adding a default for that property seems to work ok.)

If you've fulfilled the above, you can just do the following:

<build>
  <plugins>
    ..
    <plugin>
      <groupId>org.spurint.maven.plugins</groupId>
      <artifactId>scala-cross-maven-plugin</artifactId>
      <version>{see tags for latest version}</version>
      <executions>
          <execution>
              <id>rewrite-pom</id>
              <goals>
                  <goal>rewrite-pom</goal>
              </goals>
          </execution>
      </executions>
    </plugin>
    ..
  </plugins>
</build>

When you run your build, pass -Pscala-2.12 (or whichever profile you want) to Maven, and things will just work.

In reality, the plugin will take any properties defined in your Scala-version profile and interpolate them into group and artifact IDs in the rest of the POM.

For reference, here's an example of some profiles you might use:

<profiles>
  <profile>
    <id>scala-2.11</id>
    <properties>
      <scala.binary.version>2.11</scala.binary.version>
      <scala.version>2.11.12</scala.version>
    </properties>
  </profile>
  <profile>
    <id>scala-2.12</id>
    <properties>
      <scala.binary.version>2.12</scala.binary.version>
      <scala.version>2.12.10</scala.version>
    </properties>
  </profile>
</profiles>

There are a few settings you can use to tailor execution to your environment.