You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@uima.apache.org by "Marshall Schor (JIRA)" <de...@uima.apache.org> on 2013/07/11 17:45:49 UTC

[jira] [Updated] (UIMA-3072) Add workaround for maven plugin-plugin bug

     [ https://issues.apache.org/jira/browse/UIMA-3072?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Marshall Schor updated UIMA-3072:
---------------------------------

    Description: 
The maven-plugin-plugin is used in several projects to help build maven plugins.  Two of its goals, helpmojo and descriptor, extract info about the plugin from annotations.  A recent change deprecated the use of javadoc-style annotations, in favor of Java 5 annotations, and we've changed our maven plugin projects to Java 5 annotation style. 

Unfortunately, this style is broken for these two goals in the maven-plugin-plugin, because the goals end up in many cases (including during release:prepare, and if you use "clean install") being run *before* the compiler runs.  The scan for these Java annotations scans the compiled code (which is not there yet, after, for instance, a clean has been run but before the compiler has run), and doesn't find any.

Two Jira issues (currently unresolved) address this:
  * http://jira.codehaus.org/browse/MNG-5346 and
  * http://jira.codehaus.org/browse/MPLUGIN-238

The way the helpmojo works - appears not to necessarily depend on having the annotations at that time.  The generated helpmojo class is data driven, and works off of an XML file it finds in META-INF/maven/org.apache.uima/<name-of-plugin>/plugin-help.xml.  When the helpmojo is run, it does 2 things: it generates a *generic* helpmojo java source, and it uses the annotations it finds to generate that datafile (plugin-help.xml).  If this is run together with a *later* run of the "descriptor" goal, then that latter goal *regenerates* the plugin-help.xml.

So, things work if you run the helpmojo goal before the compiler step - it generates the helpmojo java source code to be included in the compile, and a "bad" version of the plugin-help.xml resource.  If the descriptor goal is then run *after* the compile step, it regenerates the correct plugin-help.xml resource and puts it into the compiled output in the right spot (since it's a resource, it doesn't need to be compiled).

This is how the workaround proposed by MNG-5346 works.

Workaround this here by setting the phase for the maven-plugin-plugin descriptor to run after compile. Note that build steps that want to invoke this have to specify this in their build plugins configuration, using the id "default-descriptor", to pick up this bit of configuration.  

  was:
The maven-plugin-plugin is used in several projects to help build maven plugins.  Two of its goals, helpmojo and descriptor, extract info about the plugin from annotations.  A recent change deprecated the use of javadoc-style annotations, in favor of Java 5 annotations, and we've changed our maven plugin projects to Java 5 annotation style. 

Unfortunately, this style is broken for these two goals in the maven-plugin-plugin, because the goals end up in many cases (including during release:prepare) being run *before* the compiler runs.  The scan for these Java annotations scans the compiled code (which is not there yet, after, for instance, a clean has been run but before the compiler has run), and doesn't find any.

Two Jira issues (currently unresolved) address this:
  * http://jira.codehaus.org/browse/MNG-5346 and
  * http://jira.codehaus.org/browse/MPLUGIN-238

The workaround proposed by MNG-5346 for the helpmojo doesn't really work because the annotations are not extracted, and the helpmojo will generate without those.

Workaround this here by setting the phase for the maven-plugin-plugin to run after compile.  With this change, the mojohelp goal, if used, will fail, but that's appropriate for now.  If someone really needs this goal to work, it's best to run it, just once, after a compile step has build the classes (run without doing a "clean" so the compile classes are there), and then manually copy the generated classes to the real source, and then drop this goal. (or something equivalent - or wait till this gets fixed properly).

    
> Add workaround for maven plugin-plugin bug
> ------------------------------------------
>
>                 Key: UIMA-3072
>                 URL: https://issues.apache.org/jira/browse/UIMA-3072
>             Project: UIMA
>          Issue Type: Bug
>          Components: Build, Packaging and Test
>    Affects Versions: parent-pom-5
>            Reporter: Marshall Schor
>            Assignee: Marshall Schor
>             Fix For: parent-pom-6
>
>
> The maven-plugin-plugin is used in several projects to help build maven plugins.  Two of its goals, helpmojo and descriptor, extract info about the plugin from annotations.  A recent change deprecated the use of javadoc-style annotations, in favor of Java 5 annotations, and we've changed our maven plugin projects to Java 5 annotation style. 
> Unfortunately, this style is broken for these two goals in the maven-plugin-plugin, because the goals end up in many cases (including during release:prepare, and if you use "clean install") being run *before* the compiler runs.  The scan for these Java annotations scans the compiled code (which is not there yet, after, for instance, a clean has been run but before the compiler has run), and doesn't find any.
> Two Jira issues (currently unresolved) address this:
>   * http://jira.codehaus.org/browse/MNG-5346 and
>   * http://jira.codehaus.org/browse/MPLUGIN-238
> The way the helpmojo works - appears not to necessarily depend on having the annotations at that time.  The generated helpmojo class is data driven, and works off of an XML file it finds in META-INF/maven/org.apache.uima/<name-of-plugin>/plugin-help.xml.  When the helpmojo is run, it does 2 things: it generates a *generic* helpmojo java source, and it uses the annotations it finds to generate that datafile (plugin-help.xml).  If this is run together with a *later* run of the "descriptor" goal, then that latter goal *regenerates* the plugin-help.xml.
> So, things work if you run the helpmojo goal before the compiler step - it generates the helpmojo java source code to be included in the compile, and a "bad" version of the plugin-help.xml resource.  If the descriptor goal is then run *after* the compile step, it regenerates the correct plugin-help.xml resource and puts it into the compiled output in the right spot (since it's a resource, it doesn't need to be compiled).
> This is how the workaround proposed by MNG-5346 works.
> Workaround this here by setting the phase for the maven-plugin-plugin descriptor to run after compile. Note that build steps that want to invoke this have to specify this in their build plugins configuration, using the id "default-descriptor", to pick up this bit of configuration.  

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira