date:20161012

[jira] [Commented] (SUREFIRE-1293) Simplify org.apache.maven.plugin.surefire.report.TestSetRunListener by using the null object pattern

2016-10-12 Thread ASF GitHub Bot (JIRA)


[ 
https://issues.apache.org/jira/browse/SUREFIRE-1293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15568182#comment-15568182
 ] 

ASF GitHub Bot commented on SUREFIRE-1293:
--

Github user Tibor17 commented on the issue:

https://github.com/apache/maven-surefire/pull/127
  
@britter 
Done


> Simplify org.apache.maven.plugin.surefire.report.TestSetRunListener by using 
> the null object pattern
> 
>
> Key: SUREFIRE-1293
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1293
> Project: Maven Surefire
>  Issue Type: Improvement
>  Components: Maven Surefire Plugin
>Reporter: Benedikt Ritter
>  Labels: github
> Fix For: 2.19.2
>
>
> The class org.apache.maven.plugin.surefire.report.TestSetRunListener has a 
> lot of checks like this:
> {code:java}
> if( field != null )
> {
> // do something with field
> }
> {code}
> This can be simplified by providing fallback implementations for the fields 
> being used by TestSetRunListener.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (SUREFIRE-1293) Simplify org.apache.maven.plugin.surefire.report.TestSetRunListener by using the null object pattern

2016-10-12 Thread Tibor Digana (JIRA)


 [ 
https://issues.apache.org/jira/browse/SUREFIRE-1293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tibor Digana reassigned SUREFIRE-1293:
--

Assignee: Tibor Digana

> Simplify org.apache.maven.plugin.surefire.report.TestSetRunListener by using 
> the null object pattern
> 
>
> Key: SUREFIRE-1293
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1293
> Project: Maven Surefire
>  Issue Type: Improvement
>  Components: Maven Surefire Plugin
>Reporter: Benedikt Ritter
>Assignee: Tibor Digana
>  Labels: github
> Fix For: 2.19.2
>
>
> The class org.apache.maven.plugin.surefire.report.TestSetRunListener has a 
> lot of checks like this:
> {code:java}
> if( field != null )
> {
> // do something with field
> }
> {code}
> This can be simplified by providing fallback implementations for the fields 
> being used by TestSetRunListener.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SUREFIRE-1293) Simplify org.apache.maven.plugin.surefire.report.TestSetRunListener by using the null object pattern

2016-10-12 Thread ASF GitHub Bot (JIRA)


[ 
https://issues.apache.org/jira/browse/SUREFIRE-1293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15568397#comment-15568397
 ] 

ASF GitHub Bot commented on SUREFIRE-1293:
--

Github user britter closed the pull request at:

https://github.com/apache/maven-surefire/pull/127


> Simplify org.apache.maven.plugin.surefire.report.TestSetRunListener by using 
> the null object pattern
> 
>
> Key: SUREFIRE-1293
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1293
> Project: Maven Surefire
>  Issue Type: Improvement
>  Components: Maven Surefire Plugin
>Reporter: Benedikt Ritter
>Assignee: Tibor Digana
>  Labels: github
> Fix For: 2.19.2
>
>
> The class org.apache.maven.plugin.surefire.report.TestSetRunListener has a 
> lot of checks like this:
> {code:java}
> if( field != null )
> {
> // do something with field
> }
> {code}
> This can be simplified by providing fallback implementations for the fields 
> being used by TestSetRunListener.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SUREFIRE-1293) Simplify org.apache.maven.plugin.surefire.report.TestSetRunListener by using the null object pattern

2016-10-12 Thread Hudson (JIRA)


[ 
https://issues.apache.org/jira/browse/SUREFIRE-1293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15568415#comment-15568415
 ] 

Hudson commented on SUREFIRE-1293:
--

UNSTABLE: Integrated in Jenkins build maven-surefire #1638 (See 
[https://builds.apache.org/job/maven-surefire/1638/])
[SUREFIRE-1293] Simplify (tibor17: rev fd9f6e5598e7ce6cdb4168ce15cf6ca138b7753f)
* (add) 
maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/report/NullStatelessXmlReporter.java
* (add) 
maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/report/NullConsoleReporter.java
* (edit) 
maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/runorder/StatisticsReporter.java
* (edit) 
maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/report/DefaultReporterFactory.java
* (add) 
maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/report/NullFileReporter.java
* (add) 
maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/report/NullConsoleOutputReceiver.java
* (add) 
maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/report/NullStatisticsReporter.java
* (edit) 
maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/report/TestSetRunListener.java


> Simplify org.apache.maven.plugin.surefire.report.TestSetRunListener by using 
> the null object pattern
> 
>
> Key: SUREFIRE-1293
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1293
> Project: Maven Surefire
>  Issue Type: Improvement
>  Components: Maven Surefire Plugin
>Reporter: Benedikt Ritter
>Assignee: Tibor Digana
>  Labels: github
> Fix For: 2.19.2
>
>
> The class org.apache.maven.plugin.surefire.report.TestSetRunListener has a 
> lot of checks like this:
> {code:java}
> if( field != null )
> {
> // do something with field
> }
> {code}
> This can be simplified by providing fallback implementations for the fields 
> being used by TestSetRunListener.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SUREFIRE-1293) Simplify org.apache.maven.plugin.surefire.report.TestSetRunListener by using the null object pattern

2016-10-12 Thread Tibor Digana (JIRA)


[ 
https://issues.apache.org/jira/browse/SUREFIRE-1293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15568423#comment-15568423
 ] 

Tibor Digana commented on SUREFIRE-1293:


commit fd9f6e5598e7ce6cdb4168ce15cf6ca138b7753f

> Simplify org.apache.maven.plugin.surefire.report.TestSetRunListener by using 
> the null object pattern
> 
>
> Key: SUREFIRE-1293
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1293
> Project: Maven Surefire
>  Issue Type: Improvement
>  Components: Maven Surefire Plugin
>Reporter: Benedikt Ritter
>Assignee: Tibor Digana
>  Labels: github
> Fix For: 2.19.2
>
>
> The class org.apache.maven.plugin.surefire.report.TestSetRunListener has a 
> lot of checks like this:
> {code:java}
> if( field != null )
> {
> // do something with field
> }
> {code}
> This can be simplified by providing fallback implementations for the fields 
> being used by TestSetRunListener.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SUREFIRE-1293) Simplify org.apache.maven.plugin.surefire.report.TestSetRunListener by using the null object pattern

2016-10-12 Thread ASF GitHub Bot (JIRA)


[ 
https://issues.apache.org/jira/browse/SUREFIRE-1293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15568422#comment-15568422
 ] 

ASF GitHub Bot commented on SUREFIRE-1293:
--

Github user Tibor17 commented on the issue:

https://github.com/apache/maven-surefire/pull/127
  
@britter 
The build failed [1]. Did you run a local build on your side?
[1] https://builds.apache.org/job/maven-surefire/1638/console


> Simplify org.apache.maven.plugin.surefire.report.TestSetRunListener by using 
> the null object pattern
> 
>
> Key: SUREFIRE-1293
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1293
> Project: Maven Surefire
>  Issue Type: Improvement
>  Components: Maven Surefire Plugin
>Reporter: Benedikt Ritter
>Assignee: Tibor Digana
>  Labels: github
> Fix For: 2.19.2
>
>
> The class org.apache.maven.plugin.surefire.report.TestSetRunListener has a 
> lot of checks like this:
> {code:java}
> if( field != null )
> {
> // do something with field
> }
> {code}
> This can be simplified by providing fallback implementations for the fields 
> being used by TestSetRunListener.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SUREFIRE-1293) Simplify org.apache.maven.plugin.surefire.report.TestSetRunListener by using the null object pattern

2016-10-12 Thread ASF GitHub Bot (JIRA)


[ 
https://issues.apache.org/jira/browse/SUREFIRE-1293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15568477#comment-15568477
 ] 

ASF GitHub Bot commented on SUREFIRE-1293:
--

