You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@maven.apache.org by "Ben Alex (JIRA)" <ji...@codehaus.org> on 2007/01/10 07:58:21 UTC

[jira] Commented: (MCOMPILER-48) Add maven.compile.failonerror equivalent functionality

    [ http://jira.codehaus.org/browse/MCOMPILER-48?page=comments#action_84595 ] 
            
Ben Alex commented on MCOMPILER-48:
-----------------------------------

The attached files implement the requested functionality. The unit tests pass and I added a new unit test to demonstrate the functionality works as intended.

Please note I needed to add explicit assignment of the default values for failOnError (and debug whilst there), as the @parameter default-value="true" did not appear to work. This may have been a build step I was missing and a commiter may wish to remove the explicit assignment.

> Add maven.compile.failonerror equivalent functionality
> ------------------------------------------------------
>
>                 Key: MCOMPILER-48
>                 URL: http://jira.codehaus.org/browse/MCOMPILER-48
>             Project: Maven 2.x Compiler Plugin
>          Issue Type: Improvement
>            Reporter: Ben Alex
>            Priority: Critical
>         Attachments: compiler-failonerror-test.zip, patch.txt
>
>
> Maven 1.x's "java" plugin offered a maven.compile.failonerror property, which could be set false in order to skip compilation errors.
> I am working on a code generation framework that uses a Maven plugin. The mojo spawns a parallel lifecycle via @execute phase="test-compile", as the mojo itself is @phase generate-sources. This is necessary as the code generator needs to instantiate certain classes to obtain metadata. The nature of the generated types means that users might write code that depends on the generated types to already be compiled on the classpath, although this has not yet happened at this phase because the code generator requires compiled classes first. By the time the generated-sources phase completes and releases to the original lifecycle, the subsequent compilation will work as the generated sources are now available for compilation.
> In practice this issue is easily resolved if AbstractCompilerMojo supported the Maven 1 style maven.compile.failonerror = false property, which could be injected via the MavenProject class during the parallel lifecycle (and reverted upon completion). The relevant lines are:
> 504         if ( compilationError )
> 505         {
> 506             throw new CompilationFailureException( messages );
> 507         }
> 508         else
> 509         {
> 510             for ( Iterator i = messages.iterator(); i.hasNext(); )
> 511             {
> 512                 CompilerError message = (CompilerError) i.next();
> 513 
> 514                 getLog().warn( message.toString() );
> 515             }
> 516         }
> Could you change line 504 to reference an injected property, so the exception can be consumed with simply a warning?
> At present I am planning on working around this issue by using exclude filters (excluding common filename patterns users are likely to generated dependent code for) but this is an inelegant solution by comparison with supporting the injected property. If there is another way to skip errors and I am not aware of it, would you please let me know. Thanks.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira