[jira] [Commented] (SCM-869) gitexe list() implemented incorrectly

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/SCM-869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16372508#comment-16372508
 ] 

ASF GitHub Bot commented on SCM-869:


GitHub user basinilya opened a pull request:

https://github.com/apache/maven-scm/pull/67

[SCM-869] fix gitexe list() implemented incorrectly



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

$ git pull https://github.com/basinilya/maven-scm SCM-869

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

https://github.com/apache/maven-scm/pull/67.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 #67


commit c50c7755d68b8d9c7a4aa46296724969cf58fcf5
Author: Ilya Basin 
Date:   2018-02-22T07:10:20Z

[SCM-869] fix gitexe list() implemented incorrectly




> gitexe list() implemented incorrectly
> -
>
> Key: SCM-869
> URL: https://issues.apache.org/jira/browse/SCM-869
> Project: Maven SCM
>  Issue Type: Bug
>  Components: maven-scm-provider-gitexe
>Affects Versions: 1.9.5, 1.9.6
>Reporter: Ilya Basin
>Priority: Major
>
> Taking the Svn implementation as a model, ScmProvider.list() should be 
> implemented as follows:
>  * The command must directly query the remote repository for files
>  * A local working copy is unnecessary and if it doesn't exist, the remote 
> repository must not be checked out.
>  * fileSet.getBasedir() indicates where to run the scm binary. The 
> recommended value is ".".
>  * fileSet.getFileList() indicates the files to list
>  * repository indicates the repo URL
> Git (among other SCMs) does not support listing remote files, so the command 
> should just fail.
> For listing files in a working copy, users should call the 
> ScmProvider.status() method instead.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] maven-scm pull request #67: [SCM-869] fix gitexe list() implemented incorrec...

[basinilya]

GitHub user basinilya opened a pull request:

https://github.com/apache/maven-scm/pull/67

[SCM-869] fix gitexe list() implemented incorrectly



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

$ git pull https://github.com/basinilya/maven-scm SCM-869

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

https://github.com/apache/maven-scm/pull/67.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 #67


commit c50c7755d68b8d9c7a4aa46296724969cf58fcf5
Author: Ilya Basin 
Date:   2018-02-22T07:10:20Z

[SCM-869] fix gitexe list() implemented incorrectly




---

[jira] [Created] (SUREFIRE-1487) ParallelComputerBuilderTest fails on overloaded system because internal delay are shorter than blocking time of JVM

[Tibor Digana (JIRA)]

Tibor Digana created SUREFIRE-1487:
--

 Summary: ParallelComputerBuilderTest fails on overloaded system 
because internal delay are shorter than blocking time of JVM
 Key: SUREFIRE-1487
 URL: https://issues.apache.org/jira/browse/SUREFIRE-1487
 Project: Maven Surefire
  Issue Type: Task
  Components: Junit 4.7+ (parallel) support
Reporter: Tibor Digana


The delays are 500 ms and variations 250 ms.
The JVM was blocked for 675 ms.
>From these measurements, the new delay should be 3-times longer at least.

[windows] Tests in error: 
[windows]   
separatePoolsWithSuiteAndSequentialClasses(org.apache.maven.surefire.junitcore.pc.ParallelComputerBuilderTest):
 (..)
[windows]   
parallelMethodsReuseOneOrTwoThreads(org.apache.maven.surefire.junitcore.pc.ParallelComputerBuilderTest):
 (..)
[windows]   
suiteAndClassInOnePool(org.apache.maven.surefire.junitcore.pc.ParallelComputerBuilderTest):
 (..)

suiteAndClassInOnePool:
Expected: (between <1450L> and <1750L> or between <1950L> and <2250L> or 
between <2450L> and <2750L>)
  but: was <3175L>


parallelMethodsReuseOneOrTwoThreads:
Expected: between <1450L> and <1750L>
  but: was <1837L>

separatePoolsWithSuiteAndSequentialClasses:
Expected: between <1450L> and <1750L>
  but: was <3562L>
In this case the JVM was blocked for 2.062 second and the delays should be 9 
times longer. The test {{ParallelComputerBuilderTest}} has small number of 
tests, so we can prolong the delays 10 times.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (SUREFIRE-1486) maven-failsafe-plugin does not use JUnit adapter for JUnit4 annotations

[Tibor Digana (JIRA)]

Tibor Digana created SUREFIRE-1486:
--

 Summary: maven-failsafe-plugin does not use JUnit adapter for 
JUnit4 annotations
 Key: SUREFIRE-1486
 URL: https://issues.apache.org/jira/browse/SUREFIRE-1486
 Project: Maven Surefire
  Issue Type: Task
Reporter: Tibor Digana
 Fix For: 2.21.0


The unit tests of {{maven-failsafe-plugin}} pass successfully in IDEA if you 
run them locally.
The Maven build does not have a chance. Therefore use JUnit3 adapter to call 
them on JUnit4 library. The tests use annotations and cannot be run in JUnit3 
runner. Therefore we use adapter elsewhere called {{JUnit4SuiteTest.java}}.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (SUREFIRE-1485) surefire-shadefire project should not be deployed in Maven Central

[Tibor Digana (JIRA)]

Tibor Digana created SUREFIRE-1485:
--

 Summary: surefire-shadefire project should not be deployed in 
Maven Central
 Key: SUREFIRE-1485
 URL: https://issues.apache.org/jira/browse/SUREFIRE-1485
 Project: Maven Surefire
  Issue Type: Task
Reporter: Tibor Digana
 Fix For: 2.21.0


It is useless to deploy {{surefire-shadefire}} which is used internally only.
The deployment in release process would be faster faster a bit.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (SUREFIRE-1484) maven-clean-plugin should be used in integration test resource junit-pathWithUmlaut

[Tibor Digana (JIRA)]

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

Tibor Digana updated SUREFIRE-1484:
---
Description: 
By mistake the m-clean-p was added in another IT: {{crash-during-test}}.
It needs to be moved to {{junit-pathWithUmlaut}}.
The point is to properly delete target which contains language mutation in a 
directory name using the latest version of m-clean-p. We use several versions 
of Maven and the plugin should be one version.

  was:
By mistake the m-clean-p was added in another IT: {{crash-during-test}}.
It needs to be moved to {{junit-pathWithUmlaut}}.
The point is to properly delete target which contains language mutation in a 
directory name using the latest version of m-clean-p.


> maven-clean-plugin should be used in integration test resource 
> junit-pathWithUmlaut
> ---
>
> Key: SUREFIRE-1484
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1484
> Project: Maven Surefire
>  Issue Type: Task
>Reporter: Tibor Digana
>Priority: Major
> Fix For: 2.21.0
>
>
> By mistake the m-clean-p was added in another IT: {{crash-during-test}}.
> It needs to be moved to {{junit-pathWithUmlaut}}.
> The point is to properly delete target which contains language mutation in a 
> directory name using the latest version of m-clean-p. We use several versions 
> of Maven and the plugin should be one version.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (SUREFIRE-1484) maven-clean-plugin should be used in integration test resource junit-pathWithUmlaut

[Tibor Digana (JIRA)]

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

Tibor Digana updated SUREFIRE-1484:
---
Description: 
By mistake the m-clean-p was added in another IT: {{crash-during-test}}.
It needs to be moved to {{junit-pathWithUmlaut}}.
The point is to properly delete target which contains language mutation in a 
directory name using the latest version of m-clean-p. We use several versions 
of Maven to build the project and the plugin should be one version.

  was:
By mistake the m-clean-p was added in another IT: {{crash-during-test}}.
It needs to be moved to {{junit-pathWithUmlaut}}.
The point is to properly delete target which contains language mutation in a 
directory name using the latest version of m-clean-p. We use several versions 
of Maven and the plugin should be one version.


> maven-clean-plugin should be used in integration test resource 
> junit-pathWithUmlaut
> ---
>
> Key: SUREFIRE-1484
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1484
> Project: Maven Surefire
>  Issue Type: Task
>Reporter: Tibor Digana
>Priority: Major
> Fix For: 2.21.0
>
>
> By mistake the m-clean-p was added in another IT: {{crash-during-test}}.
> It needs to be moved to {{junit-pathWithUmlaut}}.
> The point is to properly delete target which contains language mutation in a 
> directory name using the latest version of m-clean-p. We use several versions 
> of Maven to build the project and the plugin should be one version.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (SUREFIRE-1484) maven-clean-plugin should be used in integration test resource junit-pathWithUmlaut

[Tibor Digana (JIRA)]

Tibor Digana created SUREFIRE-1484:
--

 Summary: maven-clean-plugin should be used in integration test 
resource junit-pathWithUmlaut
 Key: SUREFIRE-1484
 URL: https://issues.apache.org/jira/browse/SUREFIRE-1484
 Project: Maven Surefire
  Issue Type: Task
Reporter: Tibor Digana
 Fix For: 2.21.0


By mistake the m-clean-p was added in another IT: {{crash-during-test}}.
It needs to be moved to {{junit-pathWithUmlaut}}.
The point is to properly delete target which contains language mutation in a 
directory name using the latest version of m-clean-p.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (SUREFIRE-1483) Disable Jenkins Agent

[Tibor Digana (JIRA)]

Tibor Digana created SUREFIRE-1483:
--

 Summary: Disable Jenkins Agent
 Key: SUREFIRE-1483
 URL: https://issues.apache.org/jira/browse/SUREFIRE-1483
 Project: Maven Surefire
  Issue Type: Task
Reporter: Tibor Digana
 Fix For: 2.21.0


Use {{JENKINS_MAVEN_AGENT_DISABLED}} in Surefire, Failsafe and Invoker plugin 
configuration as it is done in:

https://github.com/apache/maven-parent/commit/9c3213c8a5aa7441bc1e79376d3a3b901eaca2a2

Add a comment:


All reason was reported in Jenkins Jira:
https://issues.jenkins-ci.org/browse/JENKINS-49614



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (MNG-6367) maven installation insecure

[Warren MacEvoy (JIRA)]

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

Warren MacEvoy updated MNG-6367:

Description: 
The recommended install suggests using an insecure mirror, and then provides 
either an md5 sum (completely insecure, broken a thousand years ago), or a gpg 
signature (99% of installers will give up on following these directions, since 
they provide incomplete instructions on how to actually do it, and it is not 
easy to do).

Please provide a SHA256 sum with your distribution!   Please remove the MD5 sum 
which is dangerous (provides a false sense of security).  Please provide a 
complete recipe for verifying a signature using GnuPG 

This bug affects all versions.  Here is the very unsatisfying result of 
verifying using GPG:

*gpg --verify $FILE.asc*