Github user Tibor17 commented on the issue:

https://github.com/apache/maven-surefire/pull/127
  
@britter 
It seems you forgot to add `ASF commons` dependency.


> Simplify org.apache.maven.plugin.surefire.report.TestSetRunListener by using 
> the null object pattern
> 
>
> Key: SUREFIRE-1293
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1293
> Project: Maven Surefire
>  Issue Type: Improvement
>  Components: Maven Surefire Plugin
>Reporter: Benedikt Ritter
>Assignee: Tibor Digana
>  Labels: github
> Fix For: 2.19.2
>
>
> The class org.apache.maven.plugin.surefire.report.TestSetRunListener has a 
> lot of checks like this:
> {code:java}
> if( field != null )
> {
> // do something with field
> }
> {code}
> This can be simplified by providing fallback implementations for the fields 
> being used by TestSetRunListener.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SUREFIRE-1293) Simplify org.apache.maven.plugin.surefire.report.TestSetRunListener by using the null object pattern

2016-10-12 Thread ASF GitHub Bot (JIRA)


[ 
https://issues.apache.org/jira/browse/SUREFIRE-1293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15568636#comment-15568636
 ] 

ASF GitHub Bot commented on SUREFIRE-1293:
--

Github user britter commented on the issue:

https://github.com/apache/maven-surefire/pull/127
  
@Tibor17 I don't understand. `mvn clean compile` works. Why does this fail 
on Jenkins?


> Simplify org.apache.maven.plugin.surefire.report.TestSetRunListener by using 
> the null object pattern
> 
>
> Key: SUREFIRE-1293
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1293
> Project: Maven Surefire
>  Issue Type: Improvement
>  Components: Maven Surefire Plugin
>Reporter: Benedikt Ritter
>Assignee: Tibor Digana
>  Labels: github
> Fix For: 2.19.2
>
>
> The class org.apache.maven.plugin.surefire.report.TestSetRunListener has a 
> lot of checks like this:
> {code:java}
> if( field != null )
> {
> // do something with field
> }
> {code}
> This can be simplified by providing fallback implementations for the fields 
> being used by TestSetRunListener.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SUREFIRE-1293) Simplify org.apache.maven.plugin.surefire.report.TestSetRunListener by using the null object pattern

2016-10-12 Thread ASF GitHub Bot (JIRA)


[ 
https://issues.apache.org/jira/browse/SUREFIRE-1293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15568846#comment-15568846
 ] 

ASF GitHub Bot commented on SUREFIRE-1293:
--

Github user Tibor17 commented on the issue:

https://github.com/apache/maven-surefire/pull/127
  
Try to clone Surefire master and just run "mvn test"

Caused by: java.lang.NoClassDefFoundError: 
org/apache/commons/lang3/ObjectUtils
at 
org.apache.maven.plugin.surefire.report.DefaultReporterFactory.createFileReporter(DefaultReporterFactory.java:111)
at 
org.apache.maven.plugin.surefire.report.DefaultReporterFactory.createReporter(DefaultReporterFactory.java:92)
at 
org.apache.maven.surefire.testng.TestNGProvider.invoke(TestNGProvider.java:102)



On Wed, Oct 12, 2016 at 2:57 PM, Benedikt Ritter 
wrote:

> @Tibor17  I don't understand. mvn clean
> compile works. Why does this fail on Jenkins?
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> 
,
> or mute the thread
> 

> .
>



-- 
Cheers
Tibor



> Simplify org.apache.maven.plugin.surefire.report.TestSetRunListener by using 
> the null object pattern
> 
>
> Key: SUREFIRE-1293
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1293
> Project: Maven Surefire
>  Issue Type: Improvement
>  Components: Maven Surefire Plugin
>Reporter: Benedikt Ritter
>Assignee: Tibor Digana
>  Labels: github
> Fix For: 2.19.2
>
>
> The class org.apache.maven.plugin.surefire.report.TestSetRunListener has a 
> lot of checks like this:
> {code:java}
> if( field != null )
> {
> // do something with field
> }
> {code}
> This can be simplified by providing fallback implementations for the fields 
> being used by TestSetRunListener.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SUREFIRE-1293) Simplify org.apache.maven.plugin.surefire.report.TestSetRunListener by using the null object pattern

2016-10-12 Thread ASF GitHub Bot (JIRA)


[ 
https://issues.apache.org/jira/browse/SUREFIRE-1293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15568908#comment-15568908
 ] 

ASF GitHub Bot commented on SUREFIRE-1293:
--

Github user Tibor17 commented on the issue:

https://github.com/apache/maven-surefire/pull/127
  
@britter 
After using one integration tests only
`org/apache/**/JUnit47ParallelIT.java`
I got same errors as in Jenkins.
I think the dependency `commons-lang3` is not propagated to the forked jvm. 
Maybe somewhere some scope but not in our code.
If you run the test and go to `target/surefire` you will see a jar file. 
Download it and lookup `commons` in manifest.


> Simplify org.apache.maven.plugin.surefire.report.TestSetRunListener by using 
> the null object pattern
> 
>
> Key: SUREFIRE-1293
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1293
> Project: Maven Surefire
>  Issue Type: Improvement
>  Components: Maven Surefire Plugin
>Reporter: Benedikt Ritter
>Assignee: Tibor Digana
>  Labels: github
> Fix For: 2.19.2
>
>
> The class org.apache.maven.plugin.surefire.report.TestSetRunListener has a 
> lot of checks like this:
> {code:java}
> if( field != null )
> {
> // do something with field
> }
> {code}
> This can be simplified by providing fallback implementations for the fields 
> being used by TestSetRunListener.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (MJAVADOC-333) Diacritics (accents) in project path prevent the plugin from working on Windows.

