[ http://jira.codehaus.org/browse/MCOMPILER-48?page=all ]
Carlos Sanchez updated MCOMPILER-48:
------------------------------------
Fix Version/s: (was: 2.1)
2.0.2
> 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
> Assigned To: Carlos Sanchez
> Priority: Critical
> Fix For: 2.0.2
>
> Attachments: compiler-failonerror-test.zip,
> 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
