Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migrated to Confluence 5.3

This is a dicussion of the proposal to define a contract for Mojos to be able to contribute dependencies to the project to which they are attached.  Here is an example (intended only for illustration) of what this means:

Consider a project using the Antlr parser generator library.  Since version 3.0, Antlr has split its artifacts into org.antlr:antlr (buildtime stuff) and org.antlr:antlr-runtime (the Antlr runtime).  As a project utilizing Antlr, the only real transitive dependency you have is org.antlr:antlr-runtime:

Code Block
xml
xml
<dependencies>
  <dependency>
    <groupId>org.antlr</groupId>
    <artifactId>antlr-runtime</artifactId>
    <version>3.1.1</version>
  </dependency>
</dependencies>

Now, lets say that you've just read about this incredible Antlr v3 tool named gUnit and decide that you want to utilize grammar testing into your build cycle.  Luckily I happen to currently be working on some mojos for gUnit, so you are in luck (smile)

Code Block
xml
xml
<dependencies>
  <dependency>
    <groupId>org.antlr</groupId>
    <artifactId>antlr-runtime</artifactId>
    <version>3.1.1</version>
  </dependency>
</dependencies>
<build>
  <plugins>
    <plugin>
      <groupId>org.codehaus.mojo</groupId>
      <artifactId>gunit-maven-plugin</artifactId>
      <version>1.0.0-SNAPSHOT</version>
      <executions>
        <execution>
          <goals>
            <goal>generate</goal>
          </goals>
        </execution>
      </executions>
    </plugin>
  </plugins>
</build>

The 'generate' goal here is performing the gUnit JUnitCodeGen tool which generates JUnit test classes.  So the plugin generates the JUnit .java files into an output directory and adds that directory to the project as a 'test compile source root' (so that compile-test and surefire can find them later).  The generation bit works here initially, except that later we will get compilation erros from the test-compile mojo.  The reason being that t turns out that when gUnit generates the JUnit classes, they actually contain references back to gUnit classes.  However, as we said at the beginning gunit is contained in the org.antlr:antlr artifact since it is a build-time requirement; but since our project itself does not define a dependency on org.antlr:antlr, the gUnit classes are not on the classpath used by the test compiler (and even if we hacked it such that we immediately compiled the classes after generating them using our 'expanded' classpath, execution (surefire) of the tests would still fail for the same reasons.

 So we are left with a few choices:

  1. Have the gunit-maven-plugin 'hack' the project test-scoped classpath to append org.antlr:antlr so the gUnit classes are found during test-compile and surefire executions.
  2. Define org.antlr:antlr as a separate dependency *in the project*

Maven developers actively frown upon option #1 (rightfully so) and it is expected that the ability to even do this will be removed in 3.x.  But imo #2 is not any better.  The dependency on org.antlr:antlr is clearly an implementation detail of the gunit-maven-plugin that has now bled out into the project pom:

Code Block
xml
xml
<dependencies>
  <dependency>
    <groupId>org.antlr</groupId>
    <artifactId>antlr-runtime</artifactId>
    <version>3.1.1</version>
  </dependency>
  <!-- Here is the 'extra' dep -->
  <dependency>
    <groupId>org.antlr</groupId>
    <artifactId>antlr</artifactId>
    <version>3.1.1</version>
    <!-- we try to use scope to hide it from transitivity -->
    <scope>test</scope> <!-- or perhaps 'provided' (see later discussion) or 'import' (maven >= 2.0.9) -->
  </dependency>
</dependencies>
<build>
  <plugins>
    <plugin>
      <groupId>org.codehaus.mojo</groupId>
      <artifactId>gunit-maven-plugin</artifactId>
      <version>1.0.0-SNAPSHOT</version>
      <executions>
        <execution>
          <goals>
            <goal>generate</goal>
          </goals>
        </execution>
      </executions>
    </plugin>
  </plugins>
</build>

What I propose intsead is a well-defined contract for allowing plugin mojos to contribute *build-time only* dependencies to the project, preferably in a distinct, discrete, early phase of building the MavenProject reference for the project.  I assume this is the intent of the term 'resolution phase' from the email I reference in my proposal. The main idea being that