gpg: assuming signed data in `apache-maven-3.5.2-bin.tar.gz'

gpg: Signature made Wed 18 Oct 2017 01:59:56 AM MDT using DSA key ID B620D787

gpg: Good signature from "Stephen Connolly "

gpg: WARNING: This key is not certified with a trusted signature!

gpg:          There is no indication that the signature belongs to the owner. 

 

 

  was:
The recommended install suggests using an insecure mirror, and then provides 
either an md5 sum (completely insecure, broken a thousand years ago), or a gpg 
signature (99% of installers will give up on following these directions, since 
they provide incomplete instructions on how to actually do it, and it is not 
easy to do).

Please provide a SHA256 sum with your distribution!   Please remove the MD5 sum 
which is dangerous (provides a false sense of security).  Please provide a 
complete recipe for verifying a signature using GnuPG 

This bug affects all versions

 

 

 


> maven installation insecure
> ---
>
> Key: MNG-6367
> URL: https://issues.apache.org/jira/browse/MNG-6367
> Project: Maven
>  Issue Type: Bug
>  Components: Artifacts and Repositories, Bootstrap  Build, 
> Documentation: Guides
>Affects Versions: 3.5.2
>Reporter:  Warren MacEvoy
>Priority: Major
>
> The recommended install suggests using an insecure mirror, and then provides 
> either an md5 sum (completely insecure, broken a thousand years ago), or a 
> gpg signature (99% of installers will give up on following these directions, 
> since they provide incomplete instructions on how to actually do it, and it 
> is not easy to do).
> Please provide a SHA256 sum with your distribution!   Please remove the MD5 
> sum which is dangerous (provides a false sense of security).  Please provide 
> a complete recipe for verifying a signature using GnuPG 
> This bug affects all versions.  Here is the very unsatisfying result of 
> verifying using GPG:
> *gpg --verify $FILE.asc*
> gpg: assuming signed data in `apache-maven-3.5.2-bin.tar.gz'
> gpg: Signature made Wed 18 Oct 2017 01:59:56 AM MDT using DSA key ID B620D787
> gpg: Good signature from "Stephen Connolly "
> gpg: WARNING: This key is not certified with a trusted signature!
> gpg:          There is no indication that the signature belongs to the owner. 
>  
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (ARCHETYPE-541) Custom properties not used in pom.xml in root directory when using archetype:create-from-project

[Erwan LEGELEUX (JIRA)]

Erwan LEGELEUX created ARCHETYPE-541:


 Summary: Custom properties not used in pom.xml in root directory 
when using archetype:create-from-project
 Key: ARCHETYPE-541
 URL: https://issues.apache.org/jira/browse/ARCHETYPE-541
 Project: Maven Archetype
  Issue Type: Bug
Reporter: Erwan LEGELEUX
 Attachments: test-archetype.zip

Hi,

I've got an issue when I am trying to use custom properties with 
archetype:create-from-project plugin in pom.xml in root directory.

If you try to execute following command : 

mvn archetype:create-from-project -Darchetype.properties=custom.properties

You will see that README.txt file has been process with my custom properties, 
BUT not in pom.xml file.

 

Thanks a lot for your help,

 

Regards

 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MJDEPS-11) Introduce --multi-release option

[Hudson (JIRA)]

[ 
https://issues.apache.org/jira/browse/MJDEPS-11?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16372070#comment-16372070
 ] 

Hudson commented on MJDEPS-11:
--

Build succeeded in Jenkins: Maven TLP » maven-jdeps-plugin » master #6

See https://builds.apache.org/job/maven-box/job/maven-jdeps-plugin/job/master/6/

> Introduce --multi-release option
> 
>
> Key: MJDEPS-11
> URL: https://issues.apache.org/jira/browse/MJDEPS-11
> Project: Maven JDeps Plugin
>  Issue Type: New Feature
>Reporter: Naman Nigam
>Assignee: Robert Scholte
>Priority: Minor
> Fix For: 3.1.1
>
>
> A minimal reproducible example for this has been posted at 
> [Stackoverflow#46662286|https://stackoverflow.com/questions/46662286/error-log4j-api-2-9-0-jar-is-a-multi-release-jar-file-but-multi-release-optio]
> Where the `jdeps` tool returns 
> {{Error: log4j-api-2.9.0.jar is a multi-release jar file but --multi-release 
> option is not set}}
> while the jdeps-plugin finally results into 
> {noformat}
> bq. INFO] Error: log4j-api-2.9.0.jar is a multi-release jar file but 
> --multi-release option is not set
> bq. [INFO] 
> 
> bq. [INFO] BUILD FAILURE
> bq. [INFO] 
> 
> bq. [INFO] Total time: 3.389 s
> bq. [INFO] Finished at: ...
> bq. [INFO] Final Memory: 12M/41M
> bq. [INFO] 
> 
> bq. [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-jdeps-plugin:3.1.0:jdkinternals (default) on 
> project maven-jigsaw: 
> bq. [ERROR] Exit code: 2
> bq. [ERROR] Command line was: /bin/sh -c 
> '/Library/Java/JavaVirtualMachines/jdk-9.jdk/Contents/Home/bin/jdeps' '-cp' 
> '.../.m2/repository/org/apache/logging/log4j/log4j-api/2.9.0/log4j-api-2.9.0.jar'
>  '../maven/target/classes'
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Closed] (MJDEPS-11) Introduce --multi-release option

[Robert Scholte (JIRA)]

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

Robert Scholte closed MJDEPS-11.

   Resolution: Fixed
 Assignee: Robert Scholte
Fix Version/s: 3.1.1

Fixed in 
[8d700b4b95a2d89706786169f999f5d63405f33c|https://gitbox.apache.org/repos/asf?p=maven-jdeps-plugin.git;a=commit;h=8d700b4b95a2d89706786169f999f5d63405f33c]

> Introduce --multi-release option
> 
>
> Key: MJDEPS-11
> URL: https://issues.apache.org/jira/browse/MJDEPS-11
> Project: Maven JDeps Plugin
>  Issue Type: New Feature
>Reporter: Naman Nigam
>Assignee: Robert Scholte
>Priority: Minor
> Fix For: 3.1.1
>
>
> A minimal reproducible example for this has been posted at 
> [Stackoverflow#46662286|https://stackoverflow.com/questions/46662286/error-log4j-api-2-9-0-jar-is-a-multi-release-jar-file-but-multi-release-optio]
> Where the `jdeps` tool returns 
> {{Error: log4j-api-2.9.0.jar is a multi-release jar file but --multi-release 
> option is not set}}
> while the jdeps-plugin finally results into 
> {noformat}
> bq. INFO] Error: log4j-api-2.9.0.jar is a multi-release jar file but 
> --multi-release option is not set
> bq. [INFO] 
> 
> bq. [INFO] BUILD FAILURE
> bq. [INFO] 
> 
> bq. [INFO] Total time: 3.389 s
> bq. [INFO] Finished at: ...
> bq. [INFO] Final Memory: 12M/41M
> bq. [INFO] 
> 
> bq. [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-jdeps-plugin:3.1.0:jdkinternals (default) on 
> project maven-jigsaw: 
> bq. [ERROR] Exit code: 2
> bq. [ERROR] Command line was: /bin/sh -c 
> '/Library/Java/JavaVirtualMachines/jdk-9.jdk/Contents/Home/bin/jdeps' '-cp' 
> '.../.m2/repository/org/apache/logging/log4j/log4j-api/2.9.0/log4j-api-2.9.0.jar'
>  '../maven/target/classes'
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MJDEPS-9) Introduce failOnWarning as a named property

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/MJDEPS-9?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16372061#comment-16372061
 ] 

ASF GitHub Bot commented on MJDEPS-9:
-

Github user mattnelson closed the pull request at:

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


> Introduce failOnWarning as a named property
> ---
>
> Key: MJDEPS-9
> URL: https://issues.apache.org/jira/browse/MJDEPS-9
> Project: Maven JDeps Plugin
>  Issue Type: New Feature
>Reporter: Matt Nelson
>Assignee: Robert Scholte
>Priority: Minor
> Fix For: 3.1.1
>
>
> Introduce {{jdeps.failOnWarning}} named property to support command line and 
> {{}} declarations.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Closed] (MJDEPS-9) Introduce failOnWarning as a named property

[Robert Scholte (JIRA)]

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

Robert Scholte closed MJDEPS-9.
---
   Resolution: Fixed
 Assignee: Robert Scholte
Fix Version/s: 3.1.1

Fixed in 
[77bbb583496c9dc83d2e69f84ba87ea19b665be4|https://gitbox.apache.org/repos/asf?p=maven-jdeps-plugin.git;a=commit;h=77bbb583496c9dc83d2e69f84ba87ea19b665be4]

> Introduce failOnWarning as a named property
> ---
>
> Key: MJDEPS-9
> URL: https://issues.apache.org/jira/browse/MJDEPS-9
> Project: Maven JDeps Plugin
>  Issue Type: New Feature
>Reporter: Matt Nelson
>Assignee: Robert Scholte
>Priority: Minor
> Fix For: 3.1.1
>
>
> Introduce {{jdeps.failOnWarning}} named property to support command line and 
> {{}} declarations.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MJDEPS-9) Introduce failOnWarning as a named property

[Hudson (JIRA)]

[ 
https://issues.apache.org/jira/browse/MJDEPS-9?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16372058#comment-16372058
 ] 

Hudson commented on MJDEPS-9:
-

Build succeeded in Jenkins: Maven TLP » maven-jdeps-plugin » master #5

See https://builds.apache.org/job/maven-box/job/maven-jdeps-plugin/job/master/5/

> Introduce failOnWarning as a named property
> ---
>
> Key: MJDEPS-9
> URL: https://issues.apache.org/jira/browse/MJDEPS-9
> Project: Maven JDeps Plugin
>  Issue Type: New Feature
>Reporter: Matt Nelson
>Assignee: Robert Scholte
>Priority: Minor
> Fix For: 3.1.1
>
>
> Introduce {{jdeps.failOnWarning}} named property to support command line and 
> {{}} declarations.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MJDEPS-7) jdeps:(test-)jdkinternals is always in verbose mode

[Robert Scholte (JIRA)]

[ 
https://issues.apache.org/jira/browse/MJDEPS-7?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16372040#comment-16372040
 ] 

Robert Scholte commented on MJDEPS-7:
-

It requires verbose mode to be able to do the analysis. So the plugin cannot 
use the verbose flags of the jdeps tools. 
There's a consumer, which reads per line the output to the console, so it is 
streaming. Maybe we can do some buffering here in order to try to reduce the 
output.

> jdeps:(test-)jdkinternals is always in verbose mode
> ---
>
> Key: MJDEPS-7
> URL: https://issues.apache.org/jira/browse/MJDEPS-7
> Project: Maven JDeps Plugin
>  Issue Type: Bug
>Affects Versions: 3.0.0
>Reporter: Andreas Sewe
>Priority: Major
>
> AFAICT, the {{jdeps:(test-)jdkinternals}} goals always operate in some 
> {{verbose}} mode. If no use of internal APIs is detected, I would expect that 
> the plugin (with its default, i.e., not {{}} {{}}) to 
> see very little output. Instead, I get output that looks like it has been 
> generated by {{-verbose:package}}.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MJDEPS-10) Error: unknown option: -M while using module option of maven-jdeps-plugin

[Hudson (JIRA)]

