[jira] (SUREFIRE-817) JUnit 4.7 test output is always buffered, lost if forked process exits abnormally
[ https://jira.codehaus.org/browse/SUREFIRE-817?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=303512#comment-303512 ] Przemyslaw Wojnowski commented on SUREFIRE-817: --- I'm also for enabling buffering layer only when running in parallel. > JUnit 4.7 test output is always buffered, lost if forked process exits > abnormally > - > > Key: SUREFIRE-817 > URL: https://jira.codehaus.org/browse/SUREFIRE-817 > Project: Maven Surefire > Issue Type: Bug > Components: Junit 4.7+ (parallel) support >Affects Versions: 2.11 >Reporter: Todd Lipcon > > The junit47 provider and above support multi-threaded test execution, and > thus interpose a buffering layer (ConcurrentReporterManager) in between the > test output and the actual stderr/stdout. This is ostensibly to allow the > multiple threads' stderr and stdout to be demuxed nicely when the suite > completes. But, if the JVM exits abnormally (eg due to a segfault or a > System.exit() call), no output is generated. This is problematic since it's > very hard to debug the test failure! > In my opinion, the buffering layer should only be interposed _when parallel > running is enabled_. For the non-parallel case, there's no need to buffer the > output. A simple test case is to write a JUnit test which prints a line of > output to stderr and then calls System.exit(1). The output doesn't show up > anywhere. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-887) Do not hold forked surefire for debug if there are no tests
Marvin Froeder created SUREFIRE-887:
---
Summary: Do not hold forked surefire for debug if there are no
tests
Key: SUREFIRE-887
URL: https://jira.codehaus.org/browse/SUREFIRE-887
Project: Maven Surefire
Issue Type: Improvement
Components: Maven Failsafe Plugin, Maven Surefire Plugin
Affects Versions: 2.12
Reporter: Marvin Froeder
This is something a bit annoying.
When I enable debug (by either using -Dmaven.surefire.debug=true or
-Dmaven.failsafe.debug=true) surefire will hold maven execution until a
debugger is connected to the forked process.
The problem is that time to time there are no tests to be executed!
So my patch just skips launching the forked VM if there are no tests to be
executed!
{noformat}
Index:
maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/booterclient/ForkStarter.java
===
---
maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/booterclient/ForkStarter.java
(revision 1361154)
+++
maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/booterclient/ForkStarter.java
(working copy)
@@ -31,6 +31,7 @@
import java.util.concurrent.Future;
import java.util.concurrent.ThreadPoolExecutor;
import java.util.concurrent.TimeUnit;
+
import org.apache.maven.plugin.surefire.CommonReflector;
import org.apache.maven.plugin.surefire.StartupReportConfiguration;
import org.apache.maven.plugin.surefire.booterclient.output.ForkClient;
@@ -47,6 +48,8 @@
import org.apache.maven.surefire.providerapi.SurefireProvider;
import org.apache.maven.surefire.report.RunStatistics;
import org.apache.maven.surefire.suite.RunResult;
+import org.apache.maven.surefire.testset.DirectoryScannerParameters;
+import org.apache.maven.surefire.util.DefaultDirectoryScanner;
import org.codehaus.plexus.util.cli.CommandLineException;
import org.codehaus.plexus.util.cli.CommandLineTimeOutException;
import org.codehaus.plexus.util.cli.CommandLineUtils;
@@ -66,6 +69,7 @@
* @author Dan Fabulich
* @author Carlos Sanchez
* @author Kristian Rosenvold
+ * @author Marvin
Froeder
* @version $Id$
*/
public class ForkStarter
@@ -106,6 +110,12 @@
final String requestedForkMode = forkConfiguration.getForkMode();
try
{
+
+if ( Boolean.FALSE.equals( hasTestToRun() ) )
+{
+return new RunResult( 0, 0, 0, 0 );
+}
+
if ( ForkConfiguration.FORK_ONCE.equals( requestedForkMode ) )
{
final ForkClient forkClient =
@@ -134,6 +144,24 @@
return result;
}
+private Boolean hasTestToRun()
+{
+// verify if there are tests to be executed
+DirectoryScannerParameters params =
providerConfiguration.getDirScannerParams();
+if ( params == null )
+{
+//unknow
+return null;
+}
+
+DefaultDirectoryScanner scanner =
+new DefaultDirectoryScanner( params.getTestClassesDirectory(),
params.getIncludes(), params.getExcludes(),
+ params.getSpecificTests() );
+
+String[] tests = scanner.collectTests();
+return tests.length != 0;
+}
+
private RunResult runSuitesForkPerTestSet( final Properties properties,
int forkCount )
throws SurefireBooterForkException
{
Index:
surefire-api/src/main/java/org/apache/maven/surefire/util/DefaultDirectoryScanner.java
===
---
surefire-api/src/main/java/org/apache/maven/surefire/util/DefaultDirectoryScanner.java
(revision 1361154)
+++
surefire-api/src/main/java/org/apache/maven/surefire/util/DefaultDirectoryScanner.java
(working copy)
@@ -108,7 +108,7 @@
return testClass;
}
-String[] collectTests()
+public String[] collectTests()
{
String[] tests = EMPTY_STRING_ARRAY;
if ( basedir.exists() )
Index:
surefire-integration-tests/src/test/java/org/apache/maven/surefire/its/fixture/SurefireLauncher.java
===
---
surefire-integration-tests/src/test/java/org/apache/maven/surefire/its/fixture/SurefireLauncher.java
(revision 1361154)
+++
surefire-integration-tests/src/test/java/org/apache/maven/surefire/its/fixture/SurefireLauncher.java
(working copy)
@@ -42,6 +42,7 @@
* Thread safe only for running in "classes" mode.
*
* @author Kristian Rosenvold
+ * @author Marvin
Froeder
*/
public class SurefireLauncher
{
@@ -466,4 +467,10 @@
{
return surefireVerifier;
}
+
+public SurefireLauncher debugSurefire( )
+{
+return addGoal( "-Dmaven.surefire.debug=true" );
+}
+
}
Index:
surefire-integration-tests/src/test/java/org/apache/maven
[jira] (MINSTALL-50) provide property filtering on .pom files placed in local repo
[
https://jira.codehaus.org/browse/MINSTALL-50?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=303528#comment-303528
]
Ivan Bondarenko commented on MINSTALL-50:
-
Want it too. Currently this can be more or less achieved by
maven-resources-plugin in conjunction with 'pomFile' param of
maven-install-plugin, but this is very ugly approach.
Btw the same for maven-deploy-plugin. I wonder why these two plugins are not
children of one common abstract parent - a lot of logic is just duplicated and
issues are the same.
> provide property filtering on .pom files placed in local repo
> -
>
> Key: MINSTALL-50
> URL: https://jira.codehaus.org/browse/MINSTALL-50
> Project: Maven 2.x Install Plugin
> Issue Type: New Feature
> Components: install:install
>Affects Versions: 2.3
> Environment: independent
>Reporter: Stefan Armbruster
> Attachments: MNG-maven-install.patch, MNG-maven-install.patch
>
>
> When maven installs an artifact, it's pom is also copied into the artifact's
> directory. Unfortunately, if the pom contains a property reference (e.g.
> ${myprop}), this will not be replaced upon copying the pom file.
> I've created a patch for the install plugin that switches on property
> filtering by setting a mojo parameter "filteringEnabled". Since this defaults
> to "false", backward compatibility is kept 100%.
> Some implementation notes:
> * the dirty work is done in FilteredProjectArtifactMetadata.java, the
> property resolution code has been inspired by ResourcesMojo.
> * I've added a unit test, that replaces ${basedir} with the value of a system
> property.
> * since "svn diff" does not handle binary files,
> src/test/resources/unit/basic-install-test-with-filtering/target/maven-install-test-1.0-SNAPSHOT.jar
> is not included in the patch. This file is the same as
> src/test/resources/unit/basic-install-test/target/maven-install-test-1.0-SNAPSHOT.jar
> Since my knowledge of Maven API is more than limited, there might be a more
> elegant way to provide this feature ... but it works! I'd be happy to see
> this in a future release of maven.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5311) maven/tycho does not resolve dependency from local maven repository
dipV created MNG-5311: - Summary: maven/tycho does not resolve dependency from local maven repository Key: MNG-5311 URL: https://jira.codehaus.org/browse/MNG-5311 Project: Maven 2 & 3 Issue Type: Bug Components: Artifacts and Repositories Affects Versions: 3.0.4 Environment: Windows XP Reporter: dipV Attachments: debug-trace.txt There is eclipse plugin dependency. Project2 is dependent on Project1. Steps follwed: 1. Install Project1 in local maven repository using "mvn install -Dtycho.targetPlatform=targetPlatformLocation" command. It installs successfully. 2. Add dependency of Project1 in POM.xml of Project2 3. Try to build Project2. It throws error as "Missing Constraint: Require-Bundle: Project1; bundle-version="1.0.0.001"" -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-2205) "provided" scope dependencies must be transitive
[
https://jira.codehaus.org/browse/MNG-2205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=303579#comment-303579
]
Marco Speranza commented on MNG-2205:
-
Hi all...
I'm in a OSGi environment and I've the same problem.
I need to compile a project
*A* -> *B (provided)* -> *C (provided)*
B is an OSGi bunlde and A needs to use some C's packages/classes
I agree with
[Alexandre|http://jira.codehaus.org/browse/MNG-2205?focusedCommentId=141086&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-141086]
IMHO it's important to have a simple option to add a transitive 'provided'
dependency into the compile classpath.
Could be a simple solution to add a flag into the pom file (like system scope?
) that allows a provided dependency to be transitive?
i.e.
{code:xml}
foo.bar
project
1.0.0
provided
true
{code}
thanks and have a nice day :)
> "provided" scope dependencies must be transitive
>
>
> Key: MNG-2205
> URL: https://jira.codehaus.org/browse/MNG-2205
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Dependencies
>Reporter: David Boden
>Priority: Critical
> Fix For: 3.x / Backlog
>
> Attachments: transitivetest.zip
>
>
> A provided scope dependency can also be thought of as "compile-only".
> Project A requires Sybase JConnect on the runtime classpath. Project A
> declares a "provided" dependency on Sybase JConnect.
> Project B depends upon Project A. Project B declares a "compile" dependency
> on Project A.
> Project C depends upon Project B. Project C declares a "compile" dependency
> on Project B.
> C
> | - compile dependency
> B
> | - compile dependency
> A
> | - provided dependency
> Sybase JConnect
> So, does Project C transitively depend on Sybase JConnect. Yes, of course!
> The "provided" dependency needs to be transitive.
> Ultimately, when Project C gets deployed, Sybase JConnect needs to be
> somewhere on the runtime classpath in order for the application to function.
> It's valid for Project C to assume that Sybase JConnect is available and use
> JDBC all over the Project C code. Project C is safe to do this because it can
> happily deduce that Sybase JConnect will be there in the runtime environment
> because Project A NEEDS IT.
> I've got Use Cases all over my aggregated build which make it absolutely
> critical and common sense that provided scope dependencies are transitive.
> For the (very rare) odd case where you don't want to inherit provided
> dependencies, you can them.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-847) surefire cannot run single testng test
[ https://jira.codehaus.org/browse/SUREFIRE-847?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Rosenvold reassigned SUREFIRE-847: --- Assignee: Kristian Rosenvold > surefire cannot run single testng test > --- > > Key: SUREFIRE-847 > URL: https://jira.codehaus.org/browse/SUREFIRE-847 > Project: Maven Surefire > Issue Type: Bug > Components: TestNG support >Affects Versions: 2.12 > Environment: Windows 7 x64 >Reporter: Nikita Makarov >Assignee: Kristian Rosenvold >Priority: Blocker > Fix For: 2.13 > > Attachments: onlyFailedTest.log, onlyPassedTest.log, > surefire-847_example.zip > > > Trying to run single testng test class with command mvn test -Dtest=SomeTest > fails with message > [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-surefire-plugin:2.12:test (default-test) on > project web-integration-tests: No tests were executed! > (Set -DfailIfNoTests=false to ignore this error.) -> [Help 1]. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-847) surefire cannot run single testng test
[ https://jira.codehaus.org/browse/SUREFIRE-847?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Rosenvold updated SUREFIRE-847: Priority: Blocker (was: Minor) > surefire cannot run single testng test > --- > > Key: SUREFIRE-847 > URL: https://jira.codehaus.org/browse/SUREFIRE-847 > Project: Maven Surefire > Issue Type: Bug > Components: TestNG support >Affects Versions: 2.12 > Environment: Windows 7 x64 >Reporter: Nikita Makarov >Priority: Blocker > Fix For: 2.13 > > Attachments: onlyFailedTest.log, onlyPassedTest.log, > surefire-847_example.zip > > > Trying to run single testng test class with command mvn test -Dtest=SomeTest > fails with message > [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-surefire-plugin:2.12:test (default-test) on > project web-integration-tests: No tests were executed! > (Set -DfailIfNoTests=false to ignore this error.) -> [Help 1]. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (WAGON-354) Site deployment always fails with StringIndexOutOfBoundsException in SftpWagon
[
https://jira.codehaus.org/browse/WAGON-354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=303606#comment-303606
]
Archimedes Trajano commented on WAGON-354:
--
Is there a workaround?
> Site deployment always fails with StringIndexOutOfBoundsException in SftpWagon
> --
>
> Key: WAGON-354
> URL: https://jira.codehaus.org/browse/WAGON-354
> Project: Maven Wagon
> Issue Type: Bug
> Components: wagon-ssh
>Affects Versions: 1.0, 2.0
> Environment: Maven 3.0.3, Site-Plugin 3.0, Wagon 2.0
>Reporter: Juergen Kellerer
>Priority: Critical
> Fix For: 2.3
>
>
> I always get StringIndexOutOfBoundsException on the attempt to deploy a site
> with SFTP using Maven 3 + Site Plugin 3.
> Calling *"mvn site-deploy"* causes:
> {noformat}
> ...
> Caused by: org.apache.maven.plugin.MojoExecutionException: Error uploading
> site
> at
> org.apache.maven.plugins.site.AbstractDeployMojo.push(AbstractDeployMojo.java:464)
> at
> org.apache.maven.plugins.site.AbstractDeployMojo.deploy(AbstractDeployMojo.java:296)
> at
> org.apache.maven.plugins.site.AbstractDeployMojo.deployTo(AbstractDeployMojo.java:257)
> at
> org.apache.maven.plugins.site.AbstractDeployMojo.execute(AbstractDeployMojo.java:165)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
> ... 19 more
> Caused by: org.apache.maven.wagon.TransferFailedException: Error occurred
> while deploying 'c:\Projects\OS\doxia-include\target\site' to remo
> te repository:
> sftp://web.sourceforge.net/home/groups/d/do/doxia-include/htdocs/:
> at
> org.apache.maven.wagon.providers.ssh.jsch.SftpWagon.putDirectory(SftpWagon.java:286)
> at
> org.apache.maven.plugins.site.AbstractDeployMojo.push(AbstractDeployMojo.java:447)
> ... 24 more
> Caused by: 4:
> at com.jcraft.jsch.ChannelSftp.mkdir(ChannelSftp.java:1713)
> at
> org.apache.maven.wagon.providers.ssh.jsch.SftpWagon.mkdir(SftpWagon.java:204)
> at
> org.apache.maven.wagon.providers.ssh.jsch.SftpWagon.ftpRecursivePut(SftpWagon.java:300)
> at
> org.apache.maven.wagon.providers.ssh.jsch.SftpWagon.putDirectory(SftpWagon.java:277)
> ... 25 more
> Caused by: java.lang.StringIndexOutOfBoundsException: String index out of
> range: 0
> at java.lang.String.charAt(String.java:686)
> at
> com.jcraft.jsch.ChannelSftp.remoteAbsolutePath(ChannelSftp.java:2367)
> at com.jcraft.jsch.ChannelSftp.mkdir(ChannelSftp.java:1691)
> ... 28 more
> {noformat}
> *The configuration is*:
> {code:xml}
>
> doxia-include
>
>
>
> ${application.id}.shell.sourceforge.net
> ${application.id}.shell.sourceforge.net
>
> sftp://web.sourceforge.net/home/groups/d/do/${application.id}/htdocs
>
> {code}
> (Btw. I tried variuous urls, "../htdocs", "../htdocs/" and "../htdocs/." but
> the site plugin always normalizes them to "../htdocs/", which is actually the
> right thing to do.)
> *My assumption why it happens:*
> I looked at the sources of wagon (particularly to the methods mentioned in
> the stack trace), and I think the issue seems to be that:
> - Site Plugin 3 always normalizes the remote directory to end with a trailing
> slash.
> - WagonSftp.putDirectory:277 calls ScpHelper.getResourceFilename(
> destinationDirectory ) on this directory which returns an empty string.
> - WagonSfto.ftpRecursivePut:300 calls mkdir with an empty string which causes
> the exception.
> Actually it looks as if older site plugins added a trailing "/." to the path
> instead of just "/" as otherwise it would have been broken before (I did not
> verify this). Nevertheless I think the bug is in the Wagon implementation as
> it should not fail if the destination is given like this.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
