jira.codehaus.org

  • Log In Access more options
    • Online Help
    • Keyboard Shortcuts
    • About JIRA
    • JIRA Credits
    • What?s New
  • Dashboards Access more options (Alt+d)
  • Projects Access more options (Alt+p)
  • Issues Access more options (Alt+i)
  • Maven Surefire
  • SUREFIRE-598

run maven test with customized classpath

  • Log In
  • Views
    • XML
    • Word
    • Printable

Details

  • Type: New Feature New Feature
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: 2.5
  • Fix Version/s: 2.6
  • Component/s: Maven Surefire Plugin
  • Labels:
    None
  • Complexity:
    Intermediate
  • Patch Submitted:
    Yes

Description

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.

  • Options
    • Sort By Name
    • Sort By Date
    • Ascending
    • Descending
    • Download All

Attachments

  1. File
    surefire.diff
    13/Jan/10 3:21 PM
    8 kB
    A

Issue Links

is related to

New Feature - A new feature of the product, which has yet to be developed. SUREFIRE-576 Have the abiltiy to remove a dependency from the test classpath (at least optional ones

  • Major - Major loss of function.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.
relates to

Improvement - An improvement or enhancement to an existing feature or task. SUREFIRE-619 The surefire plugin should generate the test classpath

  • Major - Major loss of function.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

Activity

Ascending order - Click to sort in descending order
  • All
  • Comments
  • Work Log
  • History
  • Activity
Hide
Permalink
Paul Gier added a comment - 12/May/10 3:04 PM - edited

I trimmed down the patch a bit to just focus on the changes that remove default classpath elements.
Applied in r943662.
For the classpath debugging stuff, it seems like duplicate effort since the information is already available at the debug level. If you still want the debugging changes, maybe that should be a separate jira issue.

Show
Paul Gier added a comment - 12/May/10 3:04 PM - edited I trimmed down the patch a bit to just focus on the changes that remove default classpath elements. Applied in r943662. For the classpath debugging stuff, it seems like duplicate effort since the information is already available at the debug level. If you still want the debugging changes, maybe that should be a separate jira issue.
Hide
Permalink
A added a comment - 13/May/10 7:49 AM

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?

Show
A added a comment - 13/May/10 7:49 AM 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?
Hide
Permalink
Paul Gier added a comment - 13/May/10 9:40 AM

Updated in r943900.

Show
Paul Gier added a comment - 13/May/10 9:40 AM Updated in r943900.
Hide
Permalink
Paul Gier added a comment - 17/May/10 5:17 PM

Due to SUREFIRE-576, this was re-implemented in a more generic way. There are now two new parameters, one to remove individual dependencies by groupId:artifactId, and the other parameter to remove dependencies by scope.
Fixed in r945404

Show
Paul Gier added a comment - 17/May/10 5:17 PM Due to SUREFIRE-576, this was re-implemented in a more generic way. There are now two new parameters, one to remove individual dependencies by groupId:artifactId, and the other parameter to remove dependencies by scope. Fixed in r945404

People

  • Assignee:
    Paul Gier
    Reporter:
    A
Vote (0)
Watch (0)

Dates

  • Created:
    13/Jan/10 3:21 PM
    Updated:
    17/May/10 5:17 PM
    Resolved:
    17/May/10 5:17 PM
  • Atlassian JIRA (v5.0.4#731-sha1:3aa7374)
  • Report a problem
  • Powered by a free Atlassian JIRA open source license for Codehaus. Try JIRA - bug tracking software for your team.