[ 
https://jira.codehaus.org/browse/SUREFIRE-803?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=285659#comment-285659
 ] 

John Casey commented on SUREFIRE-803:
-------------------------------------

Do we have other cases where we're using the pluginContext for this sort of 
state? I know that's the point of the context, but it used to be broken once 
upon a time, and I'd be interested in seeing some prior art. Otherwise, I 
suppose we could try that and fall back to a file if it doesn't work.

I'm fine with changing the default behavior, since I think it's unlikely most 
people will really be able to tell. But does that mean the 'test' phase will 
actually run both surefire:test and surefire:verify, or would surefire:test 
actually run somewhere earlier (where, that it won't interfere with setting up 
the test classes?)...or, would users need to know that running `mvn clean test` 
no longer verifies the outcome of the surefire tests?

Or...are we hoping to pin verification to the end of the list of executions, 
using the pluginContext to detect that end? In effect, making it still be 
"built into" the surefire:test goal rather than splitting it into a 
surefire:verify goal?
                
> Multiple Surefire executions - FAILURE in an execution prevents successive 
> from running.
> ----------------------------------------------------------------------------------------
>
>                 Key: SUREFIRE-803
>                 URL: https://jira.codehaus.org/browse/SUREFIRE-803
>             Project: Maven Surefire
>          Issue Type: Improvement
>          Components: Maven Surefire Plugin
>    Affects Versions: 2.10
>            Reporter: Ondrej Zizka
>            Assignee: John Casey
>         Attachments: surefire-803-failure-prevents-subsequent-executions.zip
>
>
> Let's have multiple Surefire executions in a single module (different config 
> needed).
> A failure of a test in one of these executions prevents running the 
> successive.
> Surefire's testFailureIgnore is not an option because it makes a run with 
> failures succeed.
> This behavior is undocumented.
> Also, it is undesired - the module as a whole should fail, but all it's tests 
> should run.

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

        

Reply via email to