[jira] [Commented] (SUREFIRE-1269) FileNotFoundException by SureFire after execution of tests
[ https://issues.apache.org/jira/browse/SUREFIRE-1269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15422379#comment-15422379 ] Julien Herr commented on SUREFIRE-1269: --- The problem is located in JqReporter: https://github.com/cbeust/testng/blob/master/src/main/java/org/testng/reporters/JqReporter.java#L40 `org.testng.reporters.jq.Main` should be used instead. > FileNotFoundException by SureFire after execution of tests > -- > > Key: SUREFIRE-1269 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1269 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Surefire Plugin, TestNG support >Affects Versions: 2.19.1 > Environment: OS: Win10 > Java: 8 rev.102 > Maven: 3.3.9 > TestNG: 6.9.10 > SureFire: 2.19.1 > SystemMemory: 16G >Reporter: Deepak Mahapatro >Priority: Minor > Attachments: Test.zip, screenshot-1.png > > > After executing tests, maven is throwing a FienotFoundException which > originates from surefire (I understood the source from trace.). > java.io.FileNotFoundException: \Users\cedric\java\misc\jquery\head (The > system cannot find the path specified) > at java.io.FileInputStream.open0(Native Method) > at java.io.FileInputStream.open(FileInputStream.java:195) > at java.io.FileInputStream.(FileInputStream.java:138) > at org.testng.reporters.Files.readFile(Files.java:21) > at org.testng.reporters.JqReporter.generateReport(JqReporter.java:40) > at org.testng.TestNG.generateReports(TestNG.java:1135) > at org.testng.TestNG.run(TestNG.java:1081) > at > org.apache.maven.surefire.testng.TestNGExecutor.run(TestNGExecutor.java:281) > at > org.apache.maven.surefire.testng.TestNGXmlTestSuite.execute(TestNGXmlTestSuite.java:75) > at > org.apache.maven.surefire.testng.TestNGProvider.invoke(TestNGProvider.java:121) > at > org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:290) > at > org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:242) > at > org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:121) > This is not impacting either test result or build status but it is creating > some confusion while analyzing logs from both file system and from maven > console. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SUREFIRE-1269) FileNotFoundException by SureFire after execution of tests
[ https://issues.apache.org/jira/browse/SUREFIRE-1269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15422386#comment-15422386 ] Julien Herr commented on SUREFIRE-1269: --- I created an issue on TestNG project: https://github.com/cbeust/testng/issues/1117 > FileNotFoundException by SureFire after execution of tests > -- > > Key: SUREFIRE-1269 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1269 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Surefire Plugin, TestNG support >Affects Versions: 2.19.1 > Environment: OS: Win10 > Java: 8 rev.102 > Maven: 3.3.9 > TestNG: 6.9.10 > SureFire: 2.19.1 > SystemMemory: 16G >Reporter: Deepak Mahapatro >Priority: Minor > Attachments: Test.zip, screenshot-1.png > > > After executing tests, maven is throwing a FienotFoundException which > originates from surefire (I understood the source from trace.). > java.io.FileNotFoundException: \Users\cedric\java\misc\jquery\head (The > system cannot find the path specified) > at java.io.FileInputStream.open0(Native Method) > at java.io.FileInputStream.open(FileInputStream.java:195) > at java.io.FileInputStream.(FileInputStream.java:138) > at org.testng.reporters.Files.readFile(Files.java:21) > at org.testng.reporters.JqReporter.generateReport(JqReporter.java:40) > at org.testng.TestNG.generateReports(TestNG.java:1135) > at org.testng.TestNG.run(TestNG.java:1081) > at > org.apache.maven.surefire.testng.TestNGExecutor.run(TestNGExecutor.java:281) > at > org.apache.maven.surefire.testng.TestNGXmlTestSuite.execute(TestNGXmlTestSuite.java:75) > at > org.apache.maven.surefire.testng.TestNGProvider.invoke(TestNGProvider.java:121) > at > org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:290) > at > org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:242) > at > org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:121) > This is not impacting either test result or build status but it is creating > some confusion while analyzing logs from both file system and from maven > console. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (SUREFIRE-1259) ParallelComputerBuilder should not filter out runners with zero children
[
https://issues.apache.org/jira/browse/SUREFIRE-1259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Fuud updated SUREFIRE-1259:
---
Description:
ParallelComputerBuilder
{code}
private WrappedRunners wrapRunners( Collection runners )
throws InitializationError
{
// Do NOT use allGroups here.
long childrenCounter = 0;
ArrayList runs = new ArrayList();
for ( T runner : runners )
{
if ( runner != null )
{
int children = countChildren( runner );
childrenCounter += children;
if ( children != 0 )
{
runs.add( runner );
}
}
}
return runs.isEmpty() ? new WrappedRunners() : new WrappedRunners(
createSuite( runs ), childrenCounter );
}
{code}
JUnit does not enfore ParentRunner to report all it's children. Therefore zero
children count should not be criteria to skip this runner.
I suggest to remove "if ( children != 0 )" condition and run runner anyway.
Pull request https://github.com/apache/maven-surefire/pull/114
was:
ParallelComputerBuilder
{code}
private WrappedRunners wrapRunners( Collection runners )
throws InitializationError
{
// Do NOT use allGroups here.
long childrenCounter = 0;
ArrayList runs = new ArrayList();
for ( T runner : runners )
{
if ( runner != null )
{
int children = countChildren( runner );
childrenCounter += children;
if ( children != 0 )
{
runs.add( runner );
}
}
}
return runs.isEmpty() ? new WrappedRunners() : new WrappedRunners(
createSuite( runs ), childrenCounter );
}
{code}
JUnit does not enfore ParentRunner to report all it's children. Therefore zero
children count should not be criteria to skip this runner.
I suggest to remove "if ( children != 0 )" condition and run runner anyway.
> ParallelComputerBuilder should not filter out runners with zero children
>
>
> Key: SUREFIRE-1259
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1259
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Failsafe Plugin
>Affects Versions: 2.19.1
>Reporter: Fuud
>
> ParallelComputerBuilder
> {code}
> private WrappedRunners wrapRunners( Collection runners )
> throws InitializationError
> {
> // Do NOT use allGroups here.
> long childrenCounter = 0;
> ArrayList runs = new ArrayList();
> for ( T runner : runners )
> {
> if ( runner != null )
> {
> int children = countChildren( runner );
> childrenCounter += children;
> if ( children != 0 )
> {
> runs.add( runner );
> }
> }
> }
> return runs.isEmpty() ? new WrappedRunners() : new
> WrappedRunners( createSuite( runs ), childrenCounter );
> }
> {code}
> JUnit does not enfore ParentRunner to report all it's children. Therefore
> zero children count should not be criteria to skip this runner.
> I suggest to remove "if ( children != 0 )" condition and run runner anyway.
> Pull request https://github.com/apache/maven-surefire/pull/114
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (SUREFIRE-1268) With JUnit listener, redirectTestOutputToFile is ignored
[
https://issues.apache.org/jira/browse/SUREFIRE-1268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15422503#comment-15422503
]
Francesco Chicchiriccò edited comment on SUREFIRE-1268 at 8/16/16 9:44 AM:
---
I have created https://github.com/ilgrosso/surefire1268
When you run {{mvn clean test}}, you will get an output like as
{code}
Running net.tirasa.test.surefire1268.BaseTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.02 sec - in
net.tirasa.test.surefire1268.BaseTest
11:39:56.407 INFO net.tirasa.test.surefire1268.BaseTest - * You should
not be viewing this from console
Results :
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
{code}
The line
{code}
11:39:56.407 INFO net.tirasa.test.surefire1268.BaseTest - * You should
not be viewing this from console
{code}
is supposed to be included in
{{target/surefire-reports/net.tirasa.test.surefire1268.BaseTest-output.txt}},
but such file is not created.
When commenting out
{code}
listener
net.tirasa.test.surefire1268.NotDoingSoMuchListener
{code}
in the {{pom.xml}}, everything works as expected.
Moreover, I have noticed that everything works also if *not* commenting the
listener property in the {{pom.xml}} but removing this line
{code}
private static final Logger LOG =
LoggerFactory.getLogger(NotDoingSoMuchListener.class);
{code}
in the listener class.
was (Author: ilgrosso):
I have created https://github.com/ilgrosso/surefire1268
When you run {{mvn clean test}}, you will get an output like as
{code}
Running net.tirasa.test.surefire1268.BaseTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.02 sec - in
net.tirasa.test.surefire1268.BaseTest
11:39:56.407 INFO net.tirasa.test.surefire1268.BaseTest - * You should
not be viewing this from console
Results :
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
{code}
The like
{code}
11:39:56.407 INFO net.tirasa.test.surefire1268.BaseTest - * You should
not be viewing this from console
{code}
is supposed to be included in
{{target/surefire-reports/net.tirasa.test.surefire1268.BaseTest-output.txt}},
but such file is not created.
When commenting out
{code}
listener
net.tirasa.test.surefire1268.NotDoingSoMuchListener
{code}
in the {{pom.xml}}, everything works as expected.
Moreover, I have noticed that everything works also if *not* commenting the
listener property in the {{pom.xml}} but removing this line
{code}
private static final Logger LOG =
LoggerFactory.getLogger(NotDoingSoMuchListener.class);
{code}
in the listener class.
> With JUnit listener, redirectTestOutputToFile is ignored
>
>
> Key: SUREFIRE-1268
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1268
> Project: Maven Surefire
> Issue Type: Bug
> Components: Junit 4.x support, Maven Surefire Plugin
>Affects Versions: 2.19.1
> Environment: Linux
>Reporter: Francesco Chicchiriccò
>
> When specifying, according to [this
> doc|http://maven.apache.org/surefire/maven-surefire-plugin/examples/junit.html#Using_Custom_Listeners_and_Reporters],
> a JUnit listener, the test output is sent to STDOUT, even though
> {{redirectTestOutputToFile}} is set to {{true}}.
> This happens with log4j2 configuration for {{SYSTEM_OUT}}, regular
> {{System.out.println}} works fine.
> With no {{properties}} element, {{redirectTestOutputToFile}} is honored.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SUREFIRE-1268) With JUnit listener, redirectTestOutputToFile is ignored
[
https://issues.apache.org/jira/browse/SUREFIRE-1268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15422503#comment-15422503
]
Francesco Chicchiriccò commented on SUREFIRE-1268:
--
I have created https://github.com/ilgrosso/surefire1268
When you run {{mvn clean test}}, you will get an output like as
{code}
Running net.tirasa.test.surefire1268.BaseTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.02 sec - in
net.tirasa.test.surefire1268.BaseTest
11:39:56.407 INFO net.tirasa.test.surefire1268.BaseTest - * You should
not be viewing this from console
Results :
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
{code}
The like
{code}
11:39:56.407 INFO net.tirasa.test.surefire1268.BaseTest - * You should
not be viewing this from console
{code}
is supposed to be included in
{{target/surefire-reports/net.tirasa.test.surefire1268.BaseTest-output.txt}},
but such file is not created.
When commenting out
{code}
listener
net.tirasa.test.surefire1268.NotDoingSoMuchListener
{code}
in the {{pom.xml}}, everything works as expected.
Moreover, I have noticed that everything works also if *not* commenting the
listener property in the {{pom.xml}} but removing this line
{code}
private static final Logger LOG =
LoggerFactory.getLogger(NotDoingSoMuchListener.class);
{code}
in the listener class.
> With JUnit listener, redirectTestOutputToFile is ignored
>
>
> Key: SUREFIRE-1268
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1268
> Project: Maven Surefire
> Issue Type: Bug
> Components: Junit 4.x support, Maven Surefire Plugin
>Affects Versions: 2.19.1
> Environment: Linux
>Reporter: Francesco Chicchiriccò
>
> When specifying, according to [this
> doc|http://maven.apache.org/surefire/maven-surefire-plugin/examples/junit.html#Using_Custom_Listeners_and_Reporters],
> a JUnit listener, the test output is sent to STDOUT, even though
> {{redirectTestOutputToFile}} is set to {{true}}.
> This happens with log4j2 configuration for {{SYSTEM_OUT}}, regular
> {{System.out.println}} works fine.
> With no {{properties}} element, {{redirectTestOutputToFile}} is honored.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SUREFIRE-1259) ParallelComputerBuilder should not filter out runners with zero children
[
https://issues.apache.org/jira/browse/SUREFIRE-1259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15422509#comment-15422509
]
Fuud commented on SUREFIRE-1259:
[~tibor17]
Main reason for this issue is that runner that does not report any child can
discover some at runtime. For example Spock's runner "Sputnik" does not report
parametrized children because parameter calculation is performed before each
test run.
> ParallelComputerBuilder should not filter out runners with zero children
>
>
> Key: SUREFIRE-1259
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1259
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Failsafe Plugin
>Affects Versions: 2.19.1
>Reporter: Fuud
>
> ParallelComputerBuilder
> {code}
> private WrappedRunners wrapRunners( Collection runners )
> throws InitializationError
> {
> // Do NOT use allGroups here.
> long childrenCounter = 0;
> ArrayList runs = new ArrayList();
> for ( T runner : runners )
> {
> if ( runner != null )
> {
> int children = countChildren( runner );
> childrenCounter += children;
> if ( children != 0 )
> {
> runs.add( runner );
> }
> }
> }
> return runs.isEmpty() ? new WrappedRunners() : new
> WrappedRunners( createSuite( runs ), childrenCounter );
> }
> {code}
> JUnit does not enfore ParentRunner to report all it's children. Therefore
> zero children count should not be criteria to skip this runner.
> I suggest to remove "if ( children != 0 )" condition and run runner anyway.
> Pull request https://github.com/apache/maven-surefire/pull/114
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (DOXIA-543) maven-doxia-markdown fails in parallel builds
Daniel Wegener created DOXIA-543: Summary: maven-doxia-markdown fails in parallel builds Key: DOXIA-543 URL: https://issues.apache.org/jira/browse/DOXIA-543 Project: Maven Doxia Issue Type: Bug Components: Module - Markdown Affects Versions: 1.7 Reporter: Daniel Wegener The PegDownProcess used at https://github.com/apache/maven-doxia/blob/doxia-1.7/doxia-modules/doxia-module-markdown/src/main/java/org/apache/maven/doxia/module/markdown/MarkdownParser.java#L72 is shared between multiple concurrent executions of the maven-site-plugin. This leads to random errors (NPEs, ClassCastException) because the parser state machine is reused by multiple threads. It seem not to be enough to make the field non-static since the whole MarkdownParser instance seem to be shared between different threads. The PegDown Javadoc explicitly states taht a PegDownProcessor is not thread-safe: https://github.com/sirthias/pegdown/blob/master/src/main/java/org/pegdown/PegDownProcessor.java Possible solutions: - Put the PegDownProcessor into a threadLocal. - Instanciate the PegDownProcessor in the toHtml method. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DOXIA-543) maven-doxia-markdown fails in parallel builds
[ https://issues.apache.org/jira/browse/DOXIA-543?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Wegener updated DOXIA-543: - Description: The PegDownProcessor used at https://github.com/apache/maven-doxia/blob/doxia-1.7/doxia-modules/doxia-module-markdown/src/main/java/org/apache/maven/doxia/module/markdown/MarkdownParser.java#L72 is shared between multiple concurrent executions of the maven-site-plugin. This leads to random errors (NPEs, ClassCastException) because the parser state machine is reused by multiple threads. It seem not to be enough to make the field non-static since the whole MarkdownParser instance seem to be shared between different threads. The PegDown Javadoc explicitly states that a PegDownProcessor is not thread-safe: https://github.com/sirthias/pegdown/blob/master/src/main/java/org/pegdown/PegDownProcessor.java Possible solutions: - Put the PegDownProcessor into a threadLocal. - Instanciate the PegDownProcessor in the toHtml method. was: The PegDownProcessor used at https://github.com/apache/maven-doxia/blob/doxia-1.7/doxia-modules/doxia-module-markdown/src/main/java/org/apache/maven/doxia/module/markdown/MarkdownParser.java#L72 is shared between multiple concurrent executions of the maven-site-plugin. This leads to random errors (NPEs, ClassCastException) because the parser state machine is reused by multiple threads. It seem not to be enough to make the field non-static since the whole MarkdownParser instance seem to be shared between different threads. The PegDown Javadoc explicitly states taht a PegDownProcessor is not thread-safe: https://github.com/sirthias/pegdown/blob/master/src/main/java/org/pegdown/PegDownProcessor.java Possible solutions: - Put the PegDownProcessor into a threadLocal. - Instanciate the PegDownProcessor in the toHtml method. > maven-doxia-markdown fails in parallel builds > - > > Key: DOXIA-543 > URL: https://issues.apache.org/jira/browse/DOXIA-543 > Project: Maven Doxia > Issue Type: Bug > Components: Module - Markdown >Affects Versions: 1.7 >Reporter: Daniel Wegener > Original Estimate: 10m > Remaining Estimate: 10m > > The PegDownProcessor used at > https://github.com/apache/maven-doxia/blob/doxia-1.7/doxia-modules/doxia-module-markdown/src/main/java/org/apache/maven/doxia/module/markdown/MarkdownParser.java#L72 > is shared between multiple concurrent executions of the maven-site-plugin. > This leads to random errors (NPEs, ClassCastException) because the parser > state machine is reused by multiple threads. > It seem not to be enough to make the field non-static since the whole > MarkdownParser instance seem to be shared between different threads. > The PegDown Javadoc explicitly states that a PegDownProcessor is not > thread-safe: > https://github.com/sirthias/pegdown/blob/master/src/main/java/org/pegdown/PegDownProcessor.java > Possible solutions: > - Put the PegDownProcessor into a threadLocal. > - Instanciate the PegDownProcessor in the toHtml method. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DOXIA-543) maven-doxia-markdown fails in parallel builds
[ https://issues.apache.org/jira/browse/DOXIA-543?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Wegener updated DOXIA-543: - Description: The PegDownProcessor used at https://github.com/apache/maven-doxia/blob/doxia-1.7/doxia-modules/doxia-module-markdown/src/main/java/org/apache/maven/doxia/module/markdown/MarkdownParser.java#L72 is shared between multiple concurrent executions of the maven-site-plugin. This leads to random errors (NPEs, ClassCastException) because the parser state machine is reused by multiple threads. It seem not to be enough to make the field non-static since the whole MarkdownParser instance seem to be shared between different threads. The PegDown Javadoc explicitly states taht a PegDownProcessor is not thread-safe: https://github.com/sirthias/pegdown/blob/master/src/main/java/org/pegdown/PegDownProcessor.java Possible solutions: - Put the PegDownProcessor into a threadLocal. - Instanciate the PegDownProcessor in the toHtml method. was: The PegDownProcess used at https://github.com/apache/maven-doxia/blob/doxia-1.7/doxia-modules/doxia-module-markdown/src/main/java/org/apache/maven/doxia/module/markdown/MarkdownParser.java#L72 is shared between multiple concurrent executions of the maven-site-plugin. This leads to random errors (NPEs, ClassCastException) because the parser state machine is reused by multiple threads. It seem not to be enough to make the field non-static since the whole MarkdownParser instance seem to be shared between different threads. The PegDown Javadoc explicitly states taht a PegDownProcessor is not thread-safe: https://github.com/sirthias/pegdown/blob/master/src/main/java/org/pegdown/PegDownProcessor.java Possible solutions: - Put the PegDownProcessor into a threadLocal. - Instanciate the PegDownProcessor in the toHtml method. > maven-doxia-markdown fails in parallel builds > - > > Key: DOXIA-543 > URL: https://issues.apache.org/jira/browse/DOXIA-543 > Project: Maven Doxia > Issue Type: Bug > Components: Module - Markdown >Affects Versions: 1.7 >Reporter: Daniel Wegener > Original Estimate: 10m > Remaining Estimate: 10m > > The PegDownProcessor used at > https://github.com/apache/maven-doxia/blob/doxia-1.7/doxia-modules/doxia-module-markdown/src/main/java/org/apache/maven/doxia/module/markdown/MarkdownParser.java#L72 > is shared between multiple concurrent executions of the maven-site-plugin. > This leads to random errors (NPEs, ClassCastException) because the parser > state machine is reused by multiple threads. > It seem not to be enough to make the field non-static since the whole > MarkdownParser instance seem to be shared between different threads. > The PegDown Javadoc explicitly states taht a PegDownProcessor is not > thread-safe: > https://github.com/sirthias/pegdown/blob/master/src/main/java/org/pegdown/PegDownProcessor.java > Possible solutions: > - Put the PegDownProcessor into a threadLocal. > - Instanciate the PegDownProcessor in the toHtml method. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (WAGON-461) URL string not properly encoded by webdav
[
https://issues.apache.org/jira/browse/WAGON-461?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15422606#comment-15422606
]
Mike Summers commented on WAGON-461:
The 409 is a result of the malformed URI. The exception message shows the
encoded URI with escaped spaces has been further escaped- the space (%20) has
been escaped to %2520 which is incorrect.
{color:red}
https://snafu.sharefile-webdav.com/Shared%2520Folders/Fit%2520-%2520Expert%2520Services/IBM/synthetics-monitor-plugin-1.0.0.jar.
{color}
The collection exists. wagon-webdav works _if_ WebDavWagon provides the
encoding as required by org.apache.common.httpclient.HttpMethodBase(String uri)
{code:java}
/**
* Constructor specifying a URI.
* It is responsibility of the caller to ensure that URI elements
* (path & query parameters) are properly encoded (URL safe).
{code}
> URL string not properly encoded by webdav
> -
>
> Key: WAGON-461
> URL: https://issues.apache.org/jira/browse/WAGON-461
> Project: Maven Wagon
> Issue Type: Bug
> Components: wagon-webdav
>Affects Versions: 2.10
> Environment: All
>Reporter: Mike Summers
>
> wagon-webdav is not calling EncodingUtil prior to instantiating MkColMethod
> which results in
> {code:java}
> Caused by: java.lang.IllegalArgumentException: Invalid uri
> 'https://snafu.sharefile-webdav.com/Shared Folders/Fit - Expert
> Services/IBM/': escaped absolute path not valid
> {code}
> when there are special characters in the URI string.
> Changing line 153 of org.apache.maven.wagon.providers.webdav.WebDavWagon from
> {code:java}
> method = new MkColMethod( url );
> {code}
> to
> {code:java}
> method = new MkColMethod( EncodingUtil.encodeURLToString( url ) );
> {code}
> solves the issue although you may want to fix it elsewhere in the flow.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (MDEP-537) Goal purge-local-repository requires a Maven project, even with manualIncludes
Guillaume Boué created MDEP-537:
---
Summary: Goal purge-local-repository requires a Maven project,
even with manualIncludes
Key: MDEP-537
URL: https://issues.apache.org/jira/browse/MDEP-537
Project: Maven Dependency Plugin
Issue Type: Improvement
Components: purge-local-repository
Affects Versions: 2.10
Reporter: Guillaume Boué
Priority: Minor
Triggered by the Stack Overflow question [Can I remove jar from local
repository without pom.xml?|http://stackoverflow.com/q/38973960/1743880].
The goal {{purge-local-repository}} requires a Maven project to be executed,
but it also accepts a
[{{manualInclude}}|http://maven.apache.org/plugins/maven-dependency-plugin/purge-local-repository-mojo.html#manualInclude]
parameter, which bypasses the purge of project dependencies and only removes
the ones specified. Therefore, the plugin should be updated to remove the
requirement of a MavenProject.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (WAGON-461) URL string not properly encoded by webdav
[
https://issues.apache.org/jira/browse/WAGON-461?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15422701#comment-15422701
]
Michael Osipov commented on WAGON-461:
--
Just checked the code. Something seems to be fishy about Jackrabbit here since
HttpClient does require the URI to be encoded which you did first. Someone
applies {{encodeURI}} a second time. Have you enabled debugging on Jackrabbit
and HttpClient? You should see where the encoding happens again.
> URL string not properly encoded by webdav
> -
>
> Key: WAGON-461
> URL: https://issues.apache.org/jira/browse/WAGON-461
> Project: Maven Wagon
> Issue Type: Bug
> Components: wagon-webdav
>Affects Versions: 2.10
> Environment: All
>Reporter: Mike Summers
>
> wagon-webdav is not calling EncodingUtil prior to instantiating MkColMethod
> which results in
> {code:java}
> Caused by: java.lang.IllegalArgumentException: Invalid uri
> 'https://snafu.sharefile-webdav.com/Shared Folders/Fit - Expert
> Services/IBM/': escaped absolute path not valid
> {code}
> when there are special characters in the URI string.
> Changing line 153 of org.apache.maven.wagon.providers.webdav.WebDavWagon from
> {code:java}
> method = new MkColMethod( url );
> {code}
> to
> {code:java}
> method = new MkColMethod( EncodingUtil.encodeURLToString( url ) );
> {code}
> solves the issue although you may want to fix it elsewhere in the flow.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (WAGON-461) URL string not properly encoded by webdav
[
https://issues.apache.org/jira/browse/WAGON-461?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15422713#comment-15422713
]
Mike Summers commented on WAGON-461:
I did, debug didn't reveal anything- there's not much logging in Jackrabbit.
I added some debug logging to my local copy of the source and it shows that the
URI is not encoded at the point that it instantiates MkColMethod which leads
directly to the HttpClient problem.
The double encoding is a puzzle. Why adding the encode on the call to
MkColMethod doesn't break is also odd.
As soon as I can I'll add two tests to the test suite, 1) URI with spaces, and
2) URI with encoded spaces- that should help with the puzzle.
Thanks for your help.
> URL string not properly encoded by webdav
> -
>
> Key: WAGON-461
> URL: https://issues.apache.org/jira/browse/WAGON-461
> Project: Maven Wagon
> Issue Type: Bug
> Components: wagon-webdav
>Affects Versions: 2.10
> Environment: All
>Reporter: Mike Summers
>
> wagon-webdav is not calling EncodingUtil prior to instantiating MkColMethod
> which results in
> {code:java}
> Caused by: java.lang.IllegalArgumentException: Invalid uri
> 'https://snafu.sharefile-webdav.com/Shared Folders/Fit - Expert
> Services/IBM/': escaped absolute path not valid
> {code}
> when there are special characters in the URI string.
> Changing line 153 of org.apache.maven.wagon.providers.webdav.WebDavWagon from
> {code:java}
> method = new MkColMethod( url );
> {code}
> to
> {code:java}
> method = new MkColMethod( EncodingUtil.encodeURLToString( url ) );
> {code}
> solves the issue although you may want to fix it elsewhere in the flow.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (MLINKCHECK-26) Linkcheck does not support parrallel builds
Daniel Wegener created MLINKCHECK-26:
Summary: Linkcheck does not support parrallel builds
Key: MLINKCHECK-26
URL: https://issues.apache.org/jira/browse/MLINKCHECK-26
Project: Maven Linkcheck Plugin
Issue Type: Bug
Reporter: Daniel Wegener
Running multi-module-builds in parallel where multiple modules use the
linkcheck plugin can trigger the following exception.
{code}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-linkcheck-plugin:1.2:linkcheck (run-linkcheck)
on project foo.documentation.arc: Execution run-linkcheck of goal
org.apache.maven.plugins:maven-linkcheck-plugin:1.2:linkcheck failed.
ConcurrentModificationException -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal
org.apache.maven.plugins:maven-linkcheck-plugin:1.2:linkcheck (run-linkcheck)
on project foo.documentation.arc: Execution run-linkcheck of goal
org.apache.maven.plugins:maven-linkcheck-plugin:1.2:linkcheck failed.
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:212)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
at
org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call(MultiThreadedBuilder.java:185)
at
org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call(MultiThreadedBuilder.java:181)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
Caused by: org.apache.maven.plugin.PluginExecutionException: Execution
run-linkcheck of goal
org.apache.maven.plugins:maven-linkcheck-plugin:1.2:linkcheck failed.
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:145)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:207)
... 11 more
Caused by: java.util.ConcurrentModificationException
at java.util.TreeMap$PrivateEntryIterator.nextEntry(TreeMap.java:1207)
at java.util.TreeMap$KeyIterator.next(TreeMap.java:1261)
at
org.apache.maven.doxia.linkcheck.DefaultLinkCheck.check(DefaultLinkCheck.java:505)
at
org.apache.maven.doxia.linkcheck.DefaultLinkCheck.checkFile(DefaultLinkCheck.java:447)
at
org.apache.maven.doxia.linkcheck.DefaultLinkCheck.findAndCheckFiles(DefaultLinkCheck.java:423)
at
org.apache.maven.doxia.linkcheck.DefaultLinkCheck.execute(DefaultLinkCheck.java:232)
at
org.apache.maven.plugins.linkcheck.LinkcheckReport.executeLinkCheck(LinkcheckReport.java:430)
at
org.apache.maven.plugins.linkcheck.LinkcheckReport.execute(LinkcheckReport.java:285)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
... 12 more
{code}
Looks like the injected LinkCheck in
https://github.com/apache/maven-plugins/blob/a3f8da79c8d050001524f7ea993c541bc4f79b0e/maven-linkcheck-plugin/src/main/java/org/apache/maven/plugins/linkcheck/LinkcheckReport.java#L74
(which evaluates to a DefaultLinkCheck:
https://github.com/apache/maven-doxia-tools/blob/doxia-tools-1.2/doxia-linkcheck/src/main/java/org/apache/maven/doxia/linkcheck/DefaultLinkCheck.java#L65)
is not thread-safe.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MLINKCHECK-26) Linkcheck does not support parrallel builds
[
https://issues.apache.org/jira/browse/MLINKCHECK-26?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15422730#comment-15422730
]
Daniel Wegener commented on MLINKCHECK-26:
--
Probably the reason:
https://github.com/apache/maven-doxia-tools/blob/doxia-tools-1.2/doxia-linkcheck/src/main/java/org/apache/maven/doxia/linkcheck/LinkMatcher.java#L54
Hey, but at least we saved an object allocation! ¯\(ツ)/¯
> Linkcheck does not support parrallel builds
> ---
>
> Key: MLINKCHECK-26
> URL: https://issues.apache.org/jira/browse/MLINKCHECK-26
> Project: Maven Linkcheck Plugin
> Issue Type: Bug
>Reporter: Daniel Wegener
>
> Running multi-module-builds in parallel where multiple modules use the
> linkcheck plugin can trigger the following exception.
> {code}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-linkcheck-plugin:1.2:linkcheck (run-linkcheck)
> on project foo.documentation.arc: Execution run-linkcheck of goal
> org.apache.maven.plugins:maven-linkcheck-plugin:1.2:linkcheck failed.
> ConcurrentModificationException -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-linkcheck-plugin:1.2:linkcheck
> (run-linkcheck) on project foo.documentation.arc: Execution run-linkcheck of
> goal org.apache.maven.plugins:maven-linkcheck-plugin:1.2:linkcheck failed.
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:212)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
> at
> org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call(MultiThreadedBuilder.java:185)
> at
> org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call(MultiThreadedBuilder.java:181)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: org.apache.maven.plugin.PluginExecutionException: Execution
> run-linkcheck of goal
> org.apache.maven.plugins:maven-linkcheck-plugin:1.2:linkcheck failed.
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:145)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:207)
> ... 11 more
> Caused by: java.util.ConcurrentModificationException
> at java.util.TreeMap$PrivateEntryIterator.nextEntry(TreeMap.java:1207)
> at java.util.TreeMap$KeyIterator.next(TreeMap.java:1261)
> at
> org.apache.maven.doxia.linkcheck.DefaultLinkCheck.check(DefaultLinkCheck.java:505)
> at
> org.apache.maven.doxia.linkcheck.DefaultLinkCheck.checkFile(DefaultLinkCheck.java:447)
> at
> org.apache.maven.doxia.linkcheck.DefaultLinkCheck.findAndCheckFiles(DefaultLinkCheck.java:423)
> at
> org.apache.maven.doxia.linkcheck.DefaultLinkCheck.execute(DefaultLinkCheck.java:232)
> at
> org.apache.maven.plugins.linkcheck.LinkcheckReport.executeLinkCheck(LinkcheckReport.java:430)
> at
> org.apache.maven.plugins.linkcheck.LinkcheckReport.execute(LinkcheckReport.java:285)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
> ... 12 more
> {code}
> Looks like the injected LinkCheck in
> https://github.com/apache/maven-plugins/blob/a3f8da79c8d050001524f7ea993c541bc4f79b0e/maven-linkcheck-plugin/src/main/java/org/apache/maven/plugins/linkcheck/LinkcheckReport.java#L74
> (which evaluates to a DefaultLinkCheck:
> https://github.com/apache/maven-doxia-tools/blob/doxia-tools-1.2/doxia-linkcheck/src/main/java/org/apache/maven/doxia/linkcheck/DefaultLinkCheck.java#L65)
> is not thread-safe.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (DOXIATOOLS-54) LinkMatcher uses a singleton set
Daniel Wegener created DOXIATOOLS-54: Summary: LinkMatcher uses a singleton set Key: DOXIATOOLS-54 URL: https://issues.apache.org/jira/browse/DOXIATOOLS-54 Project: Maven Doxia Tools Issue Type: Bug Reporter: Daniel Wegener LinkMatcher.match() (https://github.com/apache/maven-doxia-tools/blob/562f0e6c6cbca49190e97e6923910220f7be4be8/doxia-linkcheck/src/main/java/org/apache/maven/doxia/linkcheck/LinkMatcher.java#L54) is not thread-safe and causes the maven-linkcheck-plugin to fail if used in parallel builds. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (WAGON-461) URL string not properly encoded by webdav
[
https://issues.apache.org/jira/browse/WAGON-461?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15422774#comment-15422774
]
Michael Osipov commented on WAGON-461:
--
Please read [this|https://hc.apache.org/httpcomponents-client-ga/logging.html].
It will guide you how to enable logging on the HttpClient. We can tackle the
issue down here. The quirk must be somewhere.
> URL string not properly encoded by webdav
> -
>
> Key: WAGON-461
> URL: https://issues.apache.org/jira/browse/WAGON-461
> Project: Maven Wagon
> Issue Type: Bug
> Components: wagon-webdav
>Affects Versions: 2.10
> Environment: All
>Reporter: Mike Summers
>
> wagon-webdav is not calling EncodingUtil prior to instantiating MkColMethod
> which results in
> {code:java}
> Caused by: java.lang.IllegalArgumentException: Invalid uri
> 'https://snafu.sharefile-webdav.com/Shared Folders/Fit - Expert
> Services/IBM/': escaped absolute path not valid
> {code}
> when there are special characters in the URI string.
> Changing line 153 of org.apache.maven.wagon.providers.webdav.WebDavWagon from
> {code:java}
> method = new MkColMethod( url );
> {code}
> to
> {code:java}
> method = new MkColMethod( EncodingUtil.encodeURLToString( url ) );
> {code}
> solves the issue although you may want to fix it elsewhere in the flow.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MNG-6080) New scope for non-functional dependencies
[
https://issues.apache.org/jira/browse/MNG-6080?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15422889#comment-15422889
]
Paul Benedict commented on MNG-6080:
How about a little of both? It needs to be not in the output like {{provided}}
but transitive like {{compile}}.
> New scope for non-functional dependencies
> -
>
> Key: MNG-6080
> URL: https://issues.apache.org/jira/browse/MNG-6080
> Project: Maven
> Issue Type: New Feature
> Components: Dependencies
>Affects Versions: 3.3.9
>Reporter: Paul Benedict
>Assignee: Paul Benedict
>Priority: Critical
>
> Maven currently lacks a scope for artifacts that should not be part of the
> classpath. The classpath is the path that the Java Runtime Environment (JRE)
> searches for classes and other resource files. Given that the classpath is
> Java specific, this feature request can be generalized to accommodate
> artifacts that are not code related (directly or indirectly). It is neither
> code that executes (like a .class file = "directly") nor a resource file
> intimately linked to executable code (like a .properties file = "indirectly").
> For example, an organization may with to establish a Maven project that
> contains common look-and-feel elements to brand all their web applications.
> This project could be a ZIP archive to be included in downstream projects, in
> which each build explodes the archive into their respective web application
> context roots.
> Two names in the running for the new scope are {{"asset"}} and {{"reactor"}}.
> They are nearly equal but have a different slight emphasis. The {{"asset"}}
> name emphasizes purpose of artifact. The {{"reactor"}} name emphasizes
> purpose within the build. The Maven Team should decide among these two or
> propose a third.
> Thread where discussion originated:
> http://mail-archives.apache.org/mod_mbox/maven-dev/201608.mbox/%3CCABLGb9x5e3fE25Qj9DwvCsCSa1Dwe_e6%2BOmWjL0ZbQ07HLEm8g%40mail.gmail.com%3E
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (SUREFIRE-1264) Some tests can be lost when running in parallel with parameterized tests
[
https://issues.apache.org/jira/browse/SUREFIRE-1264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15422967#comment-15422967
]
Jean-Luc Derrien edited comment on SUREFIRE-1264 at 8/16/16 4:16 PM:
-
[~tibor17], I've modified my branch
[simple-1|https://github.com/jderrien/surefire-junit-tests/tree/simple-1]
accordingly.
I still reproduce the problem with {{ConcurrentLinkedQueue}}. It seems to be a
reporting error since all the 12 files are created even when the output reports
11 tests:
{noformat}
---
T E S T S
---
Running [p2]
com.appnexus.viewability.core.surefireJunitTests.ATest.methodA1[p1] - p1 -
sleeptime = 2 => start
com.appnexus.viewability.core.surefireJunitTests.ATest.methodA1[p0] - p0 -
sleeptime = 5 => start
com.appnexus.viewability.core.surefireJunitTests.ATest.methodA1[p2] - p2 -
sleeptime = 1 => start
Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.007 sec - in
[p2]
Running [p2]
Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.012 sec - in
[p2]
Results :
Tests run: 11, Failures: 0, Errors: 0, Skipped: 0
[INFO]
[INFO] BUILD SUCCESS
[INFO]
[INFO] Total time: 7.315 s
[INFO] Finished at: 2016-08-16T18:06:26+02:00
[INFO] Final Memory: 16M/168M
[INFO]
{noformat}
{noformat}
$ ls target/*.log
target/com.appnexus.viewability.core.surefireJunitTests.ATest.methodA1[p0].log
target/com.appnexus.viewability.core.surefireJunitTests.ATest.methodA1[p1].log
target/com.appnexus.viewability.core.surefireJunitTests.ATest.methodA1[p2].log
target/com.appnexus.viewability.core.surefireJunitTests.ATest.methodA2[p0].log
target/com.appnexus.viewability.core.surefireJunitTests.ATest.methodA2[p1].log
target/com.appnexus.viewability.core.surefireJunitTests.ATest.methodA2[p2].log
target/com.appnexus.viewability.core.surefireJunitTests.BTest.methodB1[p0].log
target/com.appnexus.viewability.core.surefireJunitTests.BTest.methodB1[p1].log
target/com.appnexus.viewability.core.surefireJunitTests.BTest.methodB1[p2].log
target/com.appnexus.viewability.core.surefireJunitTests.BTest.methodB2[p0].log
target/com.appnexus.viewability.core.surefireJunitTests.BTest.methodB2[p1].log
target/com.appnexus.viewability.core.surefireJunitTests.BTest.methodB2[p2].log
{noformat}
Note: I also reproduce the problem on Linux with different version of Java and
Maven:
{noformat}
$ mvn --version
Warning: JAVA_HOME environment variable is not set.
Apache Maven 2.2.1 (r801777; 2009-08-06 21:16:01+0200)
Java version: 1.7.0_95
Java home: /usr/lib/jvm/java-7-openjdk-amd64/jre
Default locale: en_GB, platform encoding: UTF-8
OS name: "linux" version: "3.14.32--std-ipv6-64" arch: "amd64" Family:
"unix"
{noformat}
In this case, the output is slightly different (10 tests only, and the output
shows the {{=> stop}} logs correctly when the problem occurs, which is not the
case with my other setup):
{noformat}
---
T E S T S
---
Running [p2]
Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.004 sec - in
[p2]
Running [p2]
com.appnexus.viewability.core.surefireJunitTests.ATest.methodA1[p1] - p1 -
sleeptime = 2 => start
com.appnexus.viewability.core.surefireJunitTests.ATest.methodA1[p1] - p1 -
sleeptime = 2 => stop
com.appnexus.viewability.core.surefireJunitTests.ATest.methodA1[p0] - p0 -
sleeptime = 5 => start
com.appnexus.viewability.core.surefireJunitTests.ATest.methodA1[p0] - p0 -
sleeptime = 5 => stop
com.appnexus.viewability.core.surefireJunitTests.ATest.methodA1[p2] - p2 -
sleeptime = 1 => start
com.appnexus.viewability.core.surefireJunitTests.ATest.methodA1[p2] - p2 -
sleeptime = 1 => stop
Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 5.002 sec - in
[p2]
Results :
Tests run: 10, Failures: 0, Errors: 0, Skipped: 0
[INFO]
[INFO] BUILD SUCCESSFUL
[INFO]
[INFO] Total time: 7 seconds
[INFO] Finished at: Tue Aug 16 17:32:18 CEST 2016
[INFO] Final Memory: 30M/478M
[INFO]
{noformat}
was (Author: jderrien):
[~tibor17], I've modified my branch
[simple-1|https://github.com/jderrien/surefire-junit-tests/tree/simple-1]
accordingly.
I still reproduce the problem with {{ConcurrentLinkedQueue}}. It seems to be a
reporting error since all the 12 files are created even when the output reports
11 tests:
{noformat}
--
[jira] [Commented] (SUREFIRE-1264) Some tests can be lost when running in parallel with parameterized tests
[
https://issues.apache.org/jira/browse/SUREFIRE-1264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15422967#comment-15422967
]
Jean-Luc Derrien commented on SUREFIRE-1264:
[~tibor17], I've modified my branch
[simple-1|https://github.com/jderrien/surefire-junit-tests/tree/simple-1]
accordingly.
I still reproduce the problem with {{ConcurrentLinkedQueue}}. It seems to be a
reporting error since all the 12 files are created even when the output reports
11 tests:
{noformat}
---
T E S T S
---
Running [p2]
com.appnexus.viewability.core.surefireJunitTests.ATest.methodA1[p1] - p1 -
sleeptime = 2 => start
com.appnexus.viewability.core.surefireJunitTests.ATest.methodA1[p0] - p0 -
sleeptime = 5 => start
com.appnexus.viewability.core.surefireJunitTests.ATest.methodA1[p2] - p2 -
sleeptime = 1 => start
Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.007 sec - in
[p2]
Running [p2]
Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.012 sec - in
[p2]
Results :
Tests run: 11, Failures: 0, Errors: 0, Skipped: 0
[INFO]
[INFO] BUILD SUCCESS
[INFO]
[INFO] Total time: 7.315 s
[INFO] Finished at: 2016-08-16T18:06:26+02:00
[INFO] Final Memory: 16M/168M
[INFO]
{noformat}
{noformat}
$ ls target/*.log
target/com.appnexus.viewability.core.surefireJunitTests.ATest.methodA1[p0].log
target/com.appnexus.viewability.core.surefireJunitTests.ATest.methodA1[p1].log
target/com.appnexus.viewability.core.surefireJunitTests.ATest.methodA1[p2].log
target/com.appnexus.viewability.core.surefireJunitTests.ATest.methodA2[p0].log
target/com.appnexus.viewability.core.surefireJunitTests.ATest.methodA2[p1].log
target/com.appnexus.viewability.core.surefireJunitTests.ATest.methodA2[p2].log
target/com.appnexus.viewability.core.surefireJunitTests.BTest.methodB1[p0].log
target/com.appnexus.viewability.core.surefireJunitTests.BTest.methodB1[p1].log
target/com.appnexus.viewability.core.surefireJunitTests.BTest.methodB1[p2].log
target/com.appnexus.viewability.core.surefireJunitTests.BTest.methodB2[p0].log
target/com.appnexus.viewability.core.surefireJunitTests.BTest.methodB2[p1].log
target/com.appnexus.viewability.core.surefireJunitTests.BTest.methodB2[p2].log
{noformat}
Note: I also reproduce the problem on Linux with different version of Java and
Maven:
{noformat}
aiantis@s30:~/tmp/surefire-junit-tests$ mvn --version
Warning: JAVA_HOME environment variable is not set.
Apache Maven 2.2.1 (r801777; 2009-08-06 21:16:01+0200)
Java version: 1.7.0_95
Java home: /usr/lib/jvm/java-7-openjdk-amd64/jre
Default locale: en_GB, platform encoding: UTF-8
OS name: "linux" version: "3.14.32--std-ipv6-64" arch: "amd64" Family:
"unix"
{noformat}
In this case, the output is slightly different (10 tests only, and the output
shows the {{=> stop}} logs correctly when the problem occurs, which is not the
case with my other setup):
{noformat}
---
T E S T S
---
Running [p2]
Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.004 sec - in
[p2]
Running [p2]
com.appnexus.viewability.core.surefireJunitTests.ATest.methodA1[p1] - p1 -
sleeptime = 2 => start
com.appnexus.viewability.core.surefireJunitTests.ATest.methodA1[p1] - p1 -
sleeptime = 2 => stop
com.appnexus.viewability.core.surefireJunitTests.ATest.methodA1[p0] - p0 -
sleeptime = 5 => start
com.appnexus.viewability.core.surefireJunitTests.ATest.methodA1[p0] - p0 -
sleeptime = 5 => stop
com.appnexus.viewability.core.surefireJunitTests.ATest.methodA1[p2] - p2 -
sleeptime = 1 => start
com.appnexus.viewability.core.surefireJunitTests.ATest.methodA1[p2] - p2 -
sleeptime = 1 => stop
Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 5.002 sec - in
[p2]
Results :
Tests run: 10, Failures: 0, Errors: 0, Skipped: 0
[INFO]
[INFO] BUILD SUCCESSFUL
[INFO]
[INFO] Total time: 7 seconds
[INFO] Finished at: Tue Aug 16 17:32:18 CEST 2016
[INFO] Final Memory: 30M/478M
[INFO]
{noformat}
> Some tests can be lost when running in parallel with parameterized tests
>
>
> Key: SUREFIRE-1264
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1264
> Project: Maven Surefire
> Issue Type: Bug
> Compone
[jira] [Commented] (SUREFIRE-1263) No class name in log when running tests in parallel with parameterized tests
[
https://issues.apache.org/jira/browse/SUREFIRE-1263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15423003#comment-15423003
]
Jean-Luc Derrien commented on SUREFIRE-1263:
Yes, exactly.
I've launched the test, the output is correct:
{noformat}
jderrien:surefire-1082-parallel-junit-parameterized(master u=) jderrien$ mvn
test -Dsurefire.version=2.19.1
[INFO] Scanning for projects...
[INFO]
[INFO]
[INFO] Building jiras-surefire-1082 1.0
[INFO]
[INFO]
[INFO] --- maven-resources-plugin:2.6:resources (default-resources) @
jiras-surefire-1082 ---
[WARNING] Using platform encoding (UTF-8 actually) to copy filtered resources,
i.e. build is platform dependent!
[INFO] skip non existing resourceDirectory
/Users/jderrien/projects/maven-surefire/surefire-integration-tests/src/test/resources/surefire-1082-parallel-junit-parameterized/src/main/resources
[INFO]
[INFO] --- maven-compiler-plugin:2.5.1:compile (default-compile) @
jiras-surefire-1082 ---
[INFO] No sources to compile
[INFO]
[INFO] --- maven-resources-plugin:2.6:testResources (default-testResources) @
jiras-surefire-1082 ---
[WARNING] Using platform encoding (UTF-8 actually) to copy filtered resources,
i.e. build is platform dependent!
[INFO] skip non existing resourceDirectory
/Users/jderrien/projects/maven-surefire/surefire-integration-tests/src/test/resources/surefire-1082-parallel-junit-parameterized/src/test/resources
[INFO]
[INFO] --- maven-compiler-plugin:2.5.1:testCompile (default-testCompile) @
jiras-surefire-1082 ---
[INFO] Nothing to compile - all classes are up to date
[INFO]
[INFO] --- maven-surefire-plugin:2.19.1:test (default-test) @
jiras-surefire-1082 ---
[WARNING] The parameter forkMode is deprecated since version 2.14. Use
forkCount and reuseForks instead.
[WARNING] useSystemClassloader setting has no effect when not forking
Running jiras.surefire1082.Jira1082Test
class jiras.surefire1082.Jira1082Test a 0 main
class jiras.surefire1082.Jira1082Test b 0 main
class jiras.surefire1082.Jira1082Test a 1 main
class jiras.surefire1082.Jira1082Test b 1 main
Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 2.041 sec - in
jiras.surefire1082.Jira1082Test
Results :
Tests run: 4, Failures: 0, Errors: 0, Skipped: 0
[INFO]
[INFO] BUILD SUCCESS
[INFO]
[INFO] Total time: 3.091 s
[INFO] Finished at: 2016-08-16T18:16:45+02:00
[INFO] Final Memory: 9M/155M
[INFO]
{noformat}
I should be able to dig a bit more into tomorrow. I'll post what I find.
> No class name in log when running tests in parallel with parameterized tests
>
>
> Key: SUREFIRE-1263
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1263
> Project: Maven Surefire
> Issue Type: Bug
> Components: Junit 4.7+ (parallel) support
>Affects Versions: 2.19.1
>Reporter: Jean-Luc Derrien
>
> Hello,
> Using surefire and Junit, the class names are not displayed in the output log
> when the tests are run in parallel with parameterized tests.
> According to this [small
> project|https://github.com/jderrien/surefire-junit-tests/tree/simple-1], in
> parallel mode:
> {noformat}
> ---
> T E S T S
> ---
> Running [p2]
> com.appnexus.viewability.core.surefireJunitTests.ATest.methodA1[p2] - p2 -
> sleeptime = 1 => start
> com.appnexus.viewability.core.surefireJunitTests.ATest.methodA1[p2] - p2 -
> sleeptime = 1 => stop
> com.appnexus.viewability.core.surefireJunitTests.ATest.methodA1[p1] - p1 -
> sleeptime = 2 => start
> com.appnexus.viewability.core.surefireJunitTests.ATest.methodA1[p1] - p1 -
> sleeptime = 2 => stop
> com.appnexus.viewability.core.surefireJunitTests.ATest.methodA1[p0] - p0 -
> sleeptime = 5 => start
> com.appnexus.viewability.core.surefireJunitTests.ATest.methodA1[p0] - p0 -
> sleeptime = 5 => stop
> Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 5.006 sec -
> in [p2]
> Running [p2]
> Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.011 sec -
> in [p2]
> Results :
> Tests run: 12, Failures: 0, Errors: 0, Skipped: 0
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> [INFO] Total time: 7.799 s
> [INFO] Finished at: 2016-07-27T15:03:37+02:00
> [INFO] Final Memory: 18M/213M
> [I
[jira] [Assigned] (MDEP-537) Goal purge-local-repository requires a Maven project, even with manualIncludes
[
https://issues.apache.org/jira/browse/MDEP-537?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Boué reassigned MDEP-537:
---
Assignee: Guillaume Boué
> Goal purge-local-repository requires a Maven project, even with manualIncludes
> --
>
> Key: MDEP-537
> URL: https://issues.apache.org/jira/browse/MDEP-537
> Project: Maven Dependency Plugin
> Issue Type: Improvement
> Components: purge-local-repository
>Affects Versions: 2.10
>Reporter: Guillaume Boué
>Assignee: Guillaume Boué
>Priority: Minor
>
> Triggered by the Stack Overflow question [Can I remove jar from local
> repository without pom.xml?|http://stackoverflow.com/q/38973960/1743880].
> The goal {{purge-local-repository}} requires a Maven project to be executed,
> but it also accepts a
> [{{manualInclude}}|http://maven.apache.org/plugins/maven-dependency-plugin/purge-local-repository-mojo.html#manualInclude]
> parameter, which bypasses the purge of project dependencies and only removes
> the ones specified. Therefore, the plugin should be updated to remove the
> requirement of a MavenProject.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MDEP-537) Goal purge-local-repository requires a Maven project, even with manualIncludes
[
https://issues.apache.org/jira/browse/MDEP-537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15423253#comment-15423253
]
Guillaume Boué commented on MDEP-537:
-
Fixed in [r1756544|http://svn.apache.org/viewvc?view=revision&revision=1756544].
> Goal purge-local-repository requires a Maven project, even with manualIncludes
> --
>
> Key: MDEP-537
> URL: https://issues.apache.org/jira/browse/MDEP-537
> Project: Maven Dependency Plugin
> Issue Type: Improvement
> Components: purge-local-repository
>Affects Versions: 2.10
>Reporter: Guillaume Boué
>Priority: Minor
>
> Triggered by the Stack Overflow question [Can I remove jar from local
> repository without pom.xml?|http://stackoverflow.com/q/38973960/1743880].
> The goal {{purge-local-repository}} requires a Maven project to be executed,
> but it also accepts a
> [{{manualInclude}}|http://maven.apache.org/plugins/maven-dependency-plugin/purge-local-repository-mojo.html#manualInclude]
> parameter, which bypasses the purge of project dependencies and only removes
> the ones specified. Therefore, the plugin should be updated to remove the
> requirement of a MavenProject.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MDEP-537) Goal purge-local-repository requires a Maven project, even with manualIncludes
[
https://issues.apache.org/jira/browse/MDEP-537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15423278#comment-15423278
]
Hudson commented on MDEP-537:
-
SUCCESS: Integrated in Jenkins build maven-plugins #7166 (See
[https://builds.apache.org/job/maven-plugins/7166/])
[MDEP-537] Goal purge-local-repository requires a Maven project, even with
manualIncludes
The goal purge-local-repository does not require a Maven project to be
executed, since it can be configured to remove dependencies given manually.
(gboue: [http://svn.apache.org/viewvc/?view=rev&rev=1756544])
* (edit) maven-dependency-plugin/pom.xml
* (add)
maven-dependency-plugin/src/it/projects/purge-local-repository-without-pom
* (add)
maven-dependency-plugin/src/it/projects/purge-local-repository-without-pom/invoker.properties
* (add)
maven-dependency-plugin/src/it/projects/purge-local-repository-without-pom/setup.bsh
* (add)
maven-dependency-plugin/src/it/projects/purge-local-repository-without-pom/test.properties
* (add)
maven-dependency-plugin/src/it/projects/purge-local-repository-without-pom/verify.bsh
* (edit)
maven-dependency-plugin/src/main/java/org/apache/maven/plugins/dependency/PurgeLocalRepositoryMojo.java
> Goal purge-local-repository requires a Maven project, even with manualIncludes
> --
>
> Key: MDEP-537
> URL: https://issues.apache.org/jira/browse/MDEP-537
> Project: Maven Dependency Plugin
> Issue Type: Improvement
> Components: purge-local-repository
>Affects Versions: 2.10
>Reporter: Guillaume Boué
>Assignee: Guillaume Boué
>Priority: Minor
>
> Triggered by the Stack Overflow question [Can I remove jar from local
> repository without pom.xml?|http://stackoverflow.com/q/38973960/1743880].
> The goal {{purge-local-repository}} requires a Maven project to be executed,
> but it also accepts a
> [{{manualInclude}}|http://maven.apache.org/plugins/maven-dependency-plugin/purge-local-repository-mojo.html#manualInclude]
> parameter, which bypasses the purge of project dependencies and only removes
> the ones specified. Therefore, the plugin should be updated to remove the
> requirement of a MavenProject.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (MDEP-537) Goal purge-local-repository requires a Maven project, even with manualIncludes
[
https://issues.apache.org/jira/browse/MDEP-537?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Boué closed MDEP-537.
---
Resolution: Fixed
Fix Version/s: 3.0
> Goal purge-local-repository requires a Maven project, even with manualIncludes
> --
>
> Key: MDEP-537
> URL: https://issues.apache.org/jira/browse/MDEP-537
> Project: Maven Dependency Plugin
> Issue Type: Improvement
> Components: purge-local-repository
>Affects Versions: 2.10
>Reporter: Guillaume Boué
>Assignee: Guillaume Boué
>Priority: Minor
> Fix For: 3.0
>
>
> Triggered by the Stack Overflow question [Can I remove jar from local
> repository without pom.xml?|http://stackoverflow.com/q/38973960/1743880].
> The goal {{purge-local-repository}} requires a Maven project to be executed,
> but it also accepts a
> [{{manualInclude}}|http://maven.apache.org/plugins/maven-dependency-plugin/purge-local-repository-mojo.html#manualInclude]
> parameter, which bypasses the purge of project dependencies and only removes
> the ones specified. Therefore, the plugin should be updated to remove the
> requirement of a MavenProject.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (WAGON-461) URL string not properly encoded by webdav
[
https://issues.apache.org/jira/browse/WAGON-461?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Summers updated WAGON-461:
---
Attachment: logs.zip
Log files for both encoded (in pom) and unencoded URLs.
log settings:
{code:java}
org.slf4j.simpleLogger.defaultLogLevel=warn
org.slf4j.simpleLogger.showDateTime=false
org.slf4j.simpleLogger.showThreadName=false
org.slf4j.simpleLogger.showLogName=true
org.slf4j.simpleLogger.logFile=System.out
org.slf4j.simpleLogger.levelInBrackets=true
org.slf4j.simpleLogger.log.Sisu=debug
org.slf4j.simpleLogger.warnLevelString=WARNING
org.slf4j.simpleLogger.log.org.apache.http=trace
org.slf4j.simpleLogger.log.org.apache.http.wire=error
org.slf4j.simpleLogger.log.org.apache.commons.httpclient=trace
org.slf4j.simpleLogger.log.org.apache.commons.httpclient.wire=error
org.slf4j.simpleLogger.log.org.apache.jackrabbit=trace
org.slf4j.simpleLogger.log.org.apache.maven.wagon=trace
{code}
> URL string not properly encoded by webdav
> -
>
> Key: WAGON-461
> URL: https://issues.apache.org/jira/browse/WAGON-461
> Project: Maven Wagon
> Issue Type: Bug
> Components: wagon-webdav
>Affects Versions: 2.10
> Environment: All
>Reporter: Mike Summers
> Attachments: logs.zip
>
>
> wagon-webdav is not calling EncodingUtil prior to instantiating MkColMethod
> which results in
> {code:java}
> Caused by: java.lang.IllegalArgumentException: Invalid uri
> 'https://snafu.sharefile-webdav.com/Shared Folders/Fit - Expert
> Services/IBM/': escaped absolute path not valid
> {code}
> when there are special characters in the URI string.
> Changing line 153 of org.apache.maven.wagon.providers.webdav.WebDavWagon from
> {code:java}
> method = new MkColMethod( url );
> {code}
> to
> {code:java}
> method = new MkColMethod( EncodingUtil.encodeURLToString( url ) );
> {code}
> solves the issue although you may want to fix it elsewhere in the flow.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MNG-6080) New scope for non-functional dependencies
[
https://issues.apache.org/jira/browse/MNG-6080?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15423363#comment-15423363
]
Michael Osipov commented on MNG-6080:
-
Probably. Doesn't {{provided}} work in your case?
> New scope for non-functional dependencies
> -
>
> Key: MNG-6080
> URL: https://issues.apache.org/jira/browse/MNG-6080
> Project: Maven
> Issue Type: New Feature
> Components: Dependencies
>Affects Versions: 3.3.9
>Reporter: Paul Benedict
>Assignee: Paul Benedict
>Priority: Critical
>
> Maven currently lacks a scope for artifacts that should not be part of the
> classpath. The classpath is the path that the Java Runtime Environment (JRE)
> searches for classes and other resource files. Given that the classpath is
> Java specific, this feature request can be generalized to accommodate
> artifacts that are not code related (directly or indirectly). It is neither
> code that executes (like a .class file = "directly") nor a resource file
> intimately linked to executable code (like a .properties file = "indirectly").
> For example, an organization may with to establish a Maven project that
> contains common look-and-feel elements to brand all their web applications.
> This project could be a ZIP archive to be included in downstream projects, in
> which each build explodes the archive into their respective web application
> context roots.
> Two names in the running for the new scope are {{"asset"}} and {{"reactor"}}.
> They are nearly equal but have a different slight emphasis. The {{"asset"}}
> name emphasizes purpose of artifact. The {{"reactor"}} name emphasizes
> purpose within the build. The Maven Team should decide among these two or
> propose a third.
> Thread where discussion originated:
> http://mail-archives.apache.org/mod_mbox/maven-dev/201608.mbox/%3CCABLGb9x5e3fE25Qj9DwvCsCSa1Dwe_e6%2BOmWjL0ZbQ07HLEm8g%40mail.gmail.com%3E
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (WAGON-461) URL string not properly encoded by webdav
[
https://issues.apache.org/jira/browse/WAGON-461?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15423379#comment-15423379
]
Michael Osipov commented on WAGON-461:
--
Thanks for the log files. They help a lot. The first thing I see is that
{{Jakarta Commons-HttpClient/3.1}} is used. If you take a closer look at the
[dependencies
list|http://www.mojohaus.org/wagon-maven-plugin/dependencies.html#Project_Transitive_Dependencies_runtime]
of the plugin, you see that all dependencies are horribly old. Wagon is now at
2.10, Jackrabbit at 2.2.
Before doing any further analysis, one needs to upgrade Maven Wagon first.
Clone from the plugin's Git repo and try to upgrade Wagon manually and test.
Open an issue for upgrading it. Hopefully, there aren't any interface/ABI
changes.
> URL string not properly encoded by webdav
> -
>
> Key: WAGON-461
> URL: https://issues.apache.org/jira/browse/WAGON-461
> Project: Maven Wagon
> Issue Type: Bug
> Components: wagon-webdav
>Affects Versions: 2.10
> Environment: All
>Reporter: Mike Summers
> Attachments: logs.zip
>
>
> wagon-webdav is not calling EncodingUtil prior to instantiating MkColMethod
> which results in
> {code:java}
> Caused by: java.lang.IllegalArgumentException: Invalid uri
> 'https://snafu.sharefile-webdav.com/Shared Folders/Fit - Expert
> Services/IBM/': escaped absolute path not valid
> {code}
> when there are special characters in the URI string.
> Changing line 153 of org.apache.maven.wagon.providers.webdav.WebDavWagon from
> {code:java}
> method = new MkColMethod( url );
> {code}
> to
> {code:java}
> method = new MkColMethod( EncodingUtil.encodeURLToString( url ) );
> {code}
> solves the issue although you may want to fix it elsewhere in the flow.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (ARCHETYPE-455) Flexible Modulename
[
https://issues.apache.org/jira/browse/ARCHETYPE-455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15423767#comment-15423767
]
James Roper commented on ARCHETYPE-455:
---
I was thinking... I know, I could do my part and implement this myself! Then I
saw a patch was already attached 3 years ago, with no review or response from
the maintainers in that time. Willingness to contribute to this open source
project is futile.
> Flexible Modulename
> ---
>
> Key: ARCHETYPE-455
> URL: https://issues.apache.org/jira/browse/ARCHETYPE-455
> Project: Maven Archetype
> Issue Type: Wish
> Components: Generator
>Reporter: Michael Kopf
> Attachments: archetype-common-flex-module-name.patch,
> archetype-multi-module-project-1.1.jar
>
>
> I have to create a multi-module project from maven-archetype with free
> configurable modulenames. This should be possible with required properties in
> the archetype.
> Up to now this is only possible with artifactId or rootArtifactId and you
> have to use it in form of prefix__rootArtifactId__postfix for the module
> directory.
> What I want is to set a required property while setting up the new project
> with the archetype. Within the archetype you have to configure the module
> with directory __yourproperty__ and in the archetype-metadata.xml the module
> entry like as follows:
> {code}
>
> {code}
> I made a patch which works for me.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SUREFIRE-323) Running a single test using -Dtest has no effect
[
https://issues.apache.org/jira/browse/SUREFIRE-323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15424003#comment-15424003
]
Jin Kwon commented on SUREFIRE-323:
---
And {{-Dit.test=}} also doesn't do anything at all
> Running a single test using -Dtest has no effect
>
>
> Key: SUREFIRE-323
> URL: https://issues.apache.org/jira/browse/SUREFIRE-323
> Project: Maven Surefire
> Issue Type: Bug
>Affects Versions: 2.3
> Environment: java version "1.5.0_09"
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_09-b01)
> Java HotSpot(TM) 64-Bit Server VM (build 1.5.0_09-b01, mixed mode)
>Reporter: Graham Leggett
>Assignee: Brett Porter
>
> Using the -D option from the command line to run a test as per the
> instructions at
> http://maven.apache.org/plugins/maven-surefire-plugin/examples/single-test.html,
> the test is ignored.
> The test is not configured within the pom, because the test should only be
> run by hand, not as part of the build. Thus the need to run the test on its
> own.
> bash-3.00$ mvn -Dtest=**/*TestConcurrency test
> [INFO] Scanning for projects...
> [INFO]
>
> [INFO] Building Alchemy Measure
> [INFO]task-segment: [test]
> [INFO]
>
> [INFO] [resources:resources]
> [INFO] Using default encoding to copy filtered resources.
> [INFO] [compiler:compile]
> [INFO] Nothing to compile - all classes are up to date
> [INFO] [resources:testResources]
> [INFO] Using default encoding to copy filtered resources.
> [INFO] [compiler:testCompile]
> [INFO] No sources to compile
> [INFO] [surefire:test]
> [INFO] No tests to run.
> The following command line options also do not work:
> bash-3.00$ mvn -Dtest=TestConcurrency test
> [INFO] Scanning for projects...
> [INFO]
>
> [INFO] Building Alchemy Measure
> [INFO]task-segment: [test]
> [INFO]
>
> [INFO] [resources:resources]
> [INFO] Using default encoding to copy filtered resources.
> [INFO] [compiler:compile]
> [INFO] Nothing to compile - all classes are up to date
> [INFO] [resources:testResources]
> [INFO] Using default encoding to copy filtered resources.
> [INFO] [compiler:testCompile]
> [INFO] No sources to compile
> [INFO] [surefire:test]
> [INFO] No tests to run.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