[ 
https://issues.apache.org/jira/browse/MJDEPS-10?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16372034#comment-16372034
 ] 

Hudson commented on MJDEPS-10:
--

Build succeeded in Jenkins: Maven TLP » maven-jdeps-plugin » master #4

See https://builds.apache.org/job/maven-box/job/maven-jdeps-plugin/job/master/4/

> Error: unknown option: -M while using module option of maven-jdeps-plugin
> -
>
> Key: MJDEPS-10
> URL: https://issues.apache.org/jira/browse/MJDEPS-10
> Project: Maven JDeps Plugin
>  Issue Type: Bug
>Reporter: Naman Nigam
>Assignee: Robert Scholte
>Priority: Major
> Fix For: 3.1.1
>
>
> Moving this from 
> [StackOverflow#46727928|https://stackoverflow.com/questions/46727928/error-unknown-option-m-while-using-module-option-of-maven-jdeps-plugin]
> Using minimal pom.xml with Java9 as -
> {code:xml}
> 
> org.apache.maven.plugins
> maven-jdeps-plugin
> 3.1.0
> 
> true
> 
> 
> 
> 
> jdkinternals 
> test-jdkinternals 
> 
> 
> 
> 
> {code}
> Results into 
> {noformat}
> Error: unknown option: -M
> Usage: jdeps  ]
> use -h, -?, -help, or --help for a list of possible options
> {noformat}
> Also, {{-m / --module }} in the tool I can see are 
> used to specify the root module for analysis..would this also need a change 
> in Type of the attribute? (not aware of what was the initial construct of the 
> tool used to be)



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Closed] (MJDEPS-10) Error: unknown option: -M while using module option of maven-jdeps-plugin

[Robert Scholte (JIRA)]

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

Robert Scholte closed MJDEPS-10.

   Resolution: Fixed
 Assignee: Robert Scholte
Fix Version/s: 3.1.1

Fixed in 
[ea44fad322aa62fce130c4a46fa5fea8e7870328|https://gitbox.apache.org/repos/asf?p=maven-jdeps-plugin.git;a=commit;h=ea44fad322aa62fce130c4a46fa5fea8e7870328]

> Error: unknown option: -M while using module option of maven-jdeps-plugin
> -
>
> Key: MJDEPS-10
> URL: https://issues.apache.org/jira/browse/MJDEPS-10
> Project: Maven JDeps Plugin
>  Issue Type: Bug
>Reporter: Naman Nigam
>Assignee: Robert Scholte
>Priority: Major
> Fix For: 3.1.1
>
>
> Moving this from 
> [StackOverflow#46727928|https://stackoverflow.com/questions/46727928/error-unknown-option-m-while-using-module-option-of-maven-jdeps-plugin]
> Using minimal pom.xml with Java9 as -
> {code:xml}
> 
> org.apache.maven.plugins
> maven-jdeps-plugin
> 3.1.0
> 
> true
> 
> 
> 
> 
> jdkinternals 
> test-jdkinternals 
> 
> 
> 
> 
> {code}
> Results into 
> {noformat}
> Error: unknown option: -M
> Usage: jdeps  ]
> use -h, -?, -help, or --help for a list of possible options
> {noformat}
> Also, {{-m / --module }} in the tool I can see are 
> used to specify the root module for analysis..would this also need a change 
> in Type of the attribute? (not aware of what was the initial construct of the 
> tool used to be)



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (MSHARED-680) Add null check for DependencyResolver/DependencyCollector/ProjectDeployer Interfaces

[Karl Heinz Marbaise (JIRA)]

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

Karl Heinz Marbaise updated MSHARED-680:

Summary: Add null check for 
DependencyResolver/DependencyCollector/ProjectDeployer Interfaces  (was: Add 
null check for DependencyResolver Interface)

> Add null check for DependencyResolver/DependencyCollector/ProjectDeployer 
> Interfaces
> 
>
> Key: MSHARED-680
> URL: https://issues.apache.org/jira/browse/MSHARED-680
> Project: Maven Shared Components
>  Issue Type: Improvement
>  Components: maven-artifact-transfer
>Affects Versions: maven-artifact-transfer-1.0.0
>Reporter: Karl Heinz Marbaise
>Assignee: Karl Heinz Marbaise
>Priority: Minor
>
> * Null Check for DependencyCollector
> * Null Check for ProjectDeployer 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (SUREFIRE-1482) Obsolete workaround with commons-lang3 in project unit tests

[Tibor Digana (JIRA)]

Tibor Digana created SUREFIRE-1482:
--

 Summary: Obsolete workaround with commons-lang3 in project unit 
tests
 Key: SUREFIRE-1482
 URL: https://issues.apache.org/jira/browse/SUREFIRE-1482
 Project: Maven Surefire
  Issue Type: Task
Reporter: Tibor Digana
 Fix For: 2.21.0


We are not calling the method {{isJavaVersioAtLeast}} in all code and we do not 
need to use {{commons-lang3:3.7}} in test class path.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (MSHARED-680) Add null check for DependencyResolver Interface

[Karl Heinz Marbaise (JIRA)]

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

Karl Heinz Marbaise updated MSHARED-680:

Description: 
* Null Check for DependencyCollector
* Null Check for ProjectDeployer 

> Add null check for DependencyResolver Interface
> ---
>
> Key: MSHARED-680
> URL: https://issues.apache.org/jira/browse/MSHARED-680
> Project: Maven Shared Components
>  Issue Type: Improvement
>  Components: maven-artifact-transfer
>Affects Versions: maven-artifact-transfer-1.0.0
>Reporter: Karl Heinz Marbaise
>Assignee: Karl Heinz Marbaise
>Priority: Minor
>
> * Null Check for DependencyCollector
> * Null Check for ProjectDeployer 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] Tunaki commented on issue #12: Add @Generated annotation to Mojo

[GitBox]

Tunaki commented on issue #12: Add @Generated annotation to Mojo
URL: https://github.com/apache/maven-plugin-tools/pull/12#issuecomment-367468113
 
 
   Unfortunately, I'm not sure if this solves more problems than it creates... 
There are lots of issues with this annotation and Java 9 for tools that read 
Java source code. I just tried adding it and then generating the Javadoc of a 
plugin, it failed with:
   
   ```
   [ERROR] import javax.annotation.Generated;
   [ERROR] ^
   [ERROR]   (package javax.annotation is declared in module 
java.xml.ws.annotation, which is not in the module graph)
   [ERROR]
   [ERROR] Command line was: "C:\Program Files\Java\jdk-9.0.1\bin\javadoc.exe" 
@options @packages
   ```
   
   There is also a new 
[`javax.annotation.processing.Generated`](https://docs.oracle.com/javase/9/docs/api/javax/annotation/processing/Generated.html)
 annotation since Java 9...
   
   In any case, if something should be done here, modular compatibility is 
priority.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[jira] [Commented] (MNGSITE-300) Version order not documented

[Robert Scholte (JIRA)]

[ 
https://issues.apache.org/jira/browse/MNGSITE-300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16371995#comment-16371995
 ] 

Robert Scholte commented on MNGSITE-300:


Typos have been fixed and published. Thanks for reporting.

> Version order not documented
> 
>
> Key: MNGSITE-300
> URL: https://issues.apache.org/jira/browse/MNGSITE-300
> Project: Maven Project Web Site
>  Issue Type: Bug
>Reporter: Jon Harper
>Assignee: Robert Scholte
>Priority: Major
> Attachments: doc-version-order-image.png, doc-version-order.patch
>
>
> Documenting the version order. I don't know how many exemples should go there 
> because there are tons of counter intuitive version orders. Feel free to 
> discuss.
> Also, this was the most concise way I found to document the existing 
> behavior, but it could be explained differently.
> Created issue as suggested by hervé boutemy.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Comment Edited] (MJAVADOC-514) Maven Javadoc Plugin can't get dependency from third party maven repository

[Justin Wu (JIRA)]

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

Justin Wu edited comment on MJAVADOC-514 at 2/21/18 8:49 PM:
-

Tried on old version 2.10.4, it only searches my own maven repository , 
complains some library like log4j is not found:

 

[ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-javadoc-plugin:2.10.4:jar (attach-javadoc) on 
project myProject: MavenReportException: Error while generating Javadoc: Unable 
to find artifact:groupId = 'log4j'
 [ERROR] artifactId = 'log4j'
 [ERROR] version = '1.2.17': Failure to find log4j:log4j:bundle:1.2.17 in 
[http://my_maven_server:8081/nexus/content/repositories/releases/] was cached 
in the local
repository, resolution will not be reattempted until the update interval of 
main has elapsed or updates are forced


was (Author: wuyg719):
Tried on old version 2.10.4, it only searches my own maven repository , 
complains some library like log4j is not found:

 

[ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-javadoc-plugin:2.10.4:jar (attach-javadoc) on 
project myProject: MavenReportException: Error whil
nerating Javadoc: Unable to find artifact:groupId = 'log4j'
[ERROR] artifactId = 'log4j'
[ERROR] version = '1.2.17': Failure to find log4j:log4j:bundle:1.2.17 in 
http://my_maven_server:8081/nexus/content/repositories/releases/ was cached in 
the local
sitory, resolution will not be reattempted until the update interval of main 
has elapsed or updates are forced

> Maven Javadoc Plugin can't get dependency from third party maven repository
> ---
>
> Key: MJAVADOC-514
> URL: https://issues.apache.org/jira/browse/MJAVADOC-514
> Project: Maven Javadoc Plugin
>  Issue Type: Bug
> Environment: maven 3.2.x
>Reporter: Justin Wu
>Priority: Major
>
> I had a Jar is saved in my own maven repository which is runing on Nexus.
> It works well if it is a normal maven dependency.
> but it fails if I declare it in Maven Javadoc Plugin:
>  
> [INFO] --- maven-javadoc-plugin:3.0.0:jar (attach-javadoc) @ treaty ---
> Downloading: 
> https://repo.maven.apache.org/maven2/com/mycompany/util/object-tree-creator/1.0/object-tree-creator-1.0.pom
> [WARNING] The POM for com.mycompany.util:object-tree-creator:jar:1.0 is 
> missing, no dependency information available
> Downloading: 
> +[https://repo.maven.apache.org/maven2/com/mycompany/util/object-tree-creator/1.0/object-tree-creator-1.0.jar|https://repo.maven.apache.org/maven2/com/validusre/util/object-tree-creator/1.0/object-tree-creator-1.0.jar]+
>  
>  
> This is my code:
>  
> 
>  org.apache.maven.plugins
>  maven-javadoc-plugin
>  3.0.0
>  
>  bm.mycompany.common.doclet.MyDoclet
> ${project.build.directory}/../../shared-java/target/classes;${project.build.directory}/classes
>  
> ${project.build.directory}/../../shared-java/src/java;${project.build.directory}/../src/java
>  UTF-8
>  public
>  com.mycompany.api
>  false
>  
>  
>  
>  
>  javax.ws.rs
>  javax.ws.rs-api
>  2.0.1
>  
>  
>  javax.servlet
>  servlet-api
>  2.5
>  
>  
>  
>  com.mycompany.util
>  object-tree-creator
>  1.0
>  
>  
>  
> ...



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (SCM-861) connectionUrl and developerConnectionUrl does not work when within execution tag

[JIRA]

[ 
https://issues.apache.org/jira/browse/SCM-861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16371924#comment-16371924
 ] 

Guillaume Boué commented on SCM-861:


This is expected. When you're running {{mvn scm:export}}, your {{ROOT}} 
execution is not being used, instead it is a default one that is used. In the 
first case, {{connectionUrl}} is set in the configuration of all executions, so 
it is also used by the default one. However in the second case, only {{ROOT}} 
execution has the {{connectionUrl}} set.

Since Maven 3.3.1, you could use {{mvn scm:export@ROOT}} in the second case.

> connectionUrl and developerConnectionUrl does not work when within execution 
> tag
> 
>
> Key: SCM-861
> URL: https://issues.apache.org/jira/browse/SCM-861
> Project: Maven SCM
>  Issue Type: Bug
>  Components: maven-plugin
>Affects Versions: 1.9.5
>Reporter: Daniel Diehl
>Priority: Major
>
> The connectionUrl and developerConnectionUrl works properly when not tied to 
> an execution tag. But Fails when within one execution tag.
> This works:
>  
> {code:java}
> 
>org.apache.maven.plugins
>maven-scm-plugin
>1.9.5
>
>   scm:svn:http://myhost/svn/publicResources
>   false
>   true
>   connection
>   ${basedir}/target/externalResources
>
> 
> {code}
>  
> And This does not work:
> {code:java}
> 
>org.apache.maven.plugins
>maven-scm-plugin
>1.9.5
>
>   
>  ROOT
>  
> export
>  
>  
> 
> scm:svn:http://myhost/svn/publicResources
> false
> true
> connection
> 
> ${basedir}/target/externalResources
>  
>   
>
> 
> {code}
> executing: _mvn scm:export._
>  
> The run within execution tags uses the default value instead of connectionUrl.
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (SCM-868) gitexe add() does not return added files when invoked in subdir

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/SCM-868?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16371811#comment-16371811
 ] 

ASF GitHub Bot commented on SCM-868:


GitHub user basinilya opened a pull request:

https://github.com/apache/maven-scm/pull/66

[SCM-868] fix gitexe cannot deduce relative path



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

$ git pull https://github.com/basinilya/maven-scm SCM-868

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

https://github.com/apache/maven-scm/pull/66.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 #66


commit 23e7fd0722823693486410cf4f2c1ce05bc35fc0
Author: Ilya Basin 
Date:   2018-02-21T18:22:32Z

[SCM-868] fix gitexe cannot deduce relative path




> gitexe add() does not return added files when invoked in subdir
> ---
>
> Key: SCM-868
> URL: https://issues.apache.org/jira/browse/SCM-868
> Project: Maven SCM
>  Issue Type: Bug
>  Components: maven-scm-provider-gitexe
>Affects Versions: 1.9.5, 1.9.6
>Reporter: Ilya Basin
>Priority: Major
>
> I'm going to add a wagon-scm test suite for git. One of the test cases is 
> calling the GitAddCommand command with:
> {code:java}
> repo: 
> file:///C:/progs/maven/maven-wagon/wagon-providers/wagon-scm/target/test-classes/test-repo-git-test/
> fileSet: basedir = 
> C:\Users\basin\AppData\Local\Temp\wagon-scm2020146470.checkout\file-list; 
> files = [test-resource.txt]{code}
> After adding the files the command internally calls "git rev-parse 
> --show-toplevel" which prints:
> {code:java}
> C:/Users/basin/AppData/Local/Temp/wagon-scm2020146470.checkout{code}
> And on the next line it tries to do (pseudo code):
> {code:java}
> ("file:/C:/Users/basin/AppData/Local/Temp/wagon-scm1144102340.checkout/file-list/").relativize(URI.create(
> "C:/Users/basin/AppData/Local/Temp/wagon-scm2020146470.checkout")){code}
> This is so wrong! What were those people from SCM-709 trying to get? A double 
> dot ".."? The argument to the relativize() method MUST be a child, not a 
> parent, otherwise the argument is returned unchanged.
> There are so many reasons why getting an absolute path from git is a bad 
> idea: Symlinks, Windows paths.
> Nevertheless, there's a simple solution. The original problem was that "git 
> status --porcelain" printed paths relative to the top level instead of 
> relative to the base dir.
> So we should just call 
> {code}
> git rev-parse --show-prefix
> {code} instead of "show-toplevel" and strip this prefix from the paths 
> printed by "git status"



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MJAVADOC-427) "Error fetching URL" for valid non-Java API links

[Matt Nelson (JIRA)]

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

Matt Nelson commented on MJAVADOC-427:
--

Logged MJAVADOC-487 for this same issue.
 
Can JavadocUtil[1] and AbstractJavadocMojo[2] be enhanced to handle the 
redirect before handing the URI off to the javadoc tool?

[1] 
https://github.com/apache/maven-javadoc-plugin/blob/12dbbde29cf6277ca311cb8afffdf02dbfe0c9b4/src/main/java/org/apache/maven/plugins/javadoc/JavadocUtil.java#L1789
[2] 
https://github.com/apache/maven-javadoc-plugin/blob/12dbbde29cf6277ca311cb8afffdf02dbfe0c9b4/src/main/java/org/apache/maven/plugins/javadoc/AbstractJavadocMojo.java#L5883

> "Error fetching URL" for valid non-Java API links
> -
>
> Key: MJAVADOC-427
> URL: https://issues.apache.org/jira/browse/MJAVADOC-427
> Project: Maven Javadoc Plugin
>  Issue Type: Bug
>Affects Versions: 2.10.3
> Environment: Windows 7
> Apache Maven 3.2.1
> java version "1.8.0_05"
> Java(TM) SE Runtime Environment (build 1.8.0_05-b13)
> Java HotSpot(TM) 64-Bit Server VM (build 25.5-b02, mixed mode)
>Reporter: Selena Renee Phillips
>Priority: Major
> Attachments: testcase-detectLinks-enabled-no-manual-link-config.zip, 
> testcase-detectLinks-enabled-with-manual-link-config-no-trailing-slash.zip, 
> testcase-detectLinks-enabled-with-manual-link-config-trailing-slash.zip, 
> testcases-detectLinks-disabled-with-manual-link-config-no-trailing-slash.zip, 
> testcases-detectLinks-disabled-with-manual-link-config-trailing-slash.zip
>
>
> When I generate Javadoc for a simple project with 3rd party dependencies, no 
> configuration generates links for these dependencies. For valid Javadoc links 
> which have a package-list, I get the following error:
> [WARNING] javadoc: warning - Error fetching URL
> Test Cases w/ results (sample project(s)) attached:
> *1. No manual link configuration. 'detectLinks' is set to true.*
> {code:title=pom.xml - No manual link configuration with 
> detectLinks=true|borderStyle=solid}
> 
> org.apache.maven.plugins
> maven-javadoc-plugin
> 2.10.3
> 
> 
> ${project.basedir}/target
> javadoc
> Epiphany
> Epiphany
> private
> true
> true
> true
> true
> 
> 
> 
> 
> javadoc
> test-javadoc
> 
> 
> 
> 
> {code}
> Output of 'mvn javadoc:javadoc':
> {code:title=Resulting output for mvn javadoc:javadoc - No manual link 
> configuration with detectLinks=true|borderStyle=solid}
> [INFO] Scanning for projects...
> [INFO]
> [INFO] Using the builder 
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder
>  with a thread count of 1
> [INFO]
> [INFO] 
> 
> [INFO] Building epiphany 1.0-SNAPSHOT
> [INFO] 
> 
> [INFO]
> [INFO] >>> maven-javadoc-plugin:2.10.3:javadoc (default-cli) @ epiphany >>>
> [INFO]
> [INFO] <<< maven-javadoc-plugin:2.10.3:javadoc (default-cli) @ epiphany <<<
> SNIP DOWNLOADING INFO.
> [INFO]
> [INFO] --- maven-javadoc-plugin:2.10.3:javadoc (default-cli) @ epiphany ---
> [ERROR] Error fetching link: 
> http://selenium.googlecode.com/selenium-java/apidocs/package-list. Ignored it.
> [ERROR] Error fetching link: 
> http://selenium.googlecode.com/selenium-api/apidocs/package-list. Ignored it.
> [ERROR] Error fetching link: 
> http://selenium.googlecode.com/selenium-support/apidocs/package-list. Ignored 
> it.
> [ERROR] Error fetching link: 
> http://code.google.com/p/guava-libraries/guava/apidocs/package-list. Ignored 
> it.
> [ERROR] Error fetching link: 
> http://logback.qos.ch/logback-core/apidocs/package-list. Ignored it.
> [ERROR] Error fetching link: 
> http://logback.qos.ch/logback-classic/apidocs/package-list. Ignored it.
> [ERROR] Error fetching link: http://testng.org/apidocs/package-list. Ignored 
> it.
> [INFO]
> Loading source files for package com.example...
> Constructing Javadoc information...
> Standard Doclet version 1.8.0_05
> Building tree for all the packages and classes...
> Generating 
> C:\Users\sephilli\git\javadoc-bug\target\javadoc\com\example\AbstractLoadable.html...
> .SNIP
> 1 warning
> [WARNING] Javadoc Warnings
> [WARNING] javadoc: warning - Error fetching URL: http://www.slf4j.org/apidocs
> [INFO] 
> 

[jira] [Created] (MNG-6367) maven installation insecure

[Warren MacEvoy (JIRA)]

 Warren MacEvoy created MNG-6367:


 Summary: maven installation insecure
 Key: MNG-6367
 URL: https://issues.apache.org/jira/browse/MNG-6367
 Project: Maven
  Issue Type: Bug
  Components: Artifacts and Repositories, Bootstrap  Build, 
Documentation: Guides
Affects Versions: 3.5.2
Reporter:  Warren MacEvoy


The recommended install suggests using an insecure mirror, and then provides 
either an md5 sum (completely insecure, broken a thousand years ago), or a gpg 
signature (99% of installers will give up on following these directions, since 
they provide incomplete instructions on how to actually do it, and it is not 
easy to do).

Please provide a SHA256 sum with your distribution!   Please remove the MD5 sum 
which is dangerous (provides a false sense of security).  Please provide a 
complete recipe for verifying a signature using GnuPG 

This bug affects all versions

 

 

 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MSHARED-679) Make all classes package private in internal package

[Hudson (JIRA)]

[ 
https://issues.apache.org/jira/browse/MSHARED-679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16371930#comment-16371930
 ] 

Hudson commented on MSHARED-679:


Build succeeded in Jenkins: Maven TLP » maven-artifact-transfer » 
MSHARED-679-package-private #8

See 
https://builds.apache.org/job/maven-box/job/maven-artifact-transfer/job/MSHARED-679-package-private/8/

> Make all classes package private in internal package
> 
>
> Key: MSHARED-679
> URL: https://issues.apache.org/jira/browse/MSHARED-679
> Project: Maven Shared Components
>  Issue Type: Improvement
>  Components: maven-artifact-transfer
>Affects Versions: maven-artifact-transfer-0.9.1
>Reporter: Karl Heinz Marbaise
>Priority: Minor
> Fix For: maven-artifact-transfer-1.0.0
>
>
> Make all classes in package {{*.internal}} package only visible and not 
> public.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Comment Edited] (MASSEMBLY-775) Emit WARNING instead of ERROR

