maven-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "A (JIRA)" <j...@codehaus.org>
Subject [jira] Commented: (SUREFIRE-598) run maven test with customized classpath
Date Thu, 13 May 2010 12:50:12 GMT

    [ 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

        

Mime
View raw message