imonteroperez commented on pull request #400:
URL: https://github.com/apache/maven-surefire/pull/400#issuecomment-1009899120


   > > @imonteroperez @slawekjaranowski @olamy
   > > The includes|excludes, includesFile|excludesFile end up within the 
TestListResolver. There is no need to modify the implementation of Provider, 
TestListResolver and other stuff. All we could do is to compromise the sanity 
check `Method filter prohibited in includes|excludes|includesFile|excludesFile 
parameter`.
   > > Below you can see the original method for includesFile. And then the 
sanity check is shifted in the modified code, this is my proposal.
   > > ```
   > >     private List<String> getIncludeList()
   > >         throws MojoFailureException
   > >     {
   > >         List<String> includes = null;
   > >         if ( isSpecificTestSpecified() )
   > >         {
   > >             includes = new ArrayList<>();
   > >             addAll( includes, split( getTest(), "," ) );
   > >         }
   > >         else
   > >         {
   > >             if ( getIncludesFile() != null )
   > >             {
   > >                 includes = readListFromFile( getIncludesFile() );
   > >             }
   > > 
   > >             if ( includes == null )
   > >             {
   > >                 includes = getIncludes();
   > >             }
   > >             else
   > >             {
   > >                 maybeAppendList( includes, getIncludes() );
   > >             }
   > > 
   > >             checkMethodFilterInIncludesExcludes( includes );
   > > 
   > >             if ( includes == null || includes.isEmpty() )
   > >             {
   > >                 includes = asList( getDefaultIncludes() );
   > >             }
   > >         }
   > > 
   > >         return filterNulls( includes );
   > >     }
   > > ```
   > > 
   > > 
   > >     
   > >       
   > >     
   > > 
   > >       
   > >     
   > > 
   > >     
   > >   
   > > changed to
   > > ```
   > >     private List<String> getIncludeList()
   > >         throws MojoFailureException
   > >     {
   > >         List<String> includes = null;
   > >         if ( isSpecificTestSpecified() )
   > >         {
   > >             includes = new ArrayList<>();
   > >             addAll( includes, split( getTest(), "," ) );
   > >         }
   > >         else
   > >         {
   > >             includes = getIncludes();
   > > 
   > >             checkMethodFilterInIncludesExcludes( includes );
   > > 
   > >             if ( getIncludesFile() != null )
   > >             {
   > >                 if ( includes == null )
   > >                 {
   > >                     includes = new ArrayList<>();
   > >                 }
   > >                 addAll( includes, readListFromFile( getIncludesFile() ) 
);
   > >             }
   > > 
   > >             if ( includes == null || includes.isEmpty() )
   > >             {
   > >                 includes = asList( getDefaultIncludes() );
   > >             }
   > >         }
   > > 
   > >         return filterNulls( includes );
   > >     }
   > > ```
   > > 
   > > 
   > >     
   > >       
   > >     
   > > 
   > >       
   > >     
   > > 
   > >     
   > >   
   > > Similar with the excludesFile.
   > > @imonteroperez Would this help you? Of course we do not know the IT 
results yet. They may fail.., not sure! The JavaDoc of both parameters should 
say that the pattern allows using #method, and the site documentation too.
   > 
   > I think this is not going to work because IIUC then is going to be 
delegated to a FileScanner to evaluate which test classes should be executed 
without considering the method filtering. See: 
https://github.com/apache/maven-surefire/blob/master/maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/util/FileScanner.java#L74
 where method is `null`
   
   Applied your proposal with a combination of mine to specify the tests to run 
based on identifying if there is method filtering applied or not on the 
`TestListResolver`


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]


Reply via email to