Compilers other than Java execute too late

[briantopping]

Greetings, thanks for an excellent plugin.

When compilers other than Java are added to a build, they fire after javah and there doesn't seem to be any way to get around this. Research I've done into mojo ordering seems to indicate that the plugins are executed in the order they are in the effective POM, with the exception of the packaging plugin, which always runs first. The net effect in this case is there's no way to run the Scala plugin before javah.

I've attached a sample POM that will demonstrate this behavior. It can be run without source files, just note the order of the plugin execution. scala-maven-plugin runs after nar-compile, which is too late.

My initial thought was to move some stuff into the process-classes phase, but nar is already using it.

Any thoughts how this might be resolved? Thanks!

<modelVersion>4.0.0</modelVersion>
  <groupId>test</groupId>
  <artifactId>test</artifactId>
  <version>1.0-SNAPSHOT</version>
  <name>${project.artifactId}</name>
  <description>My wonderfull scala app</description>
  <inceptionYear>2015</inceptionYear>
  <licenses>
    <license>
      <name>My License</name>
      <url>http://....</url>
      <distribution>repo</distribution>
    </license>
  </licenses>

  <packaging>nar</packaging>

  <properties>
    <maven.compiler.source>1.6</maven.compiler.source>
    <maven.compiler.target>1.6</maven.compiler.target>
    <encoding>UTF-8</encoding>
    <scala.version>2.11.5</scala.version>
    <scala.compat.version>2.11</scala.compat.version>
  </properties>

  <dependencies>
    <dependency>
      <groupId>org.scala-lang</groupId>
      <artifactId>scala-library</artifactId>
      <version>${scala.version}</version>
    </dependency>

    <!-- Test -->
    <dependency>
      <groupId>junit</groupId>
      <artifactId>junit</artifactId>
      <version>4.11</version>
      <scope>test</scope>
    </dependency>
    <dependency>
      <groupId>org.specs2</groupId>
      <artifactId>specs2-core_${scala.compat.version}</artifactId>
      <version>2.4.16</version>
      <scope>test</scope>
    </dependency>
    <dependency>
      <groupId>org.scalatest</groupId>
      <artifactId>scalatest_${scala.compat.version}</artifactId>
      <version>2.2.4</version>
      <scope>test</scope>
    </dependency>
  </dependencies>

  <build>
    <sourceDirectory>src/main/scala</sourceDirectory>
    <testSourceDirectory>src/test/scala</testSourceDirectory>
    <plugins>
      <plugin>
        <!-- see http://davidb.github.com/scala-maven-plugin -->
        <groupId>net.alchim31.maven</groupId>
        <artifactId>scala-maven-plugin</artifactId>
        <version>3.2.0</version>
        <executions>
          <execution>
            <goals>
              <goal>compile</goal>
              <goal>testCompile</goal>
            </goals>
            <configuration>
              <args>
                <arg>-dependencyfile</arg>
                <arg>${project.build.directory}/.scala_dependencies</arg>
              </args>
            </configuration>
          </execution>
        </executions>
      </plugin>
      <plugin>
        <groupId>com.github.maven-nar</groupId>
        <artifactId>nar-maven-plugin</artifactId>
        <version>3.4.0</version>
        <extensions>true</extensions>
      </plugin>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-surefire-plugin</artifactId>
        <version>2.18.1</version>
        <configuration>
          <useFile>false</useFile>
          <disableXmlReport>true</disableXmlReport>
          <!-- If you have classpath issue like NoDefClassError,... -->
          <!-- useManifestOnlyJar>false</useManifestOnlyJar -->
          <includes>
            <include>**/*Test.*</include>
            <include>**/*Suite.*</include>
          </includes>
        </configuration>
      </plugin>
    </plugins>
  </build>
</project>

[ctrueden]

Hmm, that's tough. For reference, in case you or others haven't seen it, here is the list of goals NAR adds to the lifecycle. Using process-classes for the Scala plugin wouldn't work because it comes after compile, no? Or by "move some stuff" did you mean "move some of the NAR goals"? If the latter, then NAR already has phases with multiple new goals, so that's not necessarily a problem, is it?

Sorry I don't have more time to think about or investigate this. If you find a way to update the NAR plugin to be friendlier for scala/etc. without breaking backwards compatibility, a PR would be supremely welcome.

[00datman]

Not sure if this is as well known as I'd thought, but you can map any plugin's execution to any lifecycle phase with the <phase> tag. You can even disable things by reassigning them to a bogus or null phase that way.

Hope this helps!

[briantopping]

Hey thanks guys, I know this is possible and worked around it by messing with the phase it attached to that way.

I'm thinking since this is a packaging plugin already, there might as well be a custom lifecycle. If NAR used it's own phases, the original ones could remain untouched and default phase definitions embedded in plugins like Scala would work without fiddling.

[00datman]

I'm confused, now. I'm rereading your question, and I realize you mention trying to map to different passes, and the nar-compile phase getting in the way?

Does the Scala plugin also add it's own new phase (possibly in the wrong place)? Otherwise, default-nar-compile should be coming after the default-compile phase, right?