Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • Javadoc plugin
  • Assembly plugin
  • WAR plugin
  • Dependency plugin
  • Enforcer plugin
  • Checkstyle plugin (license containing artifact)

 

Additional artifacts at runtime

Several plugins require extra artifacts which don't belong on the classpath, but which are used for a specific purpose. For instance: the javadoc plugin has docletArtifacts, resourcesArtifacts and tagletArtifacts, which are separate arguments for the javadoc executable, but can all be defined with their GAV. This requires a new element in the pom.xml, so we can separate these kind of files.

Code Block
themeEclipse
languagexml
<plugin>
  <groupId/>
  <artifactId/>
  <version/>
  <dependencies> <!-- classpath, required for compilation --> </dependencies>
  <artifacts>
    <!-- additional files, resolved by Maven -->
    <artifact>
      <groupId/>
      <artifactId/>
      <version/>
      <type/>
      <classifier/>
      <scope/> <!-- optional: some sort of custom qualifier like doclet,taglet,resources. Scope might not be the best name, it shouldn't be confused with the dependency-scope: category? --> 
    </artifact>
  </artifacts>
</plugin>

Additional artifacts at buildtime

It should also be possible to specify some default additional artifacts at buildtime. Specifying them as dependency won´t help, because you can recognize it as an additional artifact. If we allow to let go the restrictions of the scope, it would mean that all unrecognized scopes need to be resolved as compile+runtime scoped dependencies.

Custom artifacts with pomless goals

The best example is probably dependency:get, where you specify the GAV of an artifact and the plugin will download it for you.

...