[ http://jira.codehaus.org/browse/MCOMPILER-48?page=comments#action_84686 ] Ben Alex commented on MCOMPILER-48: -----------------------------------
If only JIRA maintained the same index numbers for attached files... The two files to use are #1 and #3. Disregard the compiler-failonerror-test.zip with a timestamp of 10/Jan/07 12:56 AM. > 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, > 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
