[
http://jira.codehaus.org/browse/SUREFIRE-598?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=221125#action_221125
]
A commented on SUREFIRE-598:
----------------------------
Thank you very much for looking into the patch. It makes sense to cut off most
of the logging part for now.
I see a problem with the applied part though. It seems to me that it is now
possible to have the output directory added to classpath unintentionally with
line 1032:
classpathElements.add( 1, classesDirectory.getAbsolutePath() );
In my proposed patch I had that part of the code executed only in case
ignoreClasspathElements.equals( "none" ) but now it is executed without
checking that condition.
Same goes for the testOutput directory which might be added to classpath even
if ignoreClasspathElements.equals( "all" )
I can see why you have chosen to leave this part of the former code outside the
ignoreClasspathElements checks but where it stands it makes classpath
modification for testing purposes unsafe as far as I can tell.
I know that my patch seems somehow big but it is really mostly moving code
blocks.
Do you want me to strip the logging part of the patch?
> run maven test with customized classpath
> ----------------------------------------
>
> Key: SUREFIRE-598
> URL: http://jira.codehaus.org/browse/SUREFIRE-598
> Project: Maven Surefire
> Issue Type: New Feature
> Components: Maven Surefire Plugin
> Affects Versions: 2.5
> Reporter: A
> Assignee: Paul Gier
> Fix For: 2.5.1
>
> Attachments: surefire.diff
>
>
> I have modified the plug-in to allow customizing the classpath used when
> running tests. The idea is that sometimes one needs to know everything works
> with the libraries as shipped with another project that is using (and
> includes) the maven project currently under tests. But at the moment one
> cannot override the maven test classpath.
> I hope this functionality will be useful to others tasked to test releases of
> big projects bundling lots of smaller projects and willing to make sure the
> smaller projects are still operating flawlessly in this environment. So I'm
> attaching a patch against trunk r898286 that I hope to be included in future
> maven-surefire-plugin releases.
> There are two configurable additional parameters - ignoreClasspathElements
> and debugClasspath. The former one selects what to remove from the original
> maven test classpath and the second outputs classpath information to the INFO
> level so one doesn't need to dig into the DEBUG output and/or TEST-X.xml
> Basically how I use it is like:
> 1. ignoreClasspathElements=runtime (remove runtime artifacts from test
> classpath)
> 2. additionalClasspathElements=<all jars from the big project>
> 3. debugClasspath=true (so I can easily verify classpath elements are what I
> expect them to be)
> There are two more options for ignoreClasspathElements - none and all. First
> is the default so classpath is what it has always used to be. Latter is to
> nuke the whole test classpath in case somebody needs full control and wants
> to specify even the test scoped classpath elements.
> I've put "@since 2.5.1" but that of course is not something I insist on.
> Please change it to whatever fits best your release rules.
--
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