[Gordon Pettey (JIRA)]

[ 
https://issues.apache.org/jira/browse/MASSEMBLY-775?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16371826#comment-16371826
 ] 

Gordon Pettey edited comment on MASSEMBLY-775 at 2/21/18 6:53 PM:
--

It's not checking "a path starting with / on a Windows system". Every one of 
those checks is for the *destination* path. It's checking a path starting with 
/ as the target path in the assembled archive, which is utter nonsense. The 
zip/tar/whatever file isn't ever going to have "Windows" paths with drive 
letters in it (and if you supplied one as a target path, I suspect the archiver 
code is going to barf an exception at you - no need to duplicate a check in the 
assembly plugin). {{/}} is the appropriate way to specify the root directory of 
the target archive.


was (Author: gpettey):
It's not checking "a path starting with / on a Windows system". It's checking a 
path starting with / as the target path in the assembled archive, which is 
utter nonsense. The zip/tar/whatever file isn't ever going to have "Windows" 
paths with drive letters in it. {{/}} is the appropriate way to specify the 
root directory of the archive.

> Emit WARNING instead of ERROR
> -
>
> Key: MASSEMBLY-775
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-775
> Project: Maven Assembly Plugin
>  Issue Type: Improvement
>Affects Versions: 2.5.5
>Reporter: Karl Heinz Marbaise
>Priority: Minor
>
> I have currently a build which creates several tar/tar.gz/zip archives etc.
> {code}
> [INFO] Reading assembly descriptor: src/main/assembly/descriptor-inner-tar.xml
> [INFO] Reading assembly descriptor: src/main/assembly/descriptor.xml
> [INFO] Building tar: C:\...\xyz-X.y.z-SNAPSHOT-dist.tar
> [ERROR] OS=Windows and the assembly descriptor contains a *nix-specific 
> root-relative-reference (starting with slash) /
> [ERROR] OS=Windows and the assembly descriptor contains a *nix-specific 
> root-relative-reference (starting with slash) /
> {code}
> In my opinion the message could be a WARNING instead of an error ? WDYT ?



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MCHECKSTYLE-344) StringIndexOutOfBoundsException in RuleUtil

[Jonathan Haber (JIRA)]

[ 
https://issues.apache.org/jira/browse/MCHECKSTYLE-344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16371903#comment-16371903
 ] 

Jonathan Haber commented on MCHECKSTYLE-344:


I just wanted to report that we're also experiencing this issue in our codebase 
and that the PR James sent looks good to me.

> StringIndexOutOfBoundsException in RuleUtil
> ---
>
> Key: MCHECKSTYLE-344
> URL: https://issues.apache.org/jira/browse/MCHECKSTYLE-344
> Project: Maven Checkstyle Plugin
>  Issue Type: Bug
>  Components: checkstyle:check
>Affects Versions: 2.17
>Reporter: fdvxxii
>Priority: Major
>
> {{RuleUtil}} has a bug at line 95:
> {code}
>   final int end = eventSrcName.lastIndexOf('.');
>   eventSrcName = eventSrcName.substring(0, end);  
> {code}
> This code leads to a StringIndexOutOfBoundsException if the variable does not 
> contain a period. I don't know if its a convention to have a period in that 
> string, but either way the error message should me more expressive.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] maven-scm pull request #66: [SCM-868] fix gitexe cannot deduce relative path

[basinilya]

GitHub user basinilya opened a pull request:

https://github.com/apache/maven-scm/pull/66

[SCM-868] fix gitexe cannot deduce relative path



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

$ git pull https://github.com/basinilya/maven-scm SCM-868

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

https://github.com/apache/maven-scm/pull/66.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 #66


commit 23e7fd0722823693486410cf4f2c1ce05bc35fc0
Author: Ilya Basin 
Date:   2018-02-21T18:22:32Z

[SCM-868] fix gitexe cannot deduce relative path




---

[jira] [Created] (SCM-869) gitexe list() implemented incorrectly

[Ilya Basin (JIRA)]

Ilya Basin created SCM-869:
--

 Summary: gitexe list() implemented incorrectly
 Key: SCM-869
 URL: https://issues.apache.org/jira/browse/SCM-869
 Project: Maven SCM
  Issue Type: Bug
  Components: maven-scm-provider-gitexe
Affects Versions: 1.9.5, 1.9.6
Reporter: Ilya Basin


Taking the Svn implementation as a model, ScmProvider.list() should be 
implemented as follows:
 * The command must directly query the remote repository for files
 * A local working copy is unnecessary and if it doesn't exist, the remote 
repository must not be checked out.
 * fileSet.getBasedir() indicates where to run the scm binary. The recommended 
value is ".".
 * fileSet.getFileList() indicates the files to list
 * repository indicates the repo URL

Git (among other SCMs) does not support listing remote files, so the command 
should just fail.

For listing files in a working copy, users should call the ScmProvider.status() 
method instead.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (WAGON-501) gitexe unit test

[Ilya Basin (JIRA)]

Ilya Basin created WAGON-501:


 Summary: gitexe unit test
 Key: WAGON-501
 URL: https://issues.apache.org/jira/browse/WAGON-501
 Project: Maven Wagon
  Issue Type: New Feature
  Components: wagon-scm
Affects Versions: 3.0.0, 3.0.1
Reporter: Ilya Basin


Should add ScmGitExeWagonTest similar to Svn and Cvs



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MJAVADOC-514) Maven Javadoc Plugin can't get dependency from third party maven repository

[Justin Wu (JIRA)]

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

Justin Wu commented on MJAVADOC-514:


Tried on old version 2.10.4, it only searches my own maven repository , 
complains some library like log4j is not found:

 

[ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-javadoc-plugin:2.10.4:jar (attach-javadoc) on 
project myProject: MavenReportException: Error whil
nerating Javadoc: Unable to find artifact:groupId = 'log4j'
[ERROR] artifactId = 'log4j'
[ERROR] version = '1.2.17': Failure to find log4j:log4j:bundle:1.2.17 in 
http://my_maven_server:8081/nexus/content/repositories/releases/ was cached in 
the local
sitory, resolution will not be reattempted until the update interval of main 
has elapsed or updates are forced

> Maven Javadoc Plugin can't get dependency from third party maven repository
> ---
>
> Key: MJAVADOC-514
> URL: https://issues.apache.org/jira/browse/MJAVADOC-514
> Project: Maven Javadoc Plugin
>  Issue Type: Bug
> Environment: maven 3.2.x
>Reporter: Justin Wu
>Priority: Major
>
> I had a Jar is saved in my own maven repository which is runing on Nexus.
> It works well if it is a normal maven dependency.
> but it fails if I declare it in Maven Javadoc Plugin:
>  
> [INFO] --- maven-javadoc-plugin:3.0.0:jar (attach-javadoc) @ treaty ---
> Downloading: 
> https://repo.maven.apache.org/maven2/com/mycompany/util/object-tree-creator/1.0/object-tree-creator-1.0.pom
> [WARNING] The POM for com.mycompany.util:object-tree-creator:jar:1.0 is 
> missing, no dependency information available
> Downloading: 
> +[https://repo.maven.apache.org/maven2/com/mycompany/util/object-tree-creator/1.0/object-tree-creator-1.0.jar|https://repo.maven.apache.org/maven2/com/validusre/util/object-tree-creator/1.0/object-tree-creator-1.0.jar]+
>  
>  
> This is my code:
>  
> 
>  org.apache.maven.plugins
>  maven-javadoc-plugin
>  3.0.0
>  
>  bm.mycompany.common.doclet.MyDoclet
> ${project.build.directory}/../../shared-java/target/classes;${project.build.directory}/classes
>  
> ${project.build.directory}/../../shared-java/src/java;${project.build.directory}/../src/java
>  UTF-8
>  public
>  com.mycompany.api
>  false
>  
>  
>  
>  
>  javax.ws.rs
>  javax.ws.rs-api
>  2.0.1
>  
>  
>  javax.servlet
>  servlet-api
>  2.5
>  
>  
>  
>  com.mycompany.util
>  object-tree-creator
>  1.0
>  
>  
>  
> ...



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (SUREFIRE-1481) Surefire1295AttributeJvmCrashesToTestsIT should be Parameterized test instead of using Theories runner

[Tibor Digana (JIRA)]

Tibor Digana created SUREFIRE-1481:
--

 Summary: Surefire1295AttributeJvmCrashesToTestsIT should be 
Parameterized test instead of using Theories runner
 Key: SUREFIRE-1481
 URL: https://issues.apache.org/jira/browse/SUREFIRE-1481
 Project: Maven Surefire
  Issue Type: Task
Reporter: Tibor Digana
 Fix For: 2.21.0


I turned the IT to JUnit runner {{Theories}} because this runner tests all 
combinations of two parameters.
Due to this runner is not stable and does not proceed with next test if 
previous fails, I had to use {{Parameterized}} runner. Additionally 
{{Theories}} runner does not support JUnit {{Assumptions}}.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] maven-wagon pull request #45: [WAGON-501] ScmGitExeWagonTest

[basinilya]

GitHub user basinilya opened a pull request:

https://github.com/apache/maven-wagon/pull/45

[WAGON-501] ScmGitExeWagonTest



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

$ git pull https://github.com/basinilya/maven-wagon WAGON-501

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

https://github.com/apache/maven-wagon/pull/45.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 #45


commit 5608088a2bccfa3fc04cfa918373c03a6a4ba814
Author: Ilya Basin 
Date:   2018-02-21T08:52:26Z

[WAGON-501] test-repo-git

commit a436fcced0342e328f42596ee13d8dd6ff285339
Author: Ilya Basin 
Date:   2018-02-21T09:05:07Z

[WAGON-501] test-repo-git: add a file

commit 641a345ee8aabca9e40ba12c63bf87a27e35afcd
Author: Ilya Basin 
Date:   2018-02-21T12:35:26Z

[WAGON-501] ScmGitExeWagonTest




---

[jira] [Commented] (MJAVADOC-427) "Error fetching URL" for valid non-Java API links

[JIRA]

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

Guillaume Boué commented on MJAVADOC-427:
-

Looks like the issue is the HTTP -> HTTPS redirection that does not happen 
inside the {{javadoc}} tool itself. Possible upstream JDK issue here: 
[JDK-8190312|https://bugs.openjdk.java.net/browse/JDK-8190312]. The plugin 
instructs {{javadoc}} to locate the apidocs at {{http://www.slf4j.org/apidocs}} 
(because slf4j URL [is 
{{http://www.slf4j.org}}|https://github.com/qos-ch/slf4j/blob/v_1.7.12/pom.xml#L15]
 in its POM) and then it does not follow the redirect to HTTPS.

Indeed, if we explicitly add {{https://www.slf4j.org/apidocs}}, 
the link gets correctly generated.

> "Error fetching URL" for valid non-Java API links
> -
>
> Key: MJAVADOC-427
> URL: https://issues.apache.org/jira/browse/MJAVADOC-427
> Project: Maven Javadoc Plugin
>  Issue Type: Bug
>Affects Versions: 2.10.3
> Environment: Windows 7
> Apache Maven 3.2.1
> java version "1.8.0_05"
> Java(TM) SE Runtime Environment (build 1.8.0_05-b13)
> Java HotSpot(TM) 64-Bit Server VM (build 25.5-b02, mixed mode)
>Reporter: Selena Renee Phillips
>Priority: Major
> Attachments: testcase-detectLinks-enabled-no-manual-link-config.zip, 
> testcase-detectLinks-enabled-with-manual-link-config-no-trailing-slash.zip, 
> testcase-detectLinks-enabled-with-manual-link-config-trailing-slash.zip, 
> testcases-detectLinks-disabled-with-manual-link-config-no-trailing-slash.zip, 
> testcases-detectLinks-disabled-with-manual-link-config-trailing-slash.zip
>
>
> When I generate Javadoc for a simple project with 3rd party dependencies, no 
> configuration generates links for these dependencies. For valid Javadoc links 
> which have a package-list, I get the following error:
> [WARNING] javadoc: warning - Error fetching URL
> Test Cases w/ results (sample project(s)) attached:
> *1. No manual link configuration. 'detectLinks' is set to true.*
> {code:title=pom.xml - No manual link configuration with 
> detectLinks=true|borderStyle=solid}
> 
> org.apache.maven.plugins
> maven-javadoc-plugin
> 2.10.3
> 
> 
> ${project.basedir}/target
> javadoc
> Epiphany
> Epiphany
> private
> true
> true
> true
> true
> 
> 
> 
> 
> javadoc
> test-javadoc
> 
> 
> 
> 
> {code}
> Output of 'mvn javadoc:javadoc':
> {code:title=Resulting output for mvn javadoc:javadoc - No manual link 
> configuration with detectLinks=true|borderStyle=solid}
> [INFO] Scanning for projects...
> [INFO]
> [INFO] Using the builder 
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder
>  with a thread count of 1
> [INFO]
> [INFO] 
> 
> [INFO] Building epiphany 1.0-SNAPSHOT
> [INFO] 
> 
> [INFO]
> [INFO] >>> maven-javadoc-plugin:2.10.3:javadoc (default-cli) @ epiphany >>>
> [INFO]
> [INFO] <<< maven-javadoc-plugin:2.10.3:javadoc (default-cli) @ epiphany <<<
> SNIP DOWNLOADING INFO.
> [INFO]
> [INFO] --- maven-javadoc-plugin:2.10.3:javadoc (default-cli) @ epiphany ---
> [ERROR] Error fetching link: 
> http://selenium.googlecode.com/selenium-java/apidocs/package-list. Ignored it.
> [ERROR] Error fetching link: 
> http://selenium.googlecode.com/selenium-api/apidocs/package-list. Ignored it.
> [ERROR] Error fetching link: 
> http://selenium.googlecode.com/selenium-support/apidocs/package-list. Ignored 
> it.
> [ERROR] Error fetching link: 
> http://code.google.com/p/guava-libraries/guava/apidocs/package-list. Ignored 
> it.
> [ERROR] Error fetching link: 
> http://logback.qos.ch/logback-core/apidocs/package-list. Ignored it.
> [ERROR] Error fetching link: 
> http://logback.qos.ch/logback-classic/apidocs/package-list. Ignored it.
> [ERROR] Error fetching link: http://testng.org/apidocs/package-list. Ignored 
> it.
> [INFO]
> Loading source files for package com.example...
> Constructing Javadoc information...
> Standard Doclet version 1.8.0_05
> Building tree for all the packages and classes...
> Generating 
> C:\Users\sephilli\git\javadoc-bug\target\javadoc\com\example\AbstractLoadable.html...
> .SNIP
> 1 warning
> [WARNING] Javadoc Warnings
> [WARNING] javadoc: warning - Error fetching URL: 

[jira] [Issue Comment Deleted] (WAGON-501) gitexe unit test

[Ilya Basin (JIRA)]

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

Ilya Basin updated WAGON-501:
-
Comment: was deleted

(was: robot not picked https://github.com/apache/maven-wagon/pull/45)

> gitexe unit test
> 
>
> Key: WAGON-501
> URL: https://issues.apache.org/jira/browse/WAGON-501
> Project: Maven Wagon
>  Issue Type: New Feature
>  Components: wagon-scm
>Affects Versions: 3.0.0, 3.0.1
>Reporter: Ilya Basin
>Priority: Major
>
> Should add ScmGitExeWagonTest similar to Svn and Cvs



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (WAGON-501) gitexe unit test

[Ilya Basin (JIRA)]

[ 
https://issues.apache.org/jira/browse/WAGON-501?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16371895#comment-16371895
 ] 

Ilya Basin commented on WAGON-501:
--

robot not picked https://github.com/apache/maven-wagon/pull/45

> gitexe unit test
> 
>
> Key: WAGON-501
> URL: https://issues.apache.org/jira/browse/WAGON-501
> Project: Maven Wagon
>  Issue Type: New Feature
>  Components: wagon-scm
>Affects Versions: 3.0.0, 3.0.1
>Reporter: Ilya Basin
>Priority: Major
>
> Should add ScmGitExeWagonTest similar to Svn and Cvs



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (WAGON-501) gitexe unit test

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/WAGON-501?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16371893#comment-16371893
 ] 

ASF GitHub Bot commented on WAGON-501:
--

GitHub user basinilya opened a pull request:

https://github.com/apache/maven-wagon/pull/45

[WAGON-501] ScmGitExeWagonTest



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

$ git pull https://github.com/basinilya/maven-wagon WAGON-501

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

https://github.com/apache/maven-wagon/pull/45.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 #45


commit 5608088a2bccfa3fc04cfa918373c03a6a4ba814
Author: Ilya Basin 
Date:   2018-02-21T08:52:26Z

[WAGON-501] test-repo-git

commit a436fcced0342e328f42596ee13d8dd6ff285339
Author: Ilya Basin 
Date:   2018-02-21T09:05:07Z

[WAGON-501] test-repo-git: add a file

commit 641a345ee8aabca9e40ba12c63bf87a27e35afcd
Author: Ilya Basin 
Date:   2018-02-21T12:35:26Z

[WAGON-501] ScmGitExeWagonTest




> gitexe unit test
> 
>
> Key: WAGON-501
> URL: https://issues.apache.org/jira/browse/WAGON-501
> Project: Maven Wagon
>  Issue Type: New Feature
>  Components: wagon-scm
>Affects Versions: 3.0.0, 3.0.1
>Reporter: Ilya Basin
>Priority: Major
>
> Should add ScmGitExeWagonTest similar to Svn and Cvs



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (WAGON-500) ScmCvsExeWagonTest should be re-enabled

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/WAGON-500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16371879#comment-16371879
 ] 

ASF GitHub Bot commented on WAGON-500:
--

GitHub user basinilya opened a pull request:

https://github.com/apache/maven-wagon/pull/44

[WAGON-500] re-enable ScmCvsExeWagonTest



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

$ git pull https://github.com/basinilya/maven-wagon WAGON-500

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

https://github.com/apache/maven-wagon/pull/44.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 #44


commit 158c38356b186d53de0c303c9f28d517c0bba21d
Author: Ilya Basin 
Date:   2018-02-18T09:31:46Z

fix CvsWagonTest: the test repo has no subfolders

commit 9dab64acc4d4bedea44d6344d7bb153857312f5d
Author: Ilya Basin 
Date:   2018-02-21T18:56:13Z

[WAGON-500] fix test cvs repo not clean before next test case

commit 7f0b8cfa2c2de7a75c9eb478e197d4ec8bc0654e
Author: Ilya Basin 
Date:   2018-02-20T08:29:20Z

[WAGON-500] re-enable ScmCvsExeWagonTest




> ScmCvsExeWagonTest should be re-enabled
> ---
>
> Key: WAGON-500
> URL: https://issues.apache.org/jira/browse/WAGON-500
> Project: Maven Wagon
>  Issue Type: Bug
>  Components: wagon-scm
>Affects Versions: 3.0.0, 3.0.1
>Reporter: Ilya Basin
>Priority: Major
>
> ScmCvsExeWagonTest should be re-enabled



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] maven-wagon pull request #44: [WAGON-500] re-enable ScmCvsExeWagonTest

[basinilya]

GitHub user basinilya opened a pull request:

https://github.com/apache/maven-wagon/pull/44

[WAGON-500] re-enable ScmCvsExeWagonTest



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

$ git pull https://github.com/basinilya/maven-wagon WAGON-500

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

https://github.com/apache/maven-wagon/pull/44.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 #44


commit 158c38356b186d53de0c303c9f28d517c0bba21d
Author: Ilya Basin 
Date:   2018-02-18T09:31:46Z

fix CvsWagonTest: the test repo has no subfolders

commit 9dab64acc4d4bedea44d6344d7bb153857312f5d
Author: Ilya Basin 
Date:   2018-02-21T18:56:13Z

[WAGON-500] fix test cvs repo not clean before next test case

commit 7f0b8cfa2c2de7a75c9eb478e197d4ec8bc0654e
Author: Ilya Basin 
Date:   2018-02-20T08:29:20Z

[WAGON-500] re-enable ScmCvsExeWagonTest




---

[jira] [Created] (WAGON-500) ScmCvsExeWagonTest should be re-enabled

[Ilya Basin (JIRA)]

Ilya Basin created WAGON-500:


 Summary: ScmCvsExeWagonTest should be re-enabled
 Key: WAGON-500
 URL: https://issues.apache.org/jira/browse/WAGON-500
 Project: Maven Wagon
  Issue Type: Bug
  Components: wagon-scm
Affects Versions: 3.0.0, 3.0.1
Reporter: Ilya Basin


ScmCvsExeWagonTest should be re-enabled



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Comment Edited] (MASSEMBLY-775) Emit WARNING instead of ERROR

[Gordon Pettey (JIRA)]

[ 
https://issues.apache.org/jira/browse/MASSEMBLY-775?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16371826#comment-16371826
 ] 

Gordon Pettey edited comment on MASSEMBLY-775 at 2/21/18 6:31 PM:
--

It's not checking "a path starting with / on a Windows system". It's checking a 
path starting with / as the target path in the assembled archive, which is 
utter nonsense. The zip/tar/whatever file isn't ever going to have "Windows" 
paths with drive letters in it. {{/}} is the appropriate way to specify the 
root directory of the archive.


was (Author: gpettey):
It's not checking "a path starting with / on a Windows system". It's checking a 
path starting with / as the target path in the assembled archive, which is 
utter nonsense. The zip/tar/whatever file isn't ever going to have "Windows" 
paths with drive letters in it. {{/}} is THE appropriate way to specify the 
root directory of the archive.

> Emit WARNING instead of ERROR
> -
>
> Key: MASSEMBLY-775
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-775
> Project: Maven Assembly Plugin
>  Issue Type: Improvement
>Affects Versions: 2.5.5
>Reporter: Karl Heinz Marbaise
>Priority: Minor
>
> I have currently a build which creates several tar/tar.gz/zip archives etc.
> {code}
> [INFO] Reading assembly descriptor: src/main/assembly/descriptor-inner-tar.xml
> [INFO] Reading assembly descriptor: src/main/assembly/descriptor.xml
> [INFO] Building tar: C:\...\xyz-X.y.z-SNAPSHOT-dist.tar
> [ERROR] OS=Windows and the assembly descriptor contains a *nix-specific 
> root-relative-reference (starting with slash) /
> [ERROR] OS=Windows and the assembly descriptor contains a *nix-specific 
> root-relative-reference (starting with slash) /
> {code}
> In my opinion the message could be a WARNING instead of an error ? WDYT ?



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MASSEMBLY-775) Emit WARNING instead of ERROR

[Gordon Pettey (JIRA)]

[ 
https://issues.apache.org/jira/browse/MASSEMBLY-775?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16371826#comment-16371826
 ] 

Gordon Pettey commented on MASSEMBLY-775:
-

It's not checking "a path starting with / on a Windows system". It's checking a 
path starting with / as the target path in the assembled archive, which is 
utter nonsense. The zip/tar/whatever file isn't ever going to have "Windows" 
paths with drive letters in it. {{/}} is THE appropriate way to specify the 
root directory of the archive.

> Emit WARNING instead of ERROR
> -
>
> Key: MASSEMBLY-775
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-775
> Project: Maven Assembly Plugin
>  Issue Type: Improvement
>Affects Versions: 2.5.5
>Reporter: Karl Heinz Marbaise
>Priority: Minor
>
> I have currently a build which creates several tar/tar.gz/zip archives etc.
> {code}
> [INFO] Reading assembly descriptor: src/main/assembly/descriptor-inner-tar.xml
> [INFO] Reading assembly descriptor: src/main/assembly/descriptor.xml
> [INFO] Building tar: C:\...\xyz-X.y.z-SNAPSHOT-dist.tar
> [ERROR] OS=Windows and the assembly descriptor contains a *nix-specific 
> root-relative-reference (starting with slash) /
> [ERROR] OS=Windows and the assembly descriptor contains a *nix-specific 
> root-relative-reference (starting with slash) /
> {code}
> In my opinion the message could be a WARNING instead of an error ? WDYT ?



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Comment Edited] (MNG-6215) 'mvn --encrypt-password' doesn't prompt in Git Bash

[Gordon Pettey (JIRA)]

[ 
https://issues.apache.org/jira/browse/MNG-6215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16371810#comment-16371810
 ] 

Gordon Pettey edited comment on MNG-6215 at 2/21/18 6:25 PM:
-

In git bash you can use {{winpty mvn.cmd -ep}}.


was (Author: gpettey):
In git bash you can use `winpty mvn.cmd -ep`.

> 'mvn --encrypt-password' doesn't prompt in Git Bash
> ---
>
> Key: MNG-6215
> URL: https://issues.apache.org/jira/browse/MNG-6215
> Project: Maven
>  Issue Type: Bug
>  Components: Command Line
>Affects Versions: 3.3.9
> Environment: git version 2.12.2.windows.2
> jdk 8u111
> windows 7 pro
>Reporter: Alex Pintilie
>Priority: Major
> Fix For: 3.5.x-candidate
>
> Attachments: screenshot.jpg
>
>
> When I try to encrypt a password with {{mvn --encrypt-password}} in the Git 
> Bash, I get no prompt like in the windows command prompt. Instead I get some 
> empty curly braces {} (see screenshot).
> {{git version 2.12.2.windows.2}}
> Regards,
> Alex



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MNG-6215) 'mvn --encrypt-password' doesn't prompt in Git Bash

[Gordon Pettey (JIRA)]

[ 
https://issues.apache.org/jira/browse/MNG-6215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16371810#comment-16371810
 ] 

Gordon Pettey commented on MNG-6215:


In git bash you can use `winpty mvn.cmd -ep`.

> 'mvn --encrypt-password' doesn't prompt in Git Bash
> ---
>
> Key: MNG-6215
> URL: https://issues.apache.org/jira/browse/MNG-6215
> Project: Maven
>  Issue Type: Bug
>  Components: Command Line
>Affects Versions: 3.3.9
> Environment: git version 2.12.2.windows.2
> jdk 8u111
> windows 7 pro
>Reporter: Alex Pintilie
>Priority: Major
> Fix For: 3.5.x-candidate
>
> Attachments: screenshot.jpg
>
>
> When I try to encrypt a password with {{mvn --encrypt-password}} in the Git 
> Bash, I get no prompt like in the windows command prompt. Instead I get some 
> empty curly braces {} (see screenshot).
> {{git version 2.12.2.windows.2}}
> Regards,
> Alex



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (SCM-868) gitexe add() does not return added files when invoked in subdir

[Ilya Basin (JIRA)]

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

Ilya Basin updated SCM-868:
---
Description: 
I'm going to add a wagon-scm test suite for git. One of the test cases is 
calling the GitAddCommand command with:
{code:java}
repo: 
file:///C:/progs/maven/maven-wagon/wagon-providers/wagon-scm/target/test-classes/test-repo-git-test/
fileSet: basedir = 
C:\Users\basin\AppData\Local\Temp\wagon-scm2020146470.checkout\file-list; files 
= [test-resource.txt]{code}
After adding the files the command internally calls "git rev-parse 
--show-toplevel" which prints:
{code:java}
C:/Users/basin/AppData/Local/Temp/wagon-scm2020146470.checkout{code}
And on the next line it tries to do (pseudo code):
{code:java}
("file:/C:/Users/basin/AppData/Local/Temp/wagon-scm1144102340.checkout/file-list/").relativize(URI.create(
"C:/Users/basin/AppData/Local/Temp/wagon-scm2020146470.checkout")){code}
This is so wrong! What were those people from SCM-709 trying to get? A double 
dot ".."? The argument to the relativize() method MUST be a child, not a 
parent, otherwise the argument is returned unchanged.

There are so many reasons why getting an absolute path from git is a bad idea: 
Symlinks, Windows paths.

Nevertheless, there's a simple solution. The original problem was that "git 
status --porcelain" printed paths relative to the top level instead of relative 
to the base dir.

So we should just call 
{code}
git rev-parse --show-prefix
{code} instead of "show-toplevel" and strip this prefix from the paths printed 
by "git status"

  was:
I'm going to add a wagon-scm test suite for git. One of the test cases is 
calling the GitAddCommand command with:
{code:java}
repo: 
file:///C:/progs/maven/maven-wagon/wagon-providers/wagon-scm/target/test-classes/test-repo-git-test/
fileSet: basedir = 
C:\Users\basin\AppData\Local\Temp\wagon-scm2020146470.checkout\file-list; files 
= [test-resource.txt]{code}
After adding the files the command internally calls "git rev-parse 
--show-toplevel" which prints:
{code:java}
C:/Users/basin/AppData/Local/Temp/wagon-scm2020146470.checkout{code}
And on the next line it tries to do (pseudo code):
{code:java}
("file:/C:/Users/basin/AppData/Local/Temp/wagon-scm1144102340.checkout/file-list/").relativize(URI.create(
"C:/Users/basin/AppData/Local/Temp/wagon-scm2020146470.checkout")){code}
This is so wrong! What were those people from SCM-709 trying to get? A double 
dot ".."? The argument to the relativize() method MUST be a child, not a 
parent, otherwise the argument is returned unchanged.

There are so many reasons why getting an absolute path from git is a bad idea: 
Symlinks, Windows paths.

Nevertheless, there's a simple solution. The original problem was that "git 
status --porcelain" printed paths relative to the top level instead of relative 
to the base dir.

So we should just call "git rev-parse --show-prefix" instead of 
"--show-toplevel" and strip this prefix from the paths printed by "git status 
--porcelain"

 


> gitexe add() does not return added files when invoked in subdir
> ---
>
> Key: SCM-868
> URL: https://issues.apache.org/jira/browse/SCM-868
> Project: Maven SCM
>  Issue Type: Bug
>  Components: maven-scm-provider-gitexe
>Affects Versions: 1.9.5, 1.9.6
>Reporter: Ilya Basin
>Priority: Major
>
> I'm going to add a wagon-scm test suite for git. One of the test cases is 
> calling the GitAddCommand command with:
> {code:java}
> repo: 
> file:///C:/progs/maven/maven-wagon/wagon-providers/wagon-scm/target/test-classes/test-repo-git-test/
> fileSet: basedir = 
> C:\Users\basin\AppData\Local\Temp\wagon-scm2020146470.checkout\file-list; 
> files = [test-resource.txt]{code}
> After adding the files the command internally calls "git rev-parse 
> --show-toplevel" which prints:
> {code:java}
> C:/Users/basin/AppData/Local/Temp/wagon-scm2020146470.checkout{code}
> And on the next line it tries to do (pseudo code):
> {code:java}
> ("file:/C:/Users/basin/AppData/Local/Temp/wagon-scm1144102340.checkout/file-list/").relativize(URI.create(
> "C:/Users/basin/AppData/Local/Temp/wagon-scm2020146470.checkout")){code}
> This is so wrong! What were those people from SCM-709 trying to get? A double 
> dot ".."? The argument to the relativize() method MUST be a child, not a 
> parent, otherwise the argument is returned unchanged.
> There are so many reasons why getting an absolute path from git is a bad 
> idea: Symlinks, Windows paths.
> Nevertheless, there's a simple solution. The original problem was that "git 
> status --porcelain" printed paths relative to the top level instead of 
> relative to the base dir.
> So we should just call 
> {code}
> git rev-parse --show-prefix
> {code} instead of "show-toplevel" and strip this prefix from the paths 
> printed by 

[jira] [Created] (SCM-868) gitexe add() does not return added files when invoked in subdir

[Ilya Basin (JIRA)]

Ilya Basin created SCM-868:
--

 Summary: gitexe add() does not return added files when invoked in 
subdir
 Key: SCM-868
 URL: https://issues.apache.org/jira/browse/SCM-868
 Project: Maven SCM
  Issue Type: Bug
  Components: maven-scm-provider-gitexe
Affects Versions: 1.9.5, 1.9.6
Reporter: Ilya Basin


I'm going to add a wagon-scm test suite for git. One of the test cases is 
calling the GitAddCommand command with:
{code:java}
repo: 
file:///C:/progs/maven/maven-wagon/wagon-providers/wagon-scm/target/test-classes/test-repo-git-test/
fileSet: basedir = 
C:\Users\basin\AppData\Local\Temp\wagon-scm2020146470.checkout\file-list; files 
= [test-resource.txt]{code}
After adding the files the command internally calls "git rev-parse 
--show-toplevel" which prints:
{code:java}
C:/Users/basin/AppData/Local/Temp/wagon-scm2020146470.checkout{code}
And on the next line it tries to do (pseudo code):
{code:java}
("file:/C:/Users/basin/AppData/Local/Temp/wagon-scm1144102340.checkout/file-list/").relativize(URI.create(
"C:/Users/basin/AppData/Local/Temp/wagon-scm2020146470.checkout")){code}
This is so wrong! What were those people from SCM-709 trying to get? A double 
dot ".."? The argument to the relativize() method MUST be a child, not a 
parent, otherwise the argument is returned unchanged.

There are so many reasons why getting an absolute path from git is a bad idea: 
Symlinks, Windows paths.

Nevertheless, there's a simple solution. The original problem was that "git 
status --porcelain" printed paths relative to the top level instead of relative 
to the base dir.

So we should just call "git rev-parse --show-prefix" instead of 
"--show-toplevel" and strip this prefix from the paths printed by "git status 
--porcelain"

 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (SCM-867) ScmWagon has no way to work with CVS and SVN in binary mode

[Ilya Basin (JIRA)]

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

Ilya Basin updated SCM-867:
---
Description: 
By default, CVSNT will corrupt jars during `mvn deploy`. Vanilla CVS less 
likely, but still possible due to Keyword substitution. ScmWagon needs to 
perform checkout and add commands with the '-kb' flag (binary).

UPD: In some configurations svn will automatically add the svn:eol-style 
property to newly added text files. ScmWagon needs to perform the add command 
without adding automatic properties.

UPD2: Msysgit will checkout wagon-scm test-resource with CRLF by default, 
breaking the test. Need to clone with core.autocrlf=false

  was:
By default, CVSNT will corrupt jars during `mvn deploy`. Vanilla CVS less 
likely, but still possible due to Keyword substitution. ScmWagon needs to 
perform checkout and add commands with the '-kb' flag (binary).

UPD: In some configurations svn will automatically add the svn:eol-style 
property to newly added text files. ScmWagon needs to perform the add command 
without adding automatic properties.


> ScmWagon has no way to work with CVS and SVN in binary mode
> ---
>
> Key: SCM-867
> URL: https://issues.apache.org/jira/browse/SCM-867
> Project: Maven SCM
>  Issue Type: Bug
>  Components: maven-scm-provider-cvs
>Affects Versions: 1.9.5, 1.9.6
>Reporter: Ilya Basin
>Priority: Major
>
> By default, CVSNT will corrupt jars during `mvn deploy`. Vanilla CVS less 
> likely, but still possible due to Keyword substitution. ScmWagon needs to 
> perform checkout and add commands with the '-kb' flag (binary).
> UPD: In some configurations svn will automatically add the svn:eol-style 
> property to newly added text files. ScmWagon needs to perform the add command 
> without adding automatic properties.
> UPD2: Msysgit will checkout wagon-scm test-resource with CRLF by default, 
> breaking the test. Need to clone with core.autocrlf=false



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MNGSITE-300) Version order not documented

[Jon Harper (JIRA)]

[ 
https://issues.apache.org/jira/browse/MNGSITE-300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16371525#comment-16371525
 ] 

Jon Harper commented on MNGSITE-300:


Hi [~rfscholte] ,

I noticed the current site ( 
[http://maven.apache.org/pom.html#Version_Order_Specification] ) has a few 
rendering problems (typos) in the sections we added here, here's a patch 
(tested) to fix them:
{noformat}
$ svn info
URL: https://svn.apache.org/repos/asf/maven/site/trunk

$ svn diff
Index: content/apt/pom.apt
===
--- content/apt/pom.apt (revision 1824974)
+++ content/apt/pom.apt (working copy)
@@ -445,7 +445,7 @@
 
 * <<<1.ga>>> -> <<<1>>>
 
- * <<<1.final -> <<<1>>>
+ * <<<1.final>>> -> <<<1>>>
 
 * <<<1.0>>> -> <<<1>>>
 
@@ -513,9 +513,9 @@
 $ java -jar ./lib/maven-artifact-3.3.9.jar 1 2 1.1
 Display parameters as parsed by Maven (in canonical form) and comparison 
result:
 1. 1 == 1
- 1 \< 2
+ 1 < 2
 2. 2 == 2
- 2 \> 1.1
+ 2 > 1.1
 3. 1.1 == 1.1
 
{noformat}
cheers,

Jon

> Version order not documented
> 
>
> Key: MNGSITE-300
> URL: https://issues.apache.org/jira/browse/MNGSITE-300
> Project: Maven Project Web Site
>  Issue Type: Bug
>Reporter: Jon Harper
>Assignee: Robert Scholte
>Priority: Major
> Attachments: doc-version-order-image.png, doc-version-order.patch
>
>
> Documenting the version order. I don't know how many exemples should go there 
> because there are tons of counter intuitive version orders. Feel free to 
> discuss.
> Also, this was the most concise way I found to document the existing 
> behavior, but it could be explained differently.
> Created issue as suggested by hervé boutemy.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (WAGON-498) ScmWagon should work in binary and shallow mode when possible

[Ilya Basin (JIRA)]

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

Ilya Basin updated WAGON-498:
-
Description: 
See SCM-867

By default, CVSNT will corrupt jars during `mvn deploy`. Vanilla CVS less 
likely, but still possible due to Keyword substitution. ScmWagon needs to 
perform checkout and add commands with the '-kb' flag (binary).

For that we need to call the overloaded methods added recently in maven-scm 
1.9.6.

UPD: As it turns out, svn may also change files, if enable-auto-props is on. 
The test case "testWagon" which could reveal that is disabled by mistake: it 
runs only if supportsGetIfNewer(), but we don't call getIfNewer() there.

To demonstrate the issue, edit your subversion config file:
{code:java}
[miscellany]
enable-auto-props = yes
[auto-props]
test-resource = svn:eol-style=CRLF{code}
This will not affect checkin, because the test file already has LF, but the 
auto property will be set and next time the file will be checked out with CRLF 
and #testWagon will fail.

UPD2: for git should also set the shallow flag

  was:
See SCM-867

By default, CVSNT will corrupt jars during `mvn deploy`. Vanilla CVS less 
likely, but still possible due to Keyword substitution. ScmWagon needs to 
perform checkout and add commands with the '-kb' flag (binary).

For that we need to call the overloaded methods added recently in maven-scm 
1.9.6.

UPD: As it turns out, svn may also change files, if enable-auto-props is on. 
The test case "testWagon" which could reveal that is disabled by mistake: it 
runs only if supportsGetIfNewer(), but we don't call getIfNewer() there.

To demonstrate the issue, edit your subversion config file:
{code:java}
[miscellany]
enable-auto-props = yes
[auto-props]
test-resource = svn:eol-style=CRLF{code}
This will not affect checkin, because the test file already has LF, but the 
auto property will be set and next time the file will be checked out with CRLF 
and #testWagon will fail.


> ScmWagon should work in binary and shallow mode when possible
> -
>
> Key: WAGON-498
> URL: https://issues.apache.org/jira/browse/WAGON-498
> Project: Maven Wagon
>  Issue Type: Bug
>  Components: wagon-scm
>Affects Versions: 3.0.0, 3.0.1
>Reporter: Ilya Basin
>Priority: Major
>
> See SCM-867
> By default, CVSNT will corrupt jars during `mvn deploy`. Vanilla CVS less 
> likely, but still possible due to Keyword substitution. ScmWagon needs to 
> perform checkout and add commands with the '-kb' flag (binary).
> For that we need to call the overloaded methods added recently in maven-scm 
> 1.9.6.
> UPD: As it turns out, svn may also change files, if enable-auto-props is on. 
> The test case "testWagon" which could reveal that is disabled by mistake: it 
> runs only if supportsGetIfNewer(), but we don't call getIfNewer() there.
> To demonstrate the issue, edit your subversion config file:
> {code:java}
> [miscellany]
> enable-auto-props = yes
> [auto-props]
> test-resource = svn:eol-style=CRLF{code}
> This will not affect checkin, because the test file already has LF, but the 
> auto property will be set and next time the file will be checked out with 
> CRLF and #testWagon will fail.
> UPD2: for git should also set the shallow flag



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (WAGON-498) ScmWagon should work in binary and shallow mode when possible

[Ilya Basin (JIRA)]

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

Ilya Basin updated WAGON-498:
-
Summary: ScmWagon should work in binary and shallow mode when possible  
(was: ScmWagon should work in binary mode when possible)

> ScmWagon should work in binary and shallow mode when possible
> -
>
> Key: WAGON-498
> URL: https://issues.apache.org/jira/browse/WAGON-498
> Project: Maven Wagon
>  Issue Type: Bug
>  Components: wagon-scm
>Affects Versions: 3.0.0, 3.0.1
>Reporter: Ilya Basin
>Priority: Major
>
> See SCM-867
> By default, CVSNT will corrupt jars during `mvn deploy`. Vanilla CVS less 
> likely, but still possible due to Keyword substitution. ScmWagon needs to 
> perform checkout and add commands with the '-kb' flag (binary).
> For that we need to call the overloaded methods added recently in maven-scm 
> 1.9.6.
> UPD: As it turns out, svn may also change files, if enable-auto-props is on. 
> The test case "testWagon" which could reveal that is disabled by mistake: it 
> runs only if supportsGetIfNewer(), but we don't call getIfNewer() there.
> To demonstrate the issue, edit your subversion config file:
> {code:java}
> [miscellany]
> enable-auto-props = yes
> [auto-props]
> test-resource = svn:eol-style=CRLF{code}
> This will not affect checkin, because the test file already has LF, but the 
> auto property will be set and next time the file will be checked out with 
> CRLF and #testWagon will fail.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (MPMD-253) PMD links to java Xref fail in aggregated report

[Tony Washer (JIRA)]

Tony Washer created MPMD-253:


 Summary: PMD links to java Xref fail in aggregated report
 Key: MPMD-253
 URL: https://issues.apache.org/jira/browse/MPMD-253
 Project: Maven PMD Plugin
  Issue Type: Bug
  Components: PMD
Affects Versions: 3.9.0
Reporter: Tony Washer


When a PMD aggregate report in created with PMD plugin 3.9.0 (and underlying 
PMD 6.0.1) the report contains a link to the java XRef report that intended to 
take the user straight to the failing line.

In 3.9.0 the link takes you to a "Page not found". This is because the link is 
formed as  xxx/target/staging/xref/*n%20-%20*net/sourceforge/x  
instead of  xxx/target/staging/xref/net/sourceforge/x.

Here n$20-%20 is the description of the relevant module and should not 
be there

 

 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)