You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@maven.apache.org by "A (JIRA)" <ji...@codehaus.org> on 2010/01/13 22:23:55 UTC
[jira] Created: (SUREFIRE-598) run maven test with customized
classpath
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
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
[jira] Commented: (SUREFIRE-598) run maven test with customized
classpath
Posted by "A (JIRA)" <ji...@codehaus.org>.
[ 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
[jira] Commented: (SUREFIRE-598) run maven test with customized
classpath
Posted by "Paul Gier (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/SUREFIRE-598?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=221017#action_221017 ]
Paul Gier commented on SUREFIRE-598:
------------------------------------
I trimmed down the patch a bit to just focus on the changes that remove default classpath elements.
Applied in [r943662|http://svn.apache.org/viewvc?view=revision&revision=943662].
> 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
[jira] Commented: (SUREFIRE-598) run maven test with customized
classpath
Posted by "Paul Gier (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/SUREFIRE-598?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=221139#action_221139 ]
Paul Gier commented on SUREFIRE-598:
------------------------------------
Updated in [r943900|http://svn.apache.org/viewvc?view=revision&revision=943900].
> 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
[jira] Updated: (SUREFIRE-598) run maven test with customized
classpath
Posted by "Paul Gier (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/SUREFIRE-598?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Paul Gier updated SUREFIRE-598:
-------------------------------
Fix Version/s: (was: 2.5.1)
2.6
> 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.6
>
> 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
[jira] Issue Comment Edited: (SUREFIRE-598) run maven test with
customized classpath
Posted by "Paul Gier (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/SUREFIRE-598?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=221017#action_221017 ]
Paul Gier edited comment on SUREFIRE-598 at 5/12/10 3:06 PM:
-------------------------------------------------------------
I trimmed down the patch a bit to just focus on the changes that remove default classpath elements.
Applied in [r943662|http://svn.apache.org/viewvc?view=revision&revision=943662].
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.
was (Author: pgier):
I trimmed down the patch a bit to just focus on the changes that remove default classpath elements.
Applied in [r943662|http://svn.apache.org/viewvc?view=revision&revision=943662].
> 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
[jira] Updated: (SUREFIRE-598) run maven test with customized
classpath
Posted by "Paul Gier (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/SUREFIRE-598?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Paul Gier updated SUREFIRE-598:
-------------------------------
Fix Version/s: 2.5.1
Assignee: Paul Gier
> 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
[jira] Closed: (SUREFIRE-598) run maven test with customized
classpath
Posted by "Paul Gier (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/SUREFIRE-598?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Paul Gier closed SUREFIRE-598.
------------------------------
Resolution: Fixed
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|http://svn.apache.org/viewvc?view=revision&revision=945404]
> 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.6
>
> 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