Copy Page

You are not logged in. Any changes you make will be marked as anonymous. You may want to Log In if you already have an account. You can also Sign Up for a new account.

<p>This is a dicussion of the <a href="http://jira.codehaus.org/browse/MNG-4039" title="JIRA issue">proposal</a> 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:
<br class="atl-forced-newline" /></p>

<p>Consider a project using the <a href="http://antlr.org/" title="Antlr website">Antlr</a> 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:
<br class="atl-forced-newline" /></p>
<table class="wysiwyg-macro" data-macro-name="code" data-macro-default-parameter="xml" style="background-image: url(/plugins/servlet/confluence/placeholder/macro-heading?definition=e2NvZGU6eG1sfQ&amp;locale=en_GB&amp;version=2); background-repeat: no-repeat;" data-macro-body-type="PLAIN_TEXT"><tr><td class="wysiwyg-macro-body"><pre>
&lt;dependencies>
  &lt;dependency>
    &lt;groupId>org.antlr&lt;/groupId>
    &lt;artifactId>antlr-runtime&lt;/artifactId>
    &lt;version>3.1.1&lt;/version>
  &lt;/dependency>
&lt;/dependencies>
</pre></td></tr></table>
<p>Now, lets say that you've just read about this incredible Antlr v3 tool named <a href="http://www.antlr.org/wiki/display/ANTLR3/gUnit+-+Grammar+Unit+Testing" title="gUnit wiki page">gUnit</a> 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 <img class="emoticon emoticon-smile" data-emoticon-name="smile" border="0" src="/s/en_GB/3278/15/_/images/icons/emoticons/smile.png" alt="(smile)" title="(smile)" /><br class="atl-forced-newline" /></p>
<table class="wysiwyg-macro" data-macro-name="code" data-macro-default-parameter="xml" style="background-image: url(/plugins/servlet/confluence/placeholder/macro-heading?definition=e2NvZGU6eG1sfQ&amp;locale=en_GB&amp;version=2); background-repeat: no-repeat;" data-macro-body-type="PLAIN_TEXT"><tr><td class="wysiwyg-macro-body"><pre>
&lt;dependencies>
  &lt;dependency>
    &lt;groupId>org.antlr&lt;/groupId>
    &lt;artifactId>antlr-runtime&lt;/artifactId>
    &lt;version>3.1.1&lt;/version>
  &lt;/dependency>
&lt;/dependencies>
&lt;build>
  &lt;plugins>
    &lt;plugin>
      &lt;groupId>org.codehaus.mojo&lt;/groupId>
      &lt;artifactId>gunit-maven-plugin&lt;/artifactId>
      &lt;version>1.0.0-SNAPSHOT&lt;/version>
      &lt;executions>
        &lt;execution>
          &lt;goals>
            &lt;goal>generate&lt;/goal>
          &lt;/goals>
        &lt;/execution>
      &lt;/executions>
    &lt;/plugin>
  &lt;/plugins>
&lt;/build>
</pre></td></tr></table>
<p>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.</p>

<p> So we are left with a few choices:</p>
<ol>
	<li>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.</li>
	<li>Define org.antlr:antlr as a separate dependency *in the project*</li>
</ol>

<p>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:
<br class="atl-forced-newline" /></p>
<table class="wysiwyg-macro" data-macro-name="code" data-macro-default-parameter="xml" style="background-image: url(/plugins/servlet/confluence/placeholder/macro-heading?definition=e2NvZGU6eG1sfQ&amp;locale=en_GB&amp;version=2); background-repeat: no-repeat;" data-macro-body-type="PLAIN_TEXT"><tr><td class="wysiwyg-macro-body"><pre>
&lt;dependencies>
  &lt;dependency>
    &lt;groupId>org.antlr&lt;/groupId>
    &lt;artifactId>antlr-runtime&lt;/artifactId>
    &lt;version>3.1.1&lt;/version>
  &lt;/dependency>
  &lt;!-- Here is the 'extra' dep -->
  &lt;dependency>
    &lt;groupId>org.antlr&lt;/groupId>
    &lt;artifactId>antlr&lt;/artifactId>
    &lt;version>3.1.1&lt;/version>
    &lt;!-- we try to use scope to hide it from transitivity -->
    &lt;scope>test&lt;/scope> &lt;!-- or perhaps 'provided' (see later discussion) or 'import' (maven >= 2.0.9) -->
  &lt;/dependency>
&lt;/dependencies>
&lt;build>
  &lt;plugins>
    &lt;plugin>
      &lt;groupId>org.codehaus.mojo&lt;/groupId>
      &lt;artifactId>gunit-maven-plugin&lt;/artifactId>
      &lt;version>1.0.0-SNAPSHOT&lt;/version>
      &lt;executions>
        &lt;execution>
          &lt;goals>
            &lt;goal>generate&lt;/goal>
          &lt;/goals>
        &lt;/execution>
      &lt;/executions>
    &lt;/plugin>
  &lt;/plugins>
&lt;/build>
</pre></td></tr></table>
<p>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 <a href="http://jira.codehaus.org/browse/MNG-4039" title="JIRA issue">proposal</a>.  The main idea being that </p>