2016-10-12 Thread Anthony O. (JIRA)


 [ 
https://issues.apache.org/jira/browse/MJAVADOC-333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Anthony O. updated MJAVADOC-333:

Attachment: FailingProject.zip

Here is a failing project with which I had the problem.

After verification, it's happening only if I launch the Maven target "package" 
from IntelliJ IDEA 2016.2.4 which executes this command:
{noformat}
C:\Développement\MJAVADOC-333>C:\Users\myuser\Applications\JDK\8u92-windows-x64\bin\java
 
-Dmaven.home=C:\Users\myuser\Applications\IntelliJ\2016.2.2\plugins\maven\lib\maven3
 
-Dclassworlds.conf=C:\Users\myuser\Applications\IntelliJ\2016.2.2\plugins\maven\lib\maven3\bin\m2.conf
 -Didea.launcher.port=7534 
-Didea.launcher.bin.path=C:\Users\myuser\Applications\IntelliJ\2016.2.2\bin 
-Dfile.encoding=UTF-8 
-classpathC:\Users\myuser\Applications\IntelliJ\2016.2.2\plugins\maven\lib\maven3\boot\plexus-classworlds-2.4.jar;C:\Users\myuser\Applications\IntelliJ\2016.2.2\lib\idea_rt.jar
 com.intellij.rt.execution.application.AppMain 
org.codehaus.classworlds.Launcher -Didea.version=2016.2.4 package
{noformat}

Here is the output in that case:
{noformat}
[INFO] Scanning for projects...
[INFO]
[INFO] 
[INFO] Building mjavadoc-333 0.1.0-SNAPSHOT
[INFO] 
[INFO]
[INFO] --- maven-resources-plugin:2.5:resources (default-resources) @ 
mjavadoc-333 ---
[debug] execute contextualize
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory 
C:\Développement\MJAVADOC-333\src\main\resources
[INFO]
[INFO] --- maven-compiler-plugin:3.5.1:compile (default-compile) @ mjavadoc-333 
---
[INFO] Changes detected - recompiling the module!
[INFO] Compiling 1 source file to C:\Développement\MJAVADOC-333\target\classes
[INFO]
[INFO] --- maven-resources-plugin:2.5:testResources (default-testResources) @ 
mjavadoc-333 ---
[debug] execute contextualize
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory 
C:\Développement\MJAVADOC-333\src\test\resources
[INFO]
[INFO] --- maven-compiler-plugin:3.5.1:testCompile (default-testCompile) @ 
mjavadoc-333 ---
[INFO] No sources to compile
[INFO]
[INFO] --- maven-surefire-plugin:2.10:test (default-test) @ mjavadoc-333 ---
[INFO] No tests to run.
[INFO] Surefire report directory: 
C:\Développement\MJAVADOC-333\target\surefire-reports

---
 T E S T S
---

Results :

Tests run: 0, Failures: 0, Errors: 0, Skipped: 0

[INFO]
[INFO] --- maven-jar-plugin:2.3.2:jar (default-jar) @ mjavadoc-333 ---
[INFO] Building jar: 
C:\Développement\MJAVADOC-333\target\mjavadoc-333-0.1.0-SNAPSHOT.jar
[INFO]
[INFO] --- maven-javadoc-plugin:2.10.4:jar (attach-javadoc) @ mjavadoc-333 ---
[INFO]
Loading source files for package com.mycompany.mjavadoc_333...
Constructing Javadoc information...
1 error
2 warnings
[INFO] 
[INFO] BUILD FAILURE
[INFO] 
[INFO] Total time: 4.778s
[INFO] Finished at: Wed Oct 12 17:05:17 CEST 2016
[INFO] Final Memory: 20M/277M
[INFO] 
[ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-javadoc-plugin:2.10.4:jar (attach-javadoc) on 
project mjavadoc-333: MavenReportException: Error while generating Javadoc:
[ERROR] Exit code: 1 - javadoc: warning - No source files for package 
com.mycompany.mjavadoc_333
[ERROR] javadoc: warning - No source files for package 
com.mycompany.mjavadoc_333
[ERROR] javadoc: error - No public or protected classes found to document.
[ERROR]
[ERROR] Command line was: 
C:\Users\myuser\Applications\JDK\8u92-windows-x64\jre\..\bin\javadoc.exe 
-J-Dhttp.proxySet=true -J-Dhttp.proxyHost=localhost -J-Dhttp.proxyPort=5865 
"-J-Dhttp.nonProxyHosts=\"localhost\"" @options @packages
[ERROR]
[ERROR] Refer to the generated Javadoc files in 
'C:\Développement\MJAVADOC-333\target\apidocs' dir.
[ERROR] -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e 
switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please 
read the following articles:
[ERROR] [Help 1] 
http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
{noformat}

> Diacritics (accents) in project path prevent the plugin from working on 
> Windows.
> 
>
> Key: MJAVADOC-333
> URL: https://issues.apache.org/jira/browse/MJAVADOC-333
> Project: Maven Javadoc Plugin
>

[jira] [Comment Edited] (MJAVADOC-333) Diacritics (accents) in project path prevent the plugin from working on Windows.

2016-10-12 Thread Anthony O. (JIRA)


[ 
https://issues.apache.org/jira/browse/MJAVADOC-333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15568988#comment-15568988
 ] 

Anthony O. edited comment on MJAVADOC-333 at 10/12/16 3:22 PM:
---

Here is a failing project with which I had the problem.

After verification, it's happening only if I launch the Maven target "package" 
from IntelliJ IDEA 2016.2.4 which executes this command:
{noformat}
C:\Développement\MJAVADOC-333>C:\Users\myuser\Applications\JDK\8u92-windows-x64\bin\java
 
-Dmaven.home=C:\Users\myuser\Applications\IntelliJ\2016.2.2\plugins\maven\lib\maven3
 
-Dclassworlds.conf=C:\Users\myuser\Applications\IntelliJ\2016.2.2\plugins\maven\lib\maven3\bin\m2.conf
 -Didea.launcher.port=7534 
-Didea.launcher.bin.path=C:\Users\myuser\Applications\IntelliJ\2016.2.2\bin 
-Dfile.encoding=UTF-8 
-classpathC:\Users\myuser\Applications\IntelliJ\2016.2.2\plugins\maven\lib\maven3\boot\plexus-classworlds-2.4.jar;C:\Users\myuser\Applications\IntelliJ\2016.2.2\lib\idea_rt.jar
 com.intellij.rt.execution.application.AppMain 
org.codehaus.classworlds.Launcher -Didea.version=2016.2.4 package
{noformat}

Here is the output in that case:
{noformat}
[INFO] Scanning for projects...
[INFO]
[INFO] 
[INFO] Building mjavadoc-333 0.1.0-SNAPSHOT
[INFO] 
[INFO]
[INFO] --- maven-resources-plugin:2.5:resources (default-resources) @ 
mjavadoc-333 ---
[debug] execute contextualize
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory 
C:\Développement\MJAVADOC-333\src\main\resources
[INFO]
[INFO] --- maven-compiler-plugin:3.5.1:compile (default-compile) @ mjavadoc-333 
---
[INFO] Changes detected - recompiling the module!
[INFO] Compiling 1 source file to C:\Développement\MJAVADOC-333\target\classes
[INFO]
[INFO] --- maven-resources-plugin:2.5:testResources (default-testResources) @ 
mjavadoc-333 ---
[debug] execute contextualize
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory 
C:\Développement\MJAVADOC-333\src\test\resources
[INFO]
[INFO] --- maven-compiler-plugin:3.5.1:testCompile (default-testCompile) @ 
mjavadoc-333 ---
[INFO] No sources to compile
[INFO]
[INFO] --- maven-surefire-plugin:2.10:test (default-test) @ mjavadoc-333 ---
[INFO] No tests to run.
[INFO] Surefire report directory: 
C:\Développement\MJAVADOC-333\target\surefire-reports

---
 T E S T S
---

Results :

Tests run: 0, Failures: 0, Errors: 0, Skipped: 0

[INFO]
[INFO] --- maven-jar-plugin:2.3.2:jar (default-jar) @ mjavadoc-333 ---
[INFO] Building jar: 
C:\Développement\MJAVADOC-333\target\mjavadoc-333-0.1.0-SNAPSHOT.jar
[INFO]
[INFO] --- maven-javadoc-plugin:2.10.4:jar (attach-javadoc) @ mjavadoc-333 ---
[INFO]
Loading source files for package com.mycompany.mjavadoc_333...
Constructing Javadoc information...
1 error
2 warnings
[INFO] 
[INFO] BUILD FAILURE
[INFO] 
[INFO] Total time: 4.778s
[INFO] Finished at: Wed Oct 12 17:05:17 CEST 2016
[INFO] Final Memory: 20M/277M
[INFO] 
[ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-javadoc-plugin:2.10.4:jar (attach-javadoc) on 
project mjavadoc-333: MavenReportException: Error while generating Javadoc:
[ERROR] Exit code: 1 - javadoc: warning - No source files for package 
com.mycompany.mjavadoc_333
[ERROR] javadoc: warning - No source files for package 
com.mycompany.mjavadoc_333
[ERROR] javadoc: error - No public or protected classes found to document.
[ERROR]
[ERROR] Command line was: 
C:\Users\myuser\Applications\JDK\8u92-windows-x64\jre\..\bin\javadoc.exe 
-J-Dhttp.proxySet=true -J-Dhttp.proxyHost=localhost -J-Dhttp.proxyPort=5865 
"-J-Dhttp.nonProxyHosts=\"localhost\"" @options @packages
[ERROR]
[ERROR] Refer to the generated Javadoc files in 
'C:\Développement\MJAVADOC-333\target\apidocs' dir.
[ERROR] -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e 
switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please 
read the following articles:
[ERROR] [Help 1] 
http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
{noformat}

I created an issue in Jetbrains JIRA in case that's their role to fix this: 
https://youtrack.jetbrains.com/issue/IDEA-162485


was (Author: anthony-o):
Here is a failing project with which I had the problem.

After verification, it's happening only if I

[jira] [Commented] (MJAVADOC-333) Diacritics (accents) in project path prevent the plugin from working on Windows.

2016-10-12 Thread Michael Osipov (JIRA)


[ 
https://issues.apache.org/jira/browse/MJAVADOC-333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15569034#comment-15569034
 ] 

Michael Osipov commented on MJAVADOC-333:
-

It works without changes:

{noformat}
D:\Développement\MJAVADOC-333>mvn -V package
Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 
2015-11-10T17:41:47+01:00)
Maven home: D:\Entwicklung\Programme\apache-maven-3.3.9\bin\..
Java version: 1.8.0_92, vendor: Oracle Corporation
Java home: C:\Program Files\Java\jdk1.8.0_92\jre
Default locale: de_DE, platform encoding: Cp1252
OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
[INFO] Scanning for projects...
[INFO]
[INFO] 
[INFO] Building mjavadoc-333 0.1.0-SNAPSHOT
[INFO] 
[INFO]
[INFO] --- maven-resources-plugin:2.6:resources (default-resources) @ 
mjavadoc-333 ---
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory 
D:\Développement\MJAVADOC-333\src\main\resources
[INFO]
[INFO] --- maven-compiler-plugin:3.5.1:compile (default-compile) @ mjavadoc-333 
---
[INFO] Changes detected - recompiling the module!
[INFO] Compiling 1 source file to D:\Développement\MJAVADOC-333\target\classes
[INFO]
[INFO] --- maven-resources-plugin:2.6:testResources (default-testResources) @ 
mjavadoc-333 ---
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory 
D:\Développement\MJAVADOC-333\src\test\resources
[INFO]
[INFO] --- maven-compiler-plugin:3.5.1:testCompile (default-testCompile) @ 
mjavadoc-333 ---
[INFO] No sources to compile
[INFO]
[INFO] --- maven-surefire-plugin:2.12.4:test (default-test) @ mjavadoc-333 ---
[INFO] No tests to run.
[INFO]
[INFO] --- maven-jar-plugin:2.4:jar (default-jar) @ mjavadoc-333 ---
[INFO] Building jar: 
D:\Développement\MJAVADOC-333\target\mjavadoc-333-0.1.0-SNAPSHOT.jar
[INFO]
[INFO] --- maven-javadoc-plugin:2.10.4:jar (attach-javadoc) @ mjavadoc-333 ---
[INFO]
Loading source files for package com.mycompany.mjavadoc_333...
Constructing Javadoc information...
Standard Doclet version 1.8.0_92
Building tree for all the packages and classes...
Generating 
D:\Développement\MJAVADOC-333\target\apidocs\com\mycompany\mjavadoc_333\MyClass.html...
Generating 
D:\Développement\MJAVADOC-333\target\apidocs\com\mycompany\mjavadoc_333\package-frame.html...
Generating 
D:\Développement\MJAVADOC-333\target\apidocs\com\mycompany\mjavadoc_333\package-summary.html...
Generating 
D:\Développement\MJAVADOC-333\target\apidocs\com\mycompany\mjavadoc_333\package-tree.html...
Generating D:\Développement\MJAVADOC-333\target\apidocs\constant-values.html...
Generating 
D:\Développement\MJAVADOC-333\target\apidocs\com\mycompany\mjavadoc_333\class-use\MyClass.html...
Generating 
D:\Développement\MJAVADOC-333\target\apidocs\com\mycompany\mjavadoc_333\package-use.html...
Building index for all the packages and classes...
Generating D:\Développement\MJAVADOC-333\target\apidocs\overview-tree.html...
Generating D:\Développement\MJAVADOC-333\target\apidocs\index-all.html...
Generating D:\Développement\MJAVADOC-333\target\apidocs\deprecated-list.html...
Building index for all classes...
Generating D:\Développement\MJAVADOC-333\target\apidocs\allclasses-frame.html...
Generating 
D:\Développement\MJAVADOC-333\target\apidocs\allclasses-noframe.html...
Generating D:\Développement\MJAVADOC-333\target\apidocs\index.html...
Generating D:\Développement\MJAVADOC-333\target\apidocs\help-doc.html...
[INFO] Building jar: 
D:\Développement\MJAVADOC-333\target\mjavadoc-333-0.1.0-SNAPSHOT-javadoc.jar
[INFO] 
[INFO] BUILD SUCCESS
[INFO] 
[INFO] Total time: 2.396 s
[INFO] Finished at: 2016-10-12T17:27:40+02:00
[INFO] Final Memory: 20M/214M
[INFO] 

D:\Développement\MJAVADOC-333>
{noformat}

> Diacritics (accents) in project path prevent the plugin from working on 
> Windows.
> 
>
> Key: MJAVADOC-333
> URL: https://issues.apache.org/jira/browse/MJAVADOC-333
> Project: Maven Javadoc Plugin
>  Issue Type: Bug
>Affects Versions: 2.7, 2.8
> Environment: Win7
>Reporter: Martin Pecka
> Attachments: FailingProject.zip, options, pom.xml
>
>
> My project is located in "E:\ProgramovÃ¡nÃ\Java\beam-3D-data-viewer". Notice 
> the diacritics in the path.
> When launching the javadoc:javadoc goal, the build fails:
> .
> .
> .
> [ERROR] javadoc: warning - No source files for package org.esa.beam.util
> [ERROR] javadoc:

[jira] [Commented] (SUREFIRE-1293) Simplify org.apache.maven.plugin.surefire.report.TestSetRunListener by using the null object pattern

2016-10-12 Thread ASF GitHub Bot (JIRA)


[ 
https://issues.apache.org/jira/browse/SUREFIRE-1293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15569764#comment-15569764
 ] 

ASF GitHub Bot commented on SUREFIRE-1293:
--

Github user Tibor17 commented on the issue:

https://github.com/apache/maven-surefire/pull/127
  
I fixed this issue where I removed [1]. The reason behind is the 
`IsolatedClassLoader` in plugin process which did not have shaded 
`commons-lang3` in original jar file of `surefire-common`. Because of one 
method in `commons-lang3` we should not pass such a big library. Instead I 
created `ObjectUtils` which has only few method and most of them is already in 
Java 7 utility class `java.util.Objects`. In Surefire on the top of Java 7 I 
will delete them and use Java 7 facilities.
[1] import static org.apache.commons.lang3.ObjectUtils.defaultIfNull;


> Simplify org.apache.maven.plugin.surefire.report.TestSetRunListener by using 
> the null object pattern
> 
>
> Key: SUREFIRE-1293
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1293
> Project: Maven Surefire
>  Issue Type: Improvement
>  Components: Maven Surefire Plugin
>Reporter: Benedikt Ritter
>Assignee: Tibor Digana
>  Labels: github
> Fix For: 2.19.2
>
>
> The class org.apache.maven.plugin.surefire.report.TestSetRunListener has a 
> lot of checks like this:
> {code:java}
> if( field != null )
> {
> // do something with field
> }
> {code}
> This can be simplified by providing fallback implementations for the fields 
> being used by TestSetRunListener.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SUREFIRE-1293) Simplify org.apache.maven.plugin.surefire.report.TestSetRunListener by using the null object pattern

2016-10-12 Thread Tibor Digana (JIRA)


[ 
https://issues.apache.org/jira/browse/SUREFIRE-1293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15569775#comment-15569775
 ] 

Tibor Digana commented on SUREFIRE-1293:


commit 5e9f5637cead161f5e210b86febcc23d502d3f67

> Simplify org.apache.maven.plugin.surefire.report.TestSetRunListener by using 
> the null object pattern
> 
>
> Key: SUREFIRE-1293
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1293
> Project: Maven Surefire
>  Issue Type: Improvement
>  Components: Maven Surefire Plugin
>Reporter: Benedikt Ritter
>Assignee: Tibor Digana
>  Labels: github
> Fix For: 2.19.2
>
>
> The class org.apache.maven.plugin.surefire.report.TestSetRunListener has a 
> lot of checks like this:
> {code:java}
> if( field != null )
> {
> // do something with field
> }
> {code}
> This can be simplified by providing fallback implementations for the fields 
> being used by TestSetRunListener.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (MPOM-139) maven profile activation in child poms using variable profile.parent.artifactId doesn't work

2016-10-12 Thread JIRA


 [ 
https://issues.apache.org/jira/browse/MPOM-139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Miroslav Zaťko updated MPOM-139:

Description: 
I created a profile activated using property "profile.parent.artifactId" in 
parent pom so I expected it will be active in child(module) executions. It 
doesn't work even when its value is as expected
{noformat}

 

   project.parent.artifactId
   my_parent_artifactId

 
.

{noformat}
Anyway, activation using file+exists, again defined in parent pom, is working 
in child(module) executions:
{noformat}

 
${basedir}/../pom.xml
 
.

{noformat}

simple project showing this bug set at 
https://github.com/mireczatko/maven-bug.git

{{mvn validate}}

*1st* round: parent is build, property {{project.parent.artifactId}} is not 
set, so "this is default execution"  echoed by maven-antrun-plugin is correct
*2nd* round: child is build, property {{project.parent.artifactId}} is set to 
"parent", as we can see in output, so activation condition for profile 
"profile" is met. Anyway, it is not activated and "this is default execution" 
echoed again, in this step "this is profile execution" should be echoed

This would be obvious (even not expected) assuming in case profiles are 
activated or deactivated at very beginning of build process, not for each 
module separately. However, now we can change directory to child and will see 
same behavior when starting from child module. This is definitely a bug.

  was:
I created a profile activated using property "profile.parent.artifactId" in 
parent pom so I expected it will be active in child(module) executions. It 
doesn't work even when its value is as expected
{noformat}

 

   project.parent.artifactId
   my_parent_artifactId

 
.

{noformat}
Anyway, activation using file+exists, again defined in parent pom, is working 
in child(module) executions:
{noformat}

 
${basedir}/../pom.xml
 
.

{noformat}


> maven profile activation in child poms using variable 
> profile.parent.artifactId doesn't work
> 
>
> Key: MPOM-139
> URL: https://issues.apache.org/jira/browse/MPOM-139
> Project: Maven POMs
>  Issue Type: Bug
>  Components: maven
>Reporter: Miroslav Zaťko
>
> I created a profile activated using property "profile.parent.artifactId" in 
> parent pom so I expected it will be active in child(module) executions. It 
> doesn't work even when its value is as expected
> {noformat}
> 
>  
> 
>project.parent.artifactId
>my_parent_artifactId
> 
>  
> .
> 
> {noformat}
> Anyway, activation using file+exists, again defined in parent pom, is working 
> in child(module) executions:
> {noformat}
> 
>  
> ${basedir}/../pom.xml
>  
> .
> 
> {noformat}
> simple project showing this bug set at 
> https://github.com/mireczatko/maven-bug.git
> {{mvn validate}}
> *1st* round: parent is build, property {{project.parent.artifactId}} is not 
> set, so "this is default execution"  echoed by maven-antrun-plugin is correct
> *2nd* round: child is build, property {{project.parent.artifactId}} is set to 
> "parent", as we can see in output, so activation condition for profile 
> "profile" is met. Anyway, it is not activated and "this is default execution" 
> echoed again, in this step "this is profile execution" should be echoed
> This would be obvious (even not expected) assuming in case profiles are 
> activated or deactivated at very beginning of build process, not for each 
> module separately. However, now we can change directory to child and will see 
> same behavior when starting from child module. This is definitely a bug.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (MPOM-139) maven profile activation in child poms using variable profile.parent.artifactId doesn't work

2016-10-12 Thread JIRA


 [ 
https://issues.apache.org/jira/browse/MPOM-139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Miroslav Zaťko updated MPOM-139:

Description: 
I created a profile activated using property "profile.parent.artifactId" in 
parent pom so I expected it will be active in child(module) executions. It 
doesn't work even when its value is as expected
{noformat}

 

   project.parent.artifactId
   my_parent_artifactId

 
.

{noformat}
Anyway, activation using file+exists, again defined in parent pom, is working 
in child(module) executions:
{noformat}

 
${basedir}/../pom.xml
 
.

{noformat}

simple project showing this bug set at 
https://github.com/mireczatko/maven-bug.git

{{mvn validate}}

*1st* round: parent is build, property {{project.parent.artifactId}} is not 
set, so "this is default execution"  echoed by maven-antrun-plugin is correct
*2nd* round: child is build, property {{project.parent.artifactId}} is set to 
"parent", as we can see in output, so activation condition for profile 
"profile" is met. Anyway, it is not activated and "this is default execution" 
echoed again. In this step "this is profile execution" should be echoed

This would be obvious (even not expected) assuming in case profiles are 
activated or deactivated at very beginning of build process, not for each 
module separately. However, now we can change directory to child and will see 
same behavior when starting from child module. This is definitely a bug.

  was:
I created a profile activated using property "profile.parent.artifactId" in 
parent pom so I expected it will be active in child(module) executions. It 
doesn't work even when its value is as expected
{noformat}

 

   project.parent.artifactId
   my_parent_artifactId

 
.

{noformat}
Anyway, activation using file+exists, again defined in parent pom, is working 
in child(module) executions:
{noformat}

 
${basedir}/../pom.xml
 
.

{noformat}

simple project showing this bug set at 
https://github.com/mireczatko/maven-bug.git

{{mvn validate}}

*1st* round: parent is build, property {{project.parent.artifactId}} is not 
set, so "this is default execution"  echoed by maven-antrun-plugin is correct
*2nd* round: child is build, property {{project.parent.artifactId}} is set to 
"parent", as we can see in output, so activation condition for profile 
"profile" is met. Anyway, it is not activated and "this is default execution" 
echoed again, in this step "this is profile execution" should be echoed

This would be obvious (even not expected) assuming in case profiles are 
activated or deactivated at very beginning of build process, not for each 
module separately. However, now we can change directory to child and will see 
same behavior when starting from child module. This is definitely a bug.


> maven profile activation in child poms using variable 
> profile.parent.artifactId doesn't work
> 
>
> Key: MPOM-139
> URL: https://issues.apache.org/jira/browse/MPOM-139
> Project: Maven POMs
>  Issue Type: Bug
>  Components: maven
>Reporter: Miroslav Zaťko
>
> I created a profile activated using property "profile.parent.artifactId" in 
> parent pom so I expected it will be active in child(module) executions. It 
> doesn't work even when its value is as expected
> {noformat}
> 
>  
> 
>project.parent.artifactId
>my_parent_artifactId
> 
>  
> .
> 
> {noformat}
> Anyway, activation using file+exists, again defined in parent pom, is working 
> in child(module) executions:
> {noformat}
> 
>  
> ${basedir}/../pom.xml
>  
> .
> 
> {noformat}
> simple project showing this bug set at 
> https://github.com/mireczatko/maven-bug.git
> {{mvn validate}}
> *1st* round: parent is build, property {{project.parent.artifactId}} is not 
> set, so "this is default execution"  echoed by maven-antrun-plugin is correct
> *2nd* round: child is build, property {{project.parent.artifactId}} is set to 
> "parent", as we can see in output, so activation condition for profile 
> "profile" is met. Anyway, it is not activated and "this is default execution" 
> echoed again. In this step "this is profile execution" should be echoed
> This would be obvious (even not expected) assuming in case profiles are 
> activated or deactivated at very beginning of build process, not for each 
> module separately. However, now we can change directory to child and will see 
> same behavior when starting from child module. This is definitely a bug.



--
This message was sent by Atl

[jira] [Updated] (MPOM-139) maven profile activation in child poms using variable profile.parent.artifactId doesn't work

2016-10-12 Thread JIRA


 [ 
https://issues.apache.org/jira/browse/MPOM-139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Miroslav Zaťko updated MPOM-139:

Description: 
I created a profile activated using property "profile.parent.artifactId" in 
parent pom so I expected it will be active in child(module) executions. It 
doesn't work even when its value is as expected
{noformat}

 

   project.parent.artifactId
   my_parent_artifactId

 
.

{noformat}
Anyway, activation using file+exists, again defined in parent pom, is working 
in child(module) executions:
{noformat}

 
${basedir}/../pom.xml
 
.

{noformat}

simple project showing this bug set at 
https://github.com/mireczatko/maven-bug.git

{{mvn validate}}

*1st* round: parent is build, property {{project.parent.artifactId}} is not 
set, so "this is default execution"  echoed by maven-antrun-plugin is correct
*2nd* round: child is build, property {{project.parent.artifactId}} is set to 
"parent", as we can see in output, so activation condition for profile 
"profile" is met. Anyway, it is not activated and "this is default execution" 
echoed again. In this step "this is profile execution" should be echoed

This would be obvious (even not expected) assuming profiles are activated or 
deactivated at very beginning of build process, not for each module separately. 
However, now we can change directory to child and will see same behavior when 
starting from child module. This is definitely a bug.

  was:
I created a profile activated using property "profile.parent.artifactId" in 
parent pom so I expected it will be active in child(module) executions. It 
doesn't work even when its value is as expected
{noformat}

 

   project.parent.artifactId
   my_parent_artifactId

 
.

{noformat}
Anyway, activation using file+exists, again defined in parent pom, is working 
in child(module) executions:
{noformat}

 
${basedir}/../pom.xml
 
.

{noformat}

simple project showing this bug set at 
https://github.com/mireczatko/maven-bug.git

{{mvn validate}}

*1st* round: parent is build, property {{project.parent.artifactId}} is not 
set, so "this is default execution"  echoed by maven-antrun-plugin is correct
*2nd* round: child is build, property {{project.parent.artifactId}} is set to 
"parent", as we can see in output, so activation condition for profile 
"profile" is met. Anyway, it is not activated and "this is default execution" 
echoed again. In this step "this is profile execution" should be echoed

This would be obvious (even not expected) assuming in case profiles are 
activated or deactivated at very beginning of build process, not for each 
module separately. However, now we can change directory to child and will see 
same behavior when starting from child module. This is definitely a bug.


> maven profile activation in child poms using variable 
> profile.parent.artifactId doesn't work
> 
>
> Key: MPOM-139
> URL: https://issues.apache.org/jira/browse/MPOM-139
> Project: Maven POMs
>  Issue Type: Bug
>  Components: maven
>Reporter: Miroslav Zaťko
>
> I created a profile activated using property "profile.parent.artifactId" in 
> parent pom so I expected it will be active in child(module) executions. It 
> doesn't work even when its value is as expected
> {noformat}
> 
>  
> 
>project.parent.artifactId
>my_parent_artifactId
> 
>  
> .
> 
> {noformat}
> Anyway, activation using file+exists, again defined in parent pom, is working 
> in child(module) executions:
> {noformat}
> 
>  
> ${basedir}/../pom.xml
>  
> .
> 
> {noformat}
> simple project showing this bug set at 
> https://github.com/mireczatko/maven-bug.git
> {{mvn validate}}
> *1st* round: parent is build, property {{project.parent.artifactId}} is not 
> set, so "this is default execution"  echoed by maven-antrun-plugin is correct
> *2nd* round: child is build, property {{project.parent.artifactId}} is set to 
> "parent", as we can see in output, so activation condition for profile 
> "profile" is met. Anyway, it is not activated and "this is default execution" 
> echoed again. In this step "this is profile execution" should be echoed
> This would be obvious (even not expected) assuming profiles are activated or 
> deactivated at very beginning of build process, not for each module 
> separately. However, now we can change directory to child and will see same 
> behavior when starting from child module. This is definitely a bug.



--
This message was sent by Atlassian JIRA
(v6.

[jira] [Updated] (MPOM-139) maven profile activation in child poms using variable profile.parent.artifactId doesn't work

2016-10-12 Thread JIRA


 [ 
https://issues.apache.org/jira/browse/MPOM-139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Miroslav Zaťko updated MPOM-139:

Description: 
I created a profile activated using property "profile.parent.artifactId" in 
parent pom so I expected it will be active in child(module) executions. It 
doesn't work even when its value is as expected
{noformat}

 

   project.parent.artifactId
   my_parent_artifactId

 
.

{noformat}
Anyway, activation using file+exists, again defined in parent pom, is working 
in child(module) executions:
{noformat}

 
${basedir}/../pom.xml
 
.

{noformat}

simple project showing this bug set at 
https://github.com/mireczatko/maven-bug.git

{{mvn validate}}

*1st* round: parent is build, property {{project.parent.artifactId}} is not 
set, so "this is default execution"  echoed by maven-antrun-plugin is correct
*2nd* round: child is build, property {{project.parent.artifactId}} is set to 
"parent", as we can see in output, so activation condition for profile 
"profile" is met. Anyway, it is not activated and "this is default execution" 
echoed again. In this step "this is profile execution" should be echoed

This would be obvious (even not expected) assuming profiles are activated or 
deactivated at very beginning of build process, not for each module separately. 
However, now we can change directory to child and will see same behavior when 
starting from child module. This is definitely a bug.

Correct behavior we can see if we switch to branch fileactivation... BTW. it 
means my assumption about "profiles are activated or deactivated at very 
beginning of build process" was not correct...

  was:
I created a profile activated using property "profile.parent.artifactId" in 
parent pom so I expected it will be active in child(module) executions. It 
doesn't work even when its value is as expected
{noformat}

 

   project.parent.artifactId
   my_parent_artifactId

 
.

{noformat}
Anyway, activation using file+exists, again defined in parent pom, is working 
in child(module) executions:
{noformat}

 
${basedir}/../pom.xml
 
.

{noformat}

simple project showing this bug set at 
https://github.com/mireczatko/maven-bug.git

{{mvn validate}}

*1st* round: parent is build, property {{project.parent.artifactId}} is not 
set, so "this is default execution"  echoed by maven-antrun-plugin is correct
*2nd* round: child is build, property {{project.parent.artifactId}} is set to 
"parent", as we can see in output, so activation condition for profile 
"profile" is met. Anyway, it is not activated and "this is default execution" 
echoed again. In this step "this is profile execution" should be echoed

This would be obvious (even not expected) assuming profiles are activated or 
deactivated at very beginning of build process, not for each module separately. 
However, now we can change directory to child and will see same behavior when 
starting from child module. This is definitely a bug.


> maven profile activation in child poms using variable 
> profile.parent.artifactId doesn't work
> 
>
> Key: MPOM-139
> URL: https://issues.apache.org/jira/browse/MPOM-139
> Project: Maven POMs
>  Issue Type: Bug
>  Components: maven
>Reporter: Miroslav Zaťko
>
> I created a profile activated using property "profile.parent.artifactId" in 
> parent pom so I expected it will be active in child(module) executions. It 
> doesn't work even when its value is as expected
> {noformat}
> 
>  
> 
>project.parent.artifactId
>my_parent_artifactId
> 
>  
> .
> 
> {noformat}
> Anyway, activation using file+exists, again defined in parent pom, is working 
> in child(module) executions:
> {noformat}
> 
>  
> ${basedir}/../pom.xml
>  
> .
> 
> {noformat}
> simple project showing this bug set at 
> https://github.com/mireczatko/maven-bug.git
> {{mvn validate}}
> *1st* round: parent is build, property {{project.parent.artifactId}} is not 
> set, so "this is default execution"  echoed by maven-antrun-plugin is correct
> *2nd* round: child is build, property {{project.parent.artifactId}} is set to 
> "parent", as we can see in output, so activation condition for profile 
> "profile" is met. Anyway, it is not activated and "this is default execution" 
> echoed again. In this step "this is profile execution" should be echoed
> This would be obvious (even not expected) assuming profiles are activated or 
> deactivated at very beginning of build process, not for each module 
> separ

[jira] [Updated] (MPOM-139) maven profile activation in child poms using variable profile.parent.artifactId doesn't work

2016-10-12 Thread JIRA


 [ 
https://issues.apache.org/jira/browse/MPOM-139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Miroslav Zaťko updated MPOM-139:

Description: 
I created a profile activated using property "profile.parent.artifactId" in 
parent pom so I expected it will be active in child(module) executions. It 
doesn't work even when its value is as expected
{noformat}

 

   project.parent.artifactId
   my_parent_artifactId

 
.

{noformat}
Anyway, activation using file+exists, again defined in parent pom, is working 
in child(module) executions:
{noformat}

 
${basedir}/../pom.xml
 
.

{noformat}

simple project showing this bug set at 
https://github.com/mireczatko/maven-bug.git

{{mvn validate}}

*1st* round: parent is build, property {{project.parent.artifactId}} is not 
set, so "this is default execution"  echoed by maven-antrun-plugin is correct
*2nd* round: child is build, property {{project.parent.artifactId}} is set to 
"parent", as we can see in output, so activation condition for profile 
"profile" is met. Anyway, it is not activated and "this is default execution" 
echoed again. In this step "this is profile execution" should be echoed

This would be obvious (even not expected) assuming profiles are activated or 
deactivated at very beginning of build process, not for each module separately. 
However, now we can change directory to child and will see same behavior when 
starting from child module. This is definitely a bug.

Correct behavior we can see if we switch to git branch {{fileactivation}}... 
Btw. it means my assumption about "profiles are activated or deactivated at 
very beginning of build process" was not correct...

  was:
I created a profile activated using property "profile.parent.artifactId" in 
parent pom so I expected it will be active in child(module) executions. It 
doesn't work even when its value is as expected
{noformat}

 

   project.parent.artifactId
   my_parent_artifactId

 
.

{noformat}
Anyway, activation using file+exists, again defined in parent pom, is working 
in child(module) executions:
{noformat}

 
${basedir}/../pom.xml
 
.

{noformat}

simple project showing this bug set at 
https://github.com/mireczatko/maven-bug.git

{{mvn validate}}

*1st* round: parent is build, property {{project.parent.artifactId}} is not 
set, so "this is default execution"  echoed by maven-antrun-plugin is correct
*2nd* round: child is build, property {{project.parent.artifactId}} is set to 
"parent", as we can see in output, so activation condition for profile 
"profile" is met. Anyway, it is not activated and "this is default execution" 
echoed again. In this step "this is profile execution" should be echoed

This would be obvious (even not expected) assuming profiles are activated or 
deactivated at very beginning of build process, not for each module separately. 
However, now we can change directory to child and will see same behavior when 
starting from child module. This is definitely a bug.

Correct behavior we can see if we switch to branch fileactivation... BTW. it 
means my assumption about "profiles are activated or deactivated at very 
beginning of build process" was not correct...


> maven profile activation in child poms using variable 
> profile.parent.artifactId doesn't work
> 
>
> Key: MPOM-139
> URL: https://issues.apache.org/jira/browse/MPOM-139
> Project: Maven POMs
>  Issue Type: Bug
>  Components: maven
>Reporter: Miroslav Zaťko
>
> I created a profile activated using property "profile.parent.artifactId" in 
> parent pom so I expected it will be active in child(module) executions. It 
> doesn't work even when its value is as expected
> {noformat}
> 
>  
> 
>project.parent.artifactId
>my_parent_artifactId
> 
>  
> .
> 
> {noformat}
> Anyway, activation using file+exists, again defined in parent pom, is working 
> in child(module) executions:
> {noformat}
> 
>  
> ${basedir}/../pom.xml
>  
> .
> 
> {noformat}
> simple project showing this bug set at 
> https://github.com/mireczatko/maven-bug.git
> {{mvn validate}}
> *1st* round: parent is build, property {{project.parent.artifactId}} is not 
> set, so "this is default execution"  echoed by maven-antrun-plugin is correct
> *2nd* round: child is build, property {{project.parent.artifactId}} is set to 
> "parent", as we can see in output, so activation condition for profile 
> "profile" is met. Anyway, it is not activated and "this is default execution" 
> echoed again. In this

[jira] [Commented] (MSITE-705) Too much information in maven logs during site:deploy in sftp...

2016-10-12 Thread ASF GitHub Bot (JIRA)


[ 
https://issues.apache.org/jira/browse/MSITE-705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15570124#comment-15570124
 ] 

ASF GitHub Bot commented on MSITE-705:
--

GitHub user axel3rd opened a pull request:

https://github.com/apache/maven-plugins/pull/95

[MSITE-705] Wagon logs displayed only if debug mode activated

[MSITE-705](https://issues.apache.org/jira/browse/MSITE-705) : William 
Kemper patch + IT inclusion

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/axel3rd/maven-plugins MSITE-705

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/maven-plugins/pull/95.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #95






> Too much information in maven logs during site:deploy in sftp...
> 
>
> Key: MSITE-705
> URL: https://issues.apache.org/jira/browse/MSITE-705
> Project: Maven Site Plugin
>  Issue Type: Wish
>  Components: site:deploy
>Affects Versions: 3.3
> Environment: Windows / Linux, SFTP, wagon-ssh 2.6
>Reporter: Guimiot Isabelle
>Priority: Minor
> Attachments: use.debug.only.when.debug.is.enabled.patch
>
>
> When I run a site:deploy that points to an SFTP URL, each file deployed 
> generates 4 lines of log :
> {code}
> Uploading: source-repository.html to sftp://myServer/myPath/
> #
> Transfer finished. 18258 bytes copied in 0.0080 seconds
> {code}
> I guess these logs are generated by wagon-ssh, but I didn't find any solution 
> to hide them, and it's very annoying because we might deploy hundreds of 
> files during a build (javadoc, etc.), and it makes the log file uselessly 
> very big... 
> Is it possible to display them only if we run a site:deploy in debug mode 
> (-X) ?
> Thanks !



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (SUREFIRE-1293) Simplify org.apache.maven.plugin.surefire.report.TestSetRunListener by using the null object pattern

2016-10-12 Thread Tibor Digana (JIRA)


 [ 
https://issues.apache.org/jira/browse/SUREFIRE-1293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tibor Digana closed SUREFIRE-1293.
--
Resolution: Fixed

> Simplify org.apache.maven.plugin.surefire.report.TestSetRunListener by using 
> the null object pattern
> 
>
> Key: SUREFIRE-1293
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1293
> Project: Maven Surefire
>  Issue Type: Improvement
>  Components: Maven Surefire Plugin
>Reporter: Benedikt Ritter
>Assignee: Tibor Digana
>  Labels: github
> Fix For: 2.19.2
>
>
> The class org.apache.maven.plugin.surefire.report.TestSetRunListener has a 
> lot of checks like this:
> {code:java}
> if( field != null )
> {
> // do something with field
> }
> {code}
> This can be simplified by providing fallback implementations for the fields 
> being used by TestSetRunListener.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (MSITE-705) Too much information in maven logs during site:deploy in sftp...

2016-10-12 Thread Alix Lourme (JIRA)


 [ 
https://issues.apache.org/jira/browse/MSITE-705?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alix Lourme updated MSITE-705:
--
Attachment: MSITE705-maven-site-plugin.patch

[^MSITE705-maven-site-plugin.patch] : [~earthling] patch + IT inclusion
+NB+: Git patch, I could upload svn patch if required.

> Too much information in maven logs during site:deploy in sftp...
> 
>
> Key: MSITE-705
> URL: https://issues.apache.org/jira/browse/MSITE-705
> Project: Maven Site Plugin
>  Issue Type: Wish
>  Components: site:deploy
>Affects Versions: 3.3
> Environment: Windows / Linux, SFTP, wagon-ssh 2.6
>Reporter: Guimiot Isabelle
>Priority: Minor
> Attachments: MSITE705-maven-site-plugin.patch, 
> use.debug.only.when.debug.is.enabled.patch
>
>
> When I run a site:deploy that points to an SFTP URL, each file deployed 
> generates 4 lines of log :
> {code}
> Uploading: source-repository.html to sftp://myServer/myPath/
> #
> Transfer finished. 18258 bytes copied in 0.0080 seconds
> {code}
> I guess these logs are generated by wagon-ssh, but I didn't find any solution 
> to hide them, and it's very annoying because we might deploy hundreds of 
> files during a build (javadoc, etc.), and it makes the log file uselessly 
> very big... 
> Is it possible to display them only if we run a site:deploy in debug mode 
> (-X) ?
> Thanks !



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (SUREFIRE-1292) Includes misbehaves with extensions other than java

2016-10-12 Thread Tibor Digana (JIRA)


 [ 
https://issues.apache.org/jira/browse/SUREFIRE-1292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tibor Digana updated SUREFIRE-1292:
---
Fix Version/s: 3.0

> Includes misbehaves with extensions other than java
> ---
>
> Key: SUREFIRE-1292
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1292
> Project: Maven Surefire
>  Issue Type: Bug
>Reporter: Ittai Zeidman
> Fix For: 3.0, Backlog
>
>
> Hi,
> When defining an  for maven failsafe plugin it ignores ones with 
> file endings other than java. See this report for groovy 
> (https://prometheuscomputing.com/company_site/blogs/26) and I had the same 
> for scala.
> basically 
> 
> **/*E2E.scala
> 
> doesn't run a test which sits in FooE2E.scala but this
> 
> **/*E2E.java
> 
> does run the scala test



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (MJAVADOC-473) Plugin looking for mvn.bat instead of mvn.cmd

2016-10-12 Thread Gili (JIRA)

Gili created MJAVADOC-473:
-

 Summary: Plugin looking for mvn.bat instead of mvn.cmd
 Key: MJAVADOC-473
 URL: https://issues.apache.org/jira/browse/MJAVADOC-473
 Project: Maven Javadoc Plugin
  Issue Type: Bug
  Components: javadoc
Affects Versions: 2.9.1
Reporter: Gili


I get the following error message:

{code}
--- maven-javadoc-plugin:2.9.1:jar (attach-javadocs) @ japicmp-test ---
The goal 'org.apache.maven.plugins:maven-javadoc-plugin:2.9.1:javadoc' has not 
been previously called for the module: 
'com.github.siom79.japicmp:japicmp-test-v2:jar:0.9.2-SNAPSHOT'. Trying to 
invoke it...
MavenInvocationException: Error configuring command-line. Reason: Maven 
executable not found at: C:\Program Files\apache-maven-3.3.9\bin\mvn.bat
Creating fake javadoc directory to prevent repeated invocations: 
C:\Users\Gili\Documents\japicmp-develop\japicmp-testbase\japicmp-test-v2\target\apidocs
Error fetching link: 
C:\Users\Gili\Documents\japicmp-develop\japicmp-testbase\japicmp-test-v2\target\apidocs/package-list.
 Ignored it.
Building jar: 
C:\Users\Gili\Documents\japicmp-develop\japicmp-testbase\japicmp-test\target\japicmp-test-0.9.2-SNAPSHOT-javadoc.jar
{code}

According to https://issues.apache.org/jira/browse/MRELEASE-914 Maven 3.3.1 
renamed mvn.bat to mvn.cmd.

Please update the plugin accordingly.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SUREFIRE-1293) Simplify org.apache.maven.plugin.surefire.report.TestSetRunListener by using the null object pattern

2016-10-12 Thread ASF GitHub Bot (JIRA)


[ 
https://issues.apache.org/jira/browse/SUREFIRE-1293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15571029#comment-15571029
 ] 

ASF GitHub Bot commented on SUREFIRE-1293:
--

Github user britter commented on the issue:

https://github.com/apache/maven-surefire/pull/127
  
> I fixed this issue where I removed [1]

Thank you!

> Because of one method in commons-lang3 we should not pass such a big 
library.

ACK

> Instead I created ObjectUtils which has only few method and most of them 
is already in Java 7 utility class java.util.Objects. In Surefire on the top of 
Java 7 I will delete them and use Java 7 facilities.

Good Idea! Sorry for causing the problems.


> Simplify org.apache.maven.plugin.surefire.report.TestSetRunListener by using 
> the null object pattern
> 
>
> Key: SUREFIRE-1293
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1293
> Project: Maven Surefire
>  Issue Type: Improvement
>  Components: Maven Surefire Plugin
>Reporter: Benedikt Ritter
>Assignee: Tibor Digana
>  Labels: github
> Fix For: 2.19.2
>
>
> The class org.apache.maven.plugin.surefire.report.TestSetRunListener has a 
> lot of checks like this:
> {code:java}
> if( field != null )
> {
> // do something with field
> }
> {code}
> This can be simplified by providing fallback implementations for the fields 
> being used by TestSetRunListener.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SUREFIRE-1293) Simplify org.apache.maven.plugin.surefire.report.TestSetRunListener by using the null object pattern

[jira] [Assigned] (SUREFIRE-1293) Simplify org.apache.maven.plugin.surefire.report.TestSetRunListener by using the null object pattern

[jira] [Commented] (SUREFIRE-1293) Simplify org.apache.maven.plugin.surefire.report.TestSetRunListener by using the null object pattern

[jira] [Commented] (SUREFIRE-1293) Simplify org.apache.maven.plugin.surefire.report.TestSetRunListener by using the null object pattern

[jira] [Commented] (SUREFIRE-1293) Simplify org.apache.maven.plugin.surefire.report.TestSetRunListener by using the null object pattern

[jira] [Commented] (SUREFIRE-1293) Simplify org.apache.maven.plugin.surefire.report.TestSetRunListener by using the null object pattern

[jira] [Commented] (SUREFIRE-1293) Simplify org.apache.maven.plugin.surefire.report.TestSetRunListener by using the null object pattern

[jira] [Commented] (SUREFIRE-1293) Simplify org.apache.maven.plugin.surefire.report.TestSetRunListener by using the null object pattern

[jira] [Commented] (SUREFIRE-1293) Simplify org.apache.maven.plugin.surefire.report.TestSetRunListener by using the null object pattern

[jira] [Commented] (SUREFIRE-1293) Simplify org.apache.maven.plugin.surefire.report.TestSetRunListener by using the null object pattern

[jira] [Updated] (MJAVADOC-333) Diacritics (accents) in project path prevent the plugin from working on Windows.

[jira] [Comment Edited] (MJAVADOC-333) Diacritics (accents) in project path prevent the plugin from working on Windows.

[jira] [Commented] (MJAVADOC-333) Diacritics (accents) in project path prevent the plugin from working on Windows.

[jira] [Commented] (SUREFIRE-1293) Simplify org.apache.maven.plugin.surefire.report.TestSetRunListener by using the null object pattern

[jira] [Commented] (SUREFIRE-1293) Simplify org.apache.maven.plugin.surefire.report.TestSetRunListener by using the null object pattern

[jira] [Updated] (MPOM-139) maven profile activation in child poms using variable profile.parent.artifactId doesn't work

[jira] [Updated] (MPOM-139) maven profile activation in child poms using variable profile.parent.artifactId doesn't work

[jira] [Updated] (MPOM-139) maven profile activation in child poms using variable profile.parent.artifactId doesn't work

[jira] [Updated] (MPOM-139) maven profile activation in child poms using variable profile.parent.artifactId doesn't work

[jira] [Updated] (MPOM-139) maven profile activation in child poms using variable profile.parent.artifactId doesn't work

[jira] [Commented] (MSITE-705) Too much information in maven logs during site:deploy in sftp...

[jira] [Closed] (SUREFIRE-1293) Simplify org.apache.maven.plugin.surefire.report.TestSetRunListener by using the null object pattern

[jira] [Updated] (MSITE-705) Too much information in maven logs during site:deploy in sftp...

[jira] [Updated] (SUREFIRE-1292) Includes misbehaves with extensions other than java

[jira] [Created] (MJAVADOC-473) Plugin looking for mvn.bat instead of mvn.cmd

[jira] [Commented] (SUREFIRE-1293) Simplify org.apache.maven.plugin.surefire.report.TestSetRunListener by using the null object pattern

26 matches

Site Navigation

Mail list logo

Footer information