[jira] [Closed] (MENFORCER-249) "Require Release Dependencies" rule doesn't fail when using a plugin with a SNAPSHOT version

[Karl Heinz Marbaise (JIRA)]

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

Karl Heinz Marbaise closed MENFORCER-249.
-
Resolution: Implemented
  Assignee: Karl Heinz Marbaise

Thanks for the hint Matt..So I close the issue.

> "Require Release Dependencies" rule doesn't fail when using a plugin with a 
> SNAPSHOT version
> 
>
> Key: MENFORCER-249
> URL: https://issues.apache.org/jira/browse/MENFORCER-249
> Project: Maven Enforcer Plugin
>  Issue Type: New Feature
>  Components: Standard Rules
>Affects Versions: 1.4.1
>Reporter: Jean-François Lecomte
>Assignee: Karl Heinz Marbaise
>Priority: Major
>
> We are developing our own Maven plugins in my company, so we use SNAPSHOT 
> versions for these plugins while we are developing them.
> Last time we released a version of an artifact that uses this plugin, we 
> accidentally forgot to release the maven plugin first.
> I would expect the "Require Release Dependencies" to fail in such situation 
> or have another Standard Rule to prevent that...



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

[jira] [Commented] (SUREFIRE-1475) PpidChecker.windows() assumes wmic is on the path

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on SUREFIRE-1475:
--

Github user awallgren commented on the issue:

https://github.com/apache/maven-surefire/pull/174
  
And certainly more correct than whatever random wmic.exe is on the path, if
any. Also, it would be great if errors from the ping invocation weren't
suppressed as thoroughly as they currently are.


On Fri, Feb 9, 2018 at 22:59 Anders Wallgren 
wrote:

> Yes and yes.
> On Fri, Feb 9, 2018 at 19:22 Tibor Digana 
> wrote:
>
>> Did we take right path here as well? Did Microsoft mention this link in
>> their documentation?
>>
>> —
>> You are receiving this because you authored the thread.
>> Reply to this email directly, view it on GitHub
>> 
,
>> or mute the thread
>> 

>> .
>>
> --
> anders
>
-- 
anders



> PpidChecker.windows() assumes wmic is on the path
> -
>
> Key: SUREFIRE-1475
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1475
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: process forking
>Affects Versions: 2.20.1
> Environment: Windows
>Reporter: Anders Wallgren
>Priority: Major
>
>  
> {{PpidChecker.windows()}} assumes that the wmic executable is on the path, 
> which isn't always the case.
> A better approach would probably be to use 
> {{%SystemRoot%\System32\Wbem\wmic}}.
>  



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

[GitHub] maven-surefire issue #174: https://issues.apache.org/jira/browse/SUREFIRE-14...

[awallgren]

Github user awallgren commented on the issue:

https://github.com/apache/maven-surefire/pull/174
  
And certainly more correct than whatever random wmic.exe is on the path, if
any. Also, it would be great if errors from the ping invocation weren't
suppressed as thoroughly as they currently are.


On Fri, Feb 9, 2018 at 22:59 Anders Wallgren 
wrote:

> Yes and yes.
> On Fri, Feb 9, 2018 at 19:22 Tibor Digana 
> wrote:
>
>> Did we take right path here as well? Did Microsoft mention this link in
>> their documentation?
>>
>> —
>> You are receiving this because you authored the thread.
>> Reply to this email directly, view it on GitHub
>> 
,
>> or mute the thread
>> 

>> .
>>
> --
> anders
>
-- 
anders



---

[jira] [Commented] (SUREFIRE-1475) PpidChecker.windows() assumes wmic is on the path

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on SUREFIRE-1475:
--

Github user awallgren commented on the issue:

https://github.com/apache/maven-surefire/pull/174
  
Yes and yes.
On Fri, Feb 9, 2018 at 19:22 Tibor Digana  wrote:

> Did we take right path here as well? Did Microsoft mention this link in
> their documentation?
>
> —
> You are receiving this because you authored the thread.
> Reply to this email directly, view it on GitHub
> 
,
> or mute the thread
> 

> .
>
-- 
anders



> PpidChecker.windows() assumes wmic is on the path
> -
>
> Key: SUREFIRE-1475
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1475
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: process forking
>Affects Versions: 2.20.1
> Environment: Windows
>Reporter: Anders Wallgren
>Priority: Major
>
>  
> {{PpidChecker.windows()}} assumes that the wmic executable is on the path, 
> which isn't always the case.
> A better approach would probably be to use 
> {{%SystemRoot%\System32\Wbem\wmic}}.
>  



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

[GitHub] maven-surefire issue #174: https://issues.apache.org/jira/browse/SUREFIRE-14...

[awallgren]

Github user awallgren commented on the issue:

https://github.com/apache/maven-surefire/pull/174
  
Yes and yes.
On Fri, Feb 9, 2018 at 19:22 Tibor Digana  wrote:

> Did we take right path here as well? Did Microsoft mention this link in
> their documentation?
>
> —
> You are receiving this because you authored the thread.
> Reply to this email directly, view it on GitHub
> 
,
> or mute the thread
> 

> .
>
-- 
anders



---

[jira] [Commented] (SUREFIRE-1475) PpidChecker.windows() assumes wmic is on the path

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on SUREFIRE-1475:
--

Github user Tibor17 commented on the issue:

https://github.com/apache/maven-surefire/pull/174
  
Did we take right path here as well? Did Microsoft mention this link in 
their documentation?


> PpidChecker.windows() assumes wmic is on the path
> -
>
> Key: SUREFIRE-1475
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1475
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: process forking
>Affects Versions: 2.20.1
> Environment: Windows
>Reporter: Anders Wallgren
>Priority: Major
>
>  
> {{PpidChecker.windows()}} assumes that the wmic executable is on the path, 
> which isn't always the case.
> A better approach would probably be to use 
> {{%SystemRoot%\System32\Wbem\wmic}}.
>  



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

[GitHub] maven-surefire issue #174: https://issues.apache.org/jira/browse/SUREFIRE-14...

[Tibor17]

Github user Tibor17 commented on the issue:

https://github.com/apache/maven-surefire/pull/174
  
Did we take right path here as well? Did Microsoft mention this link in 
their documentation?


---

[jira] [Commented] (MENFORCER-249) "Require Release Dependencies" rule doesn't fail when using a plugin with a SNAPSHOT version

[Matt Nelson (JIRA)]

[ 
https://issues.apache.org/jira/browse/MENFORCER-249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16359159#comment-16359159
 ] 

Matt Nelson commented on MENFORCER-249:
---

This is already supported.

https://maven.apache.org/enforcer/enforcer-rules/requirePluginVersions.html

> "Require Release Dependencies" rule doesn't fail when using a plugin with a 
> SNAPSHOT version
> 
>
> Key: MENFORCER-249
> URL: https://issues.apache.org/jira/browse/MENFORCER-249
> Project: Maven Enforcer Plugin
>  Issue Type: New Feature
>  Components: Standard Rules
>Affects Versions: 1.4.1
>Reporter: Jean-François Lecomte
>Priority: Major
>
> We are developing our own Maven plugins in my company, so we use SNAPSHOT 
> versions for these plugins while we are developing them.
> Last time we released a version of an artifact that uses this plugin, we 
> accidentally forgot to release the maven plugin first.
> I would expect the "Require Release Dependencies" to fail in such situation 
> or have another Standard Rule to prevent that...



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

[jira] [Commented] (SUREFIRE-1475) PpidChecker.windows() assumes wmic is on the path

[Anders Wallgren (JIRA)]

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

Anders Wallgren commented on SUREFIRE-1475:
---

Incidentally, this would have been much easier to track down if 
{{org.apache.maven.surefire.booter.ForkedBooter#setupBooter}} didn't disable 
the ping when it senses the JVM is being debugged.

I realize that's handy to avoid timeouts...but not when debugging the 
{{PpidChecker}} code itself...

> PpidChecker.windows() assumes wmic is on the path
> -
>
> Key: SUREFIRE-1475
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1475
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: process forking
>Affects Versions: 2.20.1
> Environment: Windows
>Reporter: Anders Wallgren
>Priority: Major
>
>  
> {{PpidChecker.windows()}} assumes that the wmic executable is on the path, 
> which isn't always the case.
> A better approach would probably be to use 
> {{%SystemRoot%\System32\Wbem\wmic}}.
>  



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

[GitHub] maven-surefire issue #173: [SUREFIRE-1004] Support full gavtc format for dep...

[bindul]

Github user bindul commented on the issue:

https://github.com/apache/maven-surefire/pull/173
  
@Tibor17 

I have reviewed the Maven Coordinates documentation you mentioned, and I 
can switch the order of elements in the parameter easily. However, I think I 
would disagree with requiring the version to be last element in the coordinates 
in this use case. As the functionality stands, the `dependenciesToScan` 
configuration does not add additional dependencies to the test scope of the 
project, it filters dependencies already added to the test scope in the project 
to allow for scanning test classes to run. If someone wants to add say a 
classfier or a type/packaging, requiring them them to also mention the version 
of the dependency would just make maintainers life harder by having another 
location to keep the version of the dependency in sync.

As such I propose, we keep the version as optional and support the 
following variations of dependencies to scan:

- `groupId:artifactId`
- `groupId:artifactId:packaging/type`
- `groupId:artifactId:packaging/type::version`
- `groupId:artifactId:packaging/type:classifier`
- `groupId:artifactId::classifier`
- `groupId:artifactId::classifier:version`
- `groupId:artifactId:packaging/type:classifier:version`

It still maintains the same order of elements as the Maven Coordinates 
documentation in the POM, just makes the version not required to be the last 
element, or rather makes version optional.

Thoughts?


---

[jira] [Commented] (SUREFIRE-1004) Enhance pattern/wildcard capabilities for dependenciesToScan to GAVT

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on SUREFIRE-1004:
--

Github user bindul commented on the issue:

https://github.com/apache/maven-surefire/pull/173
  
@Tibor17 

I have reviewed the Maven Coordinates documentation you mentioned, and I 
can switch the order of elements in the parameter easily. However, I think I 
would disagree with requiring the version to be last element in the coordinates 
in this use case. As the functionality stands, the `dependenciesToScan` 
configuration does not add additional dependencies to the test scope of the 
project, it filters dependencies already added to the test scope in the project 
to allow for scanning test classes to run. If someone wants to add say a 
classfier or a type/packaging, requiring them them to also mention the version 
of the dependency would just make maintainers life harder by having another 
location to keep the version of the dependency in sync.

As such I propose, we keep the version as optional and support the 
following variations of dependencies to scan:

- `groupId:artifactId`
- `groupId:artifactId:packaging/type`
- `groupId:artifactId:packaging/type::version`
- `groupId:artifactId:packaging/type:classifier`
- `groupId:artifactId::classifier`
- `groupId:artifactId::classifier:version`
- `groupId:artifactId:packaging/type:classifier:version`

It still maintains the same order of elements as the Maven Coordinates 
documentation in the POM, just makes the version not required to be the last 
element, or rather makes version optional.

Thoughts?


> Enhance pattern/wildcard capabilities for dependenciesToScan to GAVT
> 
>
> Key: SUREFIRE-1004
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1004
> Project: Maven Surefire
>  Issue Type: Improvement
>  Components: Maven Failsafe Plugin, Maven Surefire Plugin
>Affects Versions: 2.15
>Reporter: Andreas Gudian
>Priority: Major
>
> * Enhance what has been built with SUREFIRE-569 to support patterns as in 
> maven-shade-plugin. Use maven-common-artifact-filters for that.
> * Add/Adapt documentation and examples.



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

[jira] [Commented] (SUREFIRE-1475) PpidChecker.windows() assumes wmic is on the path

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on SUREFIRE-1475:
--

GitHub user awallgren opened a pull request:

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

https://issues.apache.org/jira/browse/SUREFIRE-1475

Don't assume wmic is on the path on windows.

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

$ git pull https://github.com/awallgren/maven-surefire master

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

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


commit e5fba76e2a2e94489978da86a80a86e7cd6b0996
Author: Anders Wallgren 
Date:   2018-02-10T00:39:35Z

https://issues.apache.org/jira/browse/SUREFIRE-1475

Don't assume wmic is on the path on windows.




> PpidChecker.windows() assumes wmic is on the path
> -
>
> Key: SUREFIRE-1475
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1475
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: process forking
>Affects Versions: 2.20.1
> Environment: Windows
>Reporter: Anders Wallgren
>Priority: Major
>
>  
> {{PpidChecker.windows()}} assumes that the wmic executable is on the path, 
> which isn't always the case.
> A better approach would probably be to use 
> {{%SystemRoot%\System32\Wbem\wmic}}.
>  



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

[GitHub] maven-surefire pull request #174: https://issues.apache.org/jira/browse/SURE...

[awallgren]

GitHub user awallgren opened a pull request:

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

https://issues.apache.org/jira/browse/SUREFIRE-1475

Don't assume wmic is on the path on windows.

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

$ git pull https://github.com/awallgren/maven-surefire master

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

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


commit e5fba76e2a2e94489978da86a80a86e7cd6b0996
Author: Anders Wallgren 
Date:   2018-02-10T00:39:35Z

https://issues.apache.org/jira/browse/SUREFIRE-1475

Don't assume wmic is on the path on windows.




---

[jira] [Created] (SUREFIRE-1475) PpidChecker.windows() assumes wmic is on the path

[Anders Wallgren (JIRA)]

Anders Wallgren created SUREFIRE-1475:
-

 Summary: PpidChecker.windows() assumes wmic is on the path
 Key: SUREFIRE-1475
 URL: https://issues.apache.org/jira/browse/SUREFIRE-1475
 Project: Maven Surefire
  Issue Type: Bug
  Components: process forking
Affects Versions: 2.20.1
 Environment: Windows
Reporter: Anders Wallgren


 
{{PpidChecker.windows()}} assumes that the wmic executable is on the path, 
which isn't always the case.

A better approach would probably be to use {{%SystemRoot%\System32\Wbem\wmic}}.

 



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

[jira] [Comment Edited] (MRELEASE-935) Support for expression in 'version' tag

[Robert Thornton (JIRA)]

[ 
https://issues.apache.org/jira/browse/MRELEASE-935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16359091#comment-16359091
 ] 

Robert Thornton edited comment on MRELEASE-935 at 2/9/18 11:27 PM:
---

I would also like the release plugin to support this feature. For example, 
maven does support the ${revision} expression in the version tag in which case 
the  property is expected not to have any expressions inside it.

See: https://maven.apache.org/maven-ci-friendly.html

However, the ${revision} expression is lost when the release plugin sets the 
development version.

I've attached a patch that resolves this issue.

[^support_for_revision_in_version.patch]


was (Author: rptmaestro):
I would also like the release plugin to support this feature. For example, 
maven does support the ${revision} expression in the version tag in which case 
the  property is expected not to have any expressions inside it.  
However, the ${revision} expression is lost when the release plugin sets the 
development version.

I've attached a patch that resolves this issue.

[^support_for_revision_in_version.patch]

> Support for expression in 'version' tag
> ---
>
> Key: MRELEASE-935
> URL: https://issues.apache.org/jira/browse/MRELEASE-935
> Project: Maven Release Plugin
>  Issue Type: New Feature
>Affects Versions: 2.5.3
>Reporter: Andrea Scarpino
>Priority: Critical
> Attachments: support_for_revision_in_version.patch
>
>
> The release plugin doesn't support a version value that points to a property 
> which define the version.
> Everytime I use the plugin, the version in the current POM loose the 
> expression. Maybe it could work using the property to which it points?
> {noformat}
> $ grep '' pom.xml
> ${parent.project.version}
> $ grep '' pom.xml
> 0.0.1-SNAPSHOT
> {noformat}
> Could you please implement this or point me to the files that handle this?



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

[jira] [Commented] (MRELEASE-935) Support for expression in 'version' tag

[Robert Thornton (JIRA)]

[ 
https://issues.apache.org/jira/browse/MRELEASE-935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16359091#comment-16359091
 ] 

Robert Thornton commented on MRELEASE-935:
--

I would also like the release plugin to support this feature. For example, 
maven does support the ${revision} expression in the version tag in which case 
the  property is expected not to have any expressions inside it.  
However, the ${revision} expression is lost when the release plugin sets the 
development version.

I've attached a patch that resolves this issue.

[^support_for_revision_in_version.patch]

> Support for expression in 'version' tag
> ---
>
> Key: MRELEASE-935
> URL: https://issues.apache.org/jira/browse/MRELEASE-935
> Project: Maven Release Plugin
>  Issue Type: New Feature
>Affects Versions: 2.5.3
>Reporter: Andrea Scarpino
>Priority: Critical
> Attachments: support_for_revision_in_version.patch
>
>
> The release plugin doesn't support a version value that points to a property 
> which define the version.
> Everytime I use the plugin, the version in the current POM loose the 
> expression. Maybe it could work using the property to which it points?
> {noformat}
> $ grep '' pom.xml
> ${parent.project.version}
> $ grep '' pom.xml
> 0.0.1-SNAPSHOT
> {noformat}
> Could you please implement this or point me to the files that handle this?



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

[jira] [Updated] (MRELEASE-935) Support for expression in 'version' tag

[Robert Thornton (JIRA)]

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

Robert Thornton updated MRELEASE-935:
-
Attachment: support_for_revision_in_version.patch

> Support for expression in 'version' tag
> ---
>
> Key: MRELEASE-935
> URL: https://issues.apache.org/jira/browse/MRELEASE-935
> Project: Maven Release Plugin
>  Issue Type: New Feature
>Affects Versions: 2.5.3
>Reporter: Andrea Scarpino
>Priority: Critical
> Attachments: support_for_revision_in_version.patch
>
>
> The release plugin doesn't support a version value that points to a property 
> which define the version.
> Everytime I use the plugin, the version in the current POM loose the 
> expression. Maybe it could work using the property to which it points?
> {noformat}
> $ grep '' pom.xml
> ${parent.project.version}
> $ grep '' pom.xml
> 0.0.1-SNAPSHOT
> {noformat}
> Could you please implement this or point me to the files that handle this?



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

[jira] [Commented] (MASSEMBLY-875) Maven 3.x is about 10x slower than 2.6

[Stu (JIRA)]

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

Stu commented on MASSEMBLY-875:
---

Tried to run with profiler, but:
{code:java}
[WARNING] Failed to read extensions descriptor 
/home/stuart.smith/.mvn/extensions.xml: Plugin 
com.soebes.maven.extensions:maven-buildtime-profiler:0.2.0 or one of its 
dependencies could not be resolved: Could not find artifact 
com.soebes.maven.extensions:maven-buildtime-profiler:jar:0.2.0 in central{code}

But you can just build it and see that almost all the time is spend on the 
"Building jar.. -with-dependencies.jar" step 

> Maven 3.x is about 10x slower than 2.6
> --
>
> Key: MASSEMBLY-875
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-875
> Project: Maven Assembly Plugin
>  Issue Type: Bug
>Reporter: Stu
>Priority: Minor
>
> In all our java projects, we have a fairly basic assembly configuration, 
> something like this:
> {code:java}
> 
> maven-assembly-plugin
> 2.6
> 
> 
> 
> org.x.x.x
> 
> 
> 
> jar-with-dependencies
> 
> 
> 
> 
> make-assembly
> package
> 
> single
> 
> 
> 
> {code}
> They all take about 10x longer with any 3.x.x version of the maven assembly 
> plugin than the 2.6 version.
> This has been noticed by others:
> [https://stackoverflow.com/questions/9009232/what-sort-of-configuration-issues-or-problems-might-make-maven-assembly-plugin-g/24519615#24519615]
> But not reported as a bug that I could find.
> Although I could only justify "Minor" for the priority, this is really is a 
> blocker for us moving to 3.x.x
> The upgrade is just not worth taking your build from < 10 sec to > 50 sec.
> (For this particular build, it went from about ~ 7 sec to ~ 57 sec.)



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

[jira] [Created] (MRELEASE-997) Unable to release:perform on windows if a file name contains spaces on windows

[JIRA]

Juan Pablo Santos Rodríguez created MRELEASE-997:


 Summary: Unable to release:perform on windows if a file name 
contains spaces on windows
 Key: MRELEASE-997
 URL: https://issues.apache.org/jira/browse/MRELEASE-997
 Project: Maven Release Plugin
  Issue Type: Bug
Affects Versions: 2.5.3
Reporter: Juan Pablo Santos Rodríguez


Using the 2.5.3 version of the release plugin, on a Windows 10 machine, to 
generate the vote artifacts for the upcoming JSPWiki 2.10.3, I stumbled upon 
the following error message while doing an {{mvn release:perform}}:

{code}
[ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-release-plugin:2.5.3:prepare (default-cli) on 
project jspwiki-builder: An error occurred during the status check process: 
Exception while executing SCM command.: Error while executing command. Error 
inside systemOut parser: Illegal character in path at index 0: 
"jspwiki-war/src/main/styles/haddock/fontjspwiki/FontJspwiki/Read%20Me.txt"
{code}

which resulted on being unable to prepare the release.

Seems that this is caused by the underlying maven-scm-* artifacts' versions, 
which seem to have caused this issue on other places too (f.ex.: 
[https://issues.jenkins-ci.org/browse/JENKINS-24686]). This behaviour appears 
to be caused by https://issues.apache.org/jira/browse/SCM-772, but that's just 
an impression.

The fix would be to simply bump {{scmVersion}} property from 1.9.4 to 1.9.5 on 
[https://svn.apache.org/viewvc/maven/release/trunk/pom.xml?view=markup#l88]

Steps to reproduce:

{{mvn release:prepare -DdryRun -DautoVersionSubmodules=true}} on 
[https://github.com/apache/jspwiki/commit/0f38188a1c49fbefa957e7486a0ead943b8642d8]

Workaround: declare 1.9.5 versions of maven-scm-* artifacts as 
maven-release-plugin dependencies (as done on the aforementioned Jenkins issue 
and at 
[https://github.com/apache/jspwiki/commit/339d66c349ee0234c6e903b81a6af8d9eae842b5):]
{code:xml}
  
maven-release-plugin
2.5.3

  
org.apache.maven.scm
maven-scm-api
1.9.5
  
  
org.apache.maven.scm
maven-scm-providers-standard
1.9.5
pom
runtime
  

  
{code}



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

[jira] [Commented] (MASSEMBLY-875) Maven 3.x is about 10x slower than 2.6

[Stu (JIRA)]

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

Stu commented on MASSEMBLY-875:
---

Ok, narrowed it down to one dependency in our lib that seems to be tripping the 
perf issues in maven 3.x.x:

{code}

  net.lightbody.bmp
  browsermob-core
  2.1.5

{code}

So if you create an empty project like so:

{code}
http://maven.apache.org/POM/4.0.0; 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 
http://maven.apache.org/xsd/maven-4.0.0.xsd;>
  4.0.0

  com.shareplaylearn
  MASSEMBLY-875
  1.1-SNAPSHOT
  jar

  MASSEMBLY-875
  http://maven.apache.org

  

  
org.apache.maven.plugins
maven-compiler-plugin
3.1

  1.8
  1.8

  
  
maven-assembly-plugin
 3.1.0


  
jar-with-dependencies
  


  
make-assembly
package

  single

  

  

  

  
UTF-8
  

  

  net.lightbody.bmp
  browsermob-core
  2.1.5

  

{code}

Maven assembly 3.1.0:

{code}
[INFO] Building jar: 
/home/stuart.smith/workspace/MASSEMBLY875/target/MASSEMBLY-875-1.1-SNAPSHOT-jar-with-dependencies.jar
[INFO] 
[INFO] BUILD SUCCESS
[INFO] 
[INFO] Total time: 01:39 min
[INFO] Finished at: 2018-02-09T14:14:46-08:00
[INFO] Final Memory: 252M/2695M
[INFO] 
{code}

maven assembly 2.6:
{code}
[INFO] --- maven-assembly-plugin:2.6:single (make-assembly) @ MASSEMBLY-875 ---
[INFO] Building jar: 
/home/stuart.smith/workspace/MASSEMBLY875/target/MASSEMBLY-875-1.1-SNAPSHOT-jar-with-dependencies.jar
[INFO] 
[INFO] BUILD SUCCESS
[INFO] 
[INFO] Total time: 2.548 s
[INFO] Finished at: 2018-02-09T14:12:23-08:00
[INFO] Final Memory: 61M/546M
[INFO] 
{code}

Also of note:
  - each build was triggered with:
{code}
mvn clean && mvn package
{code}
- I ran 3.1.0, 2.6, and then 3.1.0 again. The final run of 3.1.0 is what I used.
- the above ensured dependencies were already downloaded
- the build process is visibly getting stuck on this step in 3.1.0
{code}
[INFO] Building jar: 
/home/stuart.smith/workspace/MASSEMBLY875/target/MASSEMBLY-875-1.1-SNAPSHOT-jar-with-dependencies.jar
{code}
- Check out the increased memory usage in 3.1.0 !!!

> Maven 3.x is about 10x slower than 2.6
> --
>
> Key: MASSEMBLY-875
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-875
> Project: Maven Assembly Plugin
>  Issue Type: Bug
>Reporter: Stu
>Priority: Minor
>
> In all our java projects, we have a fairly basic assembly configuration, 
> something like this:
> {code:java}
> 
> maven-assembly-plugin
> 2.6
> 
> 
> 
> org.x.x.x
> 
> 
> 
> jar-with-dependencies
> 
> 
> 
> 
> make-assembly
> package
> 
> single
> 
> 
> 
> {code}
> They all take about 10x longer with any 3.x.x version of the maven assembly 
> plugin than the 2.6 version.
> This has been noticed by others:
> [https://stackoverflow.com/questions/9009232/what-sort-of-configuration-issues-or-problems-might-make-maven-assembly-plugin-g/24519615#24519615]
> But not reported as a bug that I could find.
> Although I could only justify "Minor" for the priority, this is really is a 
> blocker for us moving to 3.x.x
> The upgrade is just not worth taking your build from < 10 sec to > 50 sec.
> (For this particular build, it went from about ~ 7 sec to ~ 57 sec.)



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

[jira] [Commented] (MASSEMBLY-875) Maven 3.x is about 10x slower than 2.6

[Stu (JIRA)]

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

Stu commented on MASSEMBLY-875:
---

Ok, I'll get this pushed to a public repo, but for now, I created an empty 
project (using maven-archetype-quickstart, and deleting the tests):

 
{code:java}
http://maven.apache.org/POM/4.0.0; 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 
http://maven.apache.org/xsd/maven-4.0.0.xsd;>
  4.0.0

  com.shareplaylearn
  MASSEMBLY-875
  1.1-SNAPSHOT
  jar

  MASSEMBLY-875
  http://maven.apache.org

  

  
org.apache.maven.plugins
maven-compiler-plugin
3.1

  1.8
  1.8

  
  
maven-assembly-plugin
3.1.0

  
jar-with-dependencies
  


  
make-assembly
package

  single

  

  

  

  
UTF-8
  

  

  com.shareplaylearn
  MASSEMBLY-875-lib
  1.2-SNAPSHOT
  

  io.netty
  netty-all

  

  

{code}

I then created another dummy project (no source code) for the lib:

{code}
http://maven.apache.org/POM/4.0.0; 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 
http://maven.apache.org/xsd/maven-4.0.0.xsd;>
  4.0.0

  com.shareplaylearn
  MASSEMBLY-875-lib
  1.2-SNAPSHOT
  jar

  MASSEMBLY-875-lib
  http://maven.apache.org

  

  
UTF-8
  
  

  
org.apache.maven.plugins
maven-compiler-plugin
3.1

  1.8
  1.8

  
  

org.apache.maven.plugins
maven-source-plugin
3.0.1

  
attach-source
verify

  jar-no-fork

  

  

  

  

  com.google.code.gson
  gson
  2.8.2


  net.lightbody.bmp
  browsermob-core
  2.1.5



  junit
  junit
  4.12
  test


  org.mockito
  mockito-core
  2.13.0
  test

  

{code}

I deployed the lib to a local repo, and then built the original project.
With maven assembly 3.1.0 -> over a minute to build the final 
-with-dependencies jar (close to 2 min!):
{code}
[INFO] BUILD SUCCESS
[INFO] 
[INFO] Total time: 01:42 min
[INFO] Finished at: 2018-02-09T14:05:14-08:00
[INFO] Final Memory: 211M/2644M
{code}

With maven assembly 2.6 -> a little over 2 seconds.
{code}
[INFO] Building jar: 
/home/stuart.smith/workspace/MASSEMBLY875/target/MASSEMBLY-875-1.1-SNAPSHOT-jar-with-dependencies.jar
[INFO] 
[INFO] BUILD SUCCESS
[INFO] 
[INFO] Total time: 2.231 s
[INFO] Finished at: 2018-02-09T14:06:34-08:00
[INFO] Final Memory: 56M/408M
{code}

I'll start whittling away the dependencies in the lib, and see what happens 
there.

> Maven 3.x is about 10x slower than 2.6
> --
>
> Key: MASSEMBLY-875
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-875
> Project: Maven Assembly Plugin
>  Issue Type: Bug
>Reporter: Stu
>Priority: Minor
>
> In all our java projects, we have a fairly basic assembly configuration, 
> something like this:
> {code:java}
> 
> maven-assembly-plugin
> 2.6
> 
> 
> 
> org.x.x.x
> 
> 
> 
> jar-with-dependencies
> 
> 
> 
> 
> make-assembly
> package
> 
> single
> 
> 
> 
> {code}
> They all take about 10x longer with any 3.x.x version of the maven assembly 
> plugin than the 2.6 version.
> This has been noticed by others:
> [https://stackoverflow.com/questions/9009232/what-sort-of-configuration-issues-or-problems-might-make-maven-assembly-plugin-g/24519615#24519615]
> But not reported as a bug that I could find.
> Although I could only justify "Minor" for the priority, this is really is a 
> blocker for us moving to 3.x.x
> The upgrade is just not worth taking your build from < 10 sec to > 50 sec.
> (For this particular build, it went from about ~ 7 sec to ~ 57 sec.)



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

[jira] [Commented] (MNG-6127) Fix plugin execution configuration interference

[Hudson (JIRA)]

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

Hudson commented on MNG-6127:
-

Build succeeded in Jenkins: Maven TLP (wip) » maven » MNG-6352-print-version #2

See 
https://builds.apache.org/job/maven-wip/job/maven/job/MNG-6352-print-version/2/

> Fix plugin execution configuration interference
> ---
>
> Key: MNG-6127
> URL: https://issues.apache.org/jira/browse/MNG-6127
> Project: Maven
>  Issue Type: Bug
>  Components: core
>Affects Versions: 3.3.9
>Reporter: Mario Krizmanic
>Assignee: Robert Scholte
>Priority: Major
> Fix For: 3.5.2
>
>
> The plugin execution configuration may interfere across maven modules 
> included in a build in case a plugin extension provides a default 
> configuration.
> Because the custom plugin configuration defined in the maven modules is 
> merged to the plugin execution configuration and the merged configuration is 
> re-used during building the other included maven modules, so the other maven 
> modules may be build using the invalid configuration.



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

[jira] [Commented] (MNG-5753) Allow plugin implementors to choose how they want the configuration created for a particular MojoExecution

[Hudson (JIRA)]

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

Hudson commented on MNG-5753:
-

Build succeeded in Jenkins: Maven TLP (wip) » maven » MNG-6352-print-version #2

See 
https://builds.apache.org/job/maven-wip/job/maven/job/MNG-6352-print-version/2/

> Allow plugin implementors to choose how they want the configuration created 
> for a particular MojoExecution
> --
>
> Key: MNG-5753
> URL: https://issues.apache.org/jira/browse/MNG-5753
> Project: Maven
>  Issue Type: New Feature
>Reporter: Jason van Zyl
>Assignee: Jason van Zyl
>Priority: Minor
> Fix For: 3.3.1
>
>
> Provide finer grained control over how a  is processed before 
> handing a final mojo configuration over the Configurator which takes the 
> configuration and applies it to the Mojo. My specific use case is that I want 
> to allow many mojos to be configured clearly by scoping the configuration for 
> a Mojo by Mojo name.



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

[jira] [Commented] (MNG-6352) Printout version information at the end of the build

[Robert Scholte (JIRA)]

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

Robert Scholte commented on MNG-6352:
-

Yes, even without the braces

> Printout version information at the end of the build
> 
>
> Key: MNG-6352
> URL: https://issues.apache.org/jira/browse/MNG-6352
> Project: Maven
>  Issue Type: Improvement
>  Components: core
>Affects Versions: 3.5.2
>Reporter: Karl Heinz Marbaise
>Priority: Trivial
> Fix For: 3.5.3
>
>
> At the end of the buid in particular of a mutli module build we should print 
> the information about the versions of modules (in case of aggregators) or 
> only a single version in case of a multi module build as an information for 
> the user.



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

[jira] [Commented] (MSITE-810) HTML code not injected in generated element

[Roberto Benedetti (JIRA)]

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

Roberto Benedetti commented on MSITE-810:
-

The issue was due to a custom skin based on the retired stylus skin, which 
can't handle script tags wrapped in CDATA.

It would be nice if the plugin could warn about old/incompatible skins.

> HTML code not injected in generated  element
> --
>
> Key: MSITE-810
> URL: https://issues.apache.org/jira/browse/MSITE-810
> Project: Maven Site Plugin
>  Issue Type: Bug
>  Components: documentation, site:deploy
>Affects Versions: 3.6, 3.7
> Environment: Windows 7 64 bit
> Java 1.7.0_161
> Maven 3.5.2
> maven-site-plugin 3.6 or 3.7
>Reporter: Roberto Benedetti
>Priority: Blocker
>  Labels: documentation
>
> According to 
> [documentation|https://maven.apache.org/plugins/maven-site-plugin/examples/sitedescriptor.html#Inject_xhtml_into_.3Chead.3E]
>  a script can be injected into generated  element adding it to 
> /project/body/head element of site descriptor.
> It worked fine with versions up to version 3.4.
> I tried to upgrade to version 3.6 and 3.7 and it does not work
>  



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

[jira] [Commented] (MNG-6352) Printout version information at the end of the build

[Karl Heinz Marbaise (JIRA)]

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

Karl Heinz Marbaise commented on MNG-6352:
--

Had you something more like this in mind?
{code}
[INFO] --- maven-clean-plugin:3.0.0:clean (default-clean) @ assembly ---
[INFO] 
[INFO] Reactor Summary:
[INFO]
[INFO] parent (5.0.1-SNAPSHOT)  SUCCESS [  0.235 s]
[INFO] domain (5.0.1-SNAPSHOT)  SUCCESS [  0.002 s]
[INFO] service-client (5.0.1-SNAPSHOT)  SUCCESS [  0.001 s]
[INFO] webgui (5.0.1-SNAPSHOT)  SUCCESS [  0.003 s]
[INFO] service (5.0.1-SNAPSHOT) ... SUCCESS [  0.002 s]
[INFO] app (5.0.1-SNAPSHOT) ... SUCCESS [  0.002 s]
[INFO] appasm (5.0.1-SNAPSHOT)  SUCCESS [  0.002 s]
[INFO] shade (5.0.1-SNAPSHOT) . SUCCESS [  0.003 s]
[INFO] assembly (5.0.1-SNAPSHOT) .. SUCCESS [  0.002 s]
[INFO] 
[INFO] BUILD SUCCESS
[INFO] 
[INFO] Total time: 0.713 s
[INFO] Finished at: 2018-02-09T18:32:58+01:00
[INFO] 
{code}

> Printout version information at the end of the build
> 
>
> Key: MNG-6352
> URL: https://issues.apache.org/jira/browse/MNG-6352
> Project: Maven
>  Issue Type: Improvement
>  Components: core
>Affects Versions: 3.5.2
>Reporter: Karl Heinz Marbaise
>Priority: Trivial
> Fix For: 3.5.3
>
>
> At the end of the buid in particular of a mutli module build we should print 
> the information about the versions of modules (in case of aggregators) or 
> only a single version in case of a multi module build as an information for 
> the user.



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

[jira] [Closed] (MDEP-598) CLONE - Unpack goal fails in java versions earlier than 7

[Robert Scholte (JIRA)]

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

Robert Scholte closed MDEP-598.
---
Resolution: Won't Fix

The most recent versions of Maven require Java 7, that's the current standard. 

Trying to stay compatible with older versions will block contributions and 
innovations. So if you want to unpack with you have 2 options:
 * change the runtime to at least Java 1.7 
 * lock the plugin version to the last compatible version, i.e. 2.9

> CLONE - Unpack goal fails in java versions earlier than 7
> -
>
> Key: MDEP-598
> URL: https://issues.apache.org/jira/browse/MDEP-598
> Project: Maven Dependency Plugin
>  Issue Type: Bug
>  Components: unpack
>Affects Versions: 2.10, 3.0.2
>Reporter: Sam Yi
>Assignee: Robert Scholte
>Priority: Major
>
> Cloning this ticket as the original was closed without resolution.  This 
> issue persists (even in 3.0.2), but it should be noted that it only seems to 
> occur when unpacking tar.bz2 or tar.gz.  I did some digging and found that 
> MDEP-68 brought in plexus-archiver fix 
> 271ba64cf6b2e303d473dab4bb0bf3640f22e46e.  This commit modifies 
> PlexusIoBzip2ResourceCollection and PlexusIoGzipResourceCollection to import 
> org.codehaus.plexus.components.io.attributes.Java7AttributeUtils and 
> org.codehaus.plexus.components.io.attributes.Java7FileAttributes which 
> contains code that requires Java 7+.
>  
> Original ticket description follows:
>  
> When using the unpack goal with Java 1.5 or 1.6, the following error message 
> will appear:
> {{[ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-dependency-plugin:2.10:unpack (unpack) on 
> project ID-JRE_8.0: Execution unpack of goal 
> org.apache.maven.plugins:maven-dependency-plugin:2.10:unpack failed: An API 
> incompatibility was encountered while executing 
> org.apache.maven.plugins:maven-dependency-plugin:2.10:unpack: 
> java.lang.NoSuchMethodError: java.io.File.toPath()Ljava/nio/file/Path;}}
> This is obviously calling a method introduced in Java 7. This contradicts the 
> about page[1] that indicates that JDK 1.5 is the minimum required.
> This bug does not appear until version 2.10. Version 2.9 works fine.
> [1] 
> [http://maven.apache.org/plugins-archives/maven-dependency-plugin-2.10/project-summary.html]



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

[jira] [Commented] (MDEP-598) CLONE - Unpack goal fails in java versions earlier than 7

[Sam Yi (JIRA)]

[ 
https://issues.apache.org/jira/browse/MDEP-598?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16358617#comment-16358617
 ] 

Sam Yi commented on MDEP-598:
-

Steps to reproduce:
 # Download portable-pypy @ 
[https://bitbucket.org/squeaky/portable-pypy/downloads/pypy-5.10.0-linux_x86_64-portable.tar.bz2]
 # Run the following:
{code:java}
mvn install:install-file -DgroupId=com.github.squeaky-pl 
-DartifactId=portable-pypy -Dversion=5.10.0 
-Dfile=pypy-5.10.0-linux_x86_64-portable.tar.bz2 -DgeneratePom=true 
-Dpackaging=tar.bz2{code}
 # Include the following in your pom.xml:{code}

  org.apache.maven.plugins
  maven-dependency-plugin
  2.10
  

  copy-pypy
  process-resources
  
unpack
  
  

  
com.github.squeaky-pl
portable-pypy
5.10.0
tar.bz2
  

/tmp
  

  
{code}


> CLONE - Unpack goal fails in java versions earlier than 7
> -
>
> Key: MDEP-598
> URL: https://issues.apache.org/jira/browse/MDEP-598
> Project: Maven Dependency Plugin
>  Issue Type: Bug
>  Components: unpack
>Affects Versions: 2.10, 3.0.2
>Reporter: Sam Yi
>Assignee: Robert Scholte
>Priority: Major
>
> Cloning this ticket as the original was closed without resolution.  This 
> issue persists (even in 3.0.2), but it should be noted that it only seems to 
> occur when unpacking tar.bz2 or tar.gz.  I did some digging and found that 
> MDEP-68 brought in plexus-archiver fix 
> 271ba64cf6b2e303d473dab4bb0bf3640f22e46e.  This commit modifies 
> PlexusIoBzip2ResourceCollection and PlexusIoGzipResourceCollection to import 
> org.codehaus.plexus.components.io.attributes.Java7AttributeUtils and 
> org.codehaus.plexus.components.io.attributes.Java7FileAttributes which 
> contains code that requires Java 7+.
>  
> Original ticket description follows:
>  
> When using the unpack goal with Java 1.5 or 1.6, the following error message 
> will appear:
> {{[ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-dependency-plugin:2.10:unpack (unpack) on 
> project ID-JRE_8.0: Execution unpack of goal 
> org.apache.maven.plugins:maven-dependency-plugin:2.10:unpack failed: An API 
> incompatibility was encountered while executing 
> org.apache.maven.plugins:maven-dependency-plugin:2.10:unpack: 
> java.lang.NoSuchMethodError: java.io.File.toPath()Ljava/nio/file/Path;}}
> This is obviously calling a method introduced in Java 7. This contradicts the 
> about page[1] that indicates that JDK 1.5 is the minimum required.
> This bug does not appear until version 2.10. Version 2.9 works fine.
> [1] 
> [http://maven.apache.org/plugins-archives/maven-dependency-plugin-2.10/project-summary.html]



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

[jira] [Updated] (MDEP-598) CLONE - Unpack goal fails in java versions earlier than 7

[Sam Yi (JIRA)]

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

Sam Yi updated MDEP-598:

Affects Version/s: 3.0.2
  Description: 
Cloning this ticket as the original was closed without resolution.  This issue 
persists (even in 3.0.2), but it should be noted that it only seems to occur 
when unpacking tar.bz2 or tar.gz.  I did some digging and found that MDEP-68 
brought in plexus-archiver fix 271ba64cf6b2e303d473dab4bb0bf3640f22e46e.  This 
commit modifies PlexusIoBzip2ResourceCollection and 
PlexusIoGzipResourceCollection to import 
org.codehaus.plexus.components.io.attributes.Java7AttributeUtils and 
org.codehaus.plexus.components.io.attributes.Java7FileAttributes which contains 
code that requires Java 7+.

 

Original ticket description follows:

 

When using the unpack goal with Java 1.5 or 1.6, the following error message 
will appear:

{{[ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-dependency-plugin:2.10:unpack (unpack) on 
project ID-JRE_8.0: Execution unpack of goal 
org.apache.maven.plugins:maven-dependency-plugin:2.10:unpack failed: An API 
incompatibility was encountered while executing 
org.apache.maven.plugins:maven-dependency-plugin:2.10:unpack: 
java.lang.NoSuchMethodError: java.io.File.toPath()Ljava/nio/file/Path;}}

This is obviously calling a method introduced in Java 7. This contradicts the 
about page[1] that indicates that JDK 1.5 is the minimum required.

This bug does not appear until version 2.10. Version 2.9 works fine.

[1] 
[http://maven.apache.org/plugins-archives/maven-dependency-plugin-2.10/project-summary.html]

  was:
When using the unpack goal with Java 1.5 or 1.6, the following error message 
will appear:

{{\[ERROR\] Failed to execute goal 
org.apache.maven.plugins:maven-dependency-plugin:2.10:unpack (unpack) on 
project ID-JRE_8.0: Execution unpack of goal 
org.apache.maven.plugins:maven-dependency-plugin:2.10:unpack failed: An API 
incompatibility was encountered while executing 
org.apache.maven.plugins:maven-dependency-plugin:2.10:unpack: 
java.lang.NoSuchMethodError: java.io.File.toPath()Ljava/nio/file/Path;}}

This is obviously calling a method introduced in Java 7. This contradicts the 
about page\[1\] that indicates that JDK 1.5 is the minimum required.

This bug does not appear until version 2.10. Version 2.9 works fine.

\[1\] 
http://maven.apache.org/plugins-archives/maven-dependency-plugin-2.10/project-summary.html


> CLONE - Unpack goal fails in java versions earlier than 7
> -
>
> Key: MDEP-598
> URL: https://issues.apache.org/jira/browse/MDEP-598
> Project: Maven Dependency Plugin
>  Issue Type: Bug
>  Components: unpack
>Affects Versions: 2.10, 3.0.2
>Reporter: Sam Yi
>Assignee: Robert Scholte
>Priority: Major
>
> Cloning this ticket as the original was closed without resolution.  This 
> issue persists (even in 3.0.2), but it should be noted that it only seems to 
> occur when unpacking tar.bz2 or tar.gz.  I did some digging and found that 
> MDEP-68 brought in plexus-archiver fix 
> 271ba64cf6b2e303d473dab4bb0bf3640f22e46e.  This commit modifies 
> PlexusIoBzip2ResourceCollection and PlexusIoGzipResourceCollection to import 
> org.codehaus.plexus.components.io.attributes.Java7AttributeUtils and 
> org.codehaus.plexus.components.io.attributes.Java7FileAttributes which 
> contains code that requires Java 7+.
>  
> Original ticket description follows:
>  
> When using the unpack goal with Java 1.5 or 1.6, the following error message 
> will appear:
> {{[ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-dependency-plugin:2.10:unpack (unpack) on 
> project ID-JRE_8.0: Execution unpack of goal 
> org.apache.maven.plugins:maven-dependency-plugin:2.10:unpack failed: An API 
> incompatibility was encountered while executing 
> org.apache.maven.plugins:maven-dependency-plugin:2.10:unpack: 
> java.lang.NoSuchMethodError: java.io.File.toPath()Ljava/nio/file/Path;}}
> This is obviously calling a method introduced in Java 7. This contradicts the 
> about page[1] that indicates that JDK 1.5 is the minimum required.
> This bug does not appear until version 2.10. Version 2.9 works fine.
> [1] 
> [http://maven.apache.org/plugins-archives/maven-dependency-plugin-2.10/project-summary.html]



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

[jira] [Created] (MDEP-598) CLONE - Unpack goal fails in java versions earlier than 7

[Sam Yi (JIRA)]

Sam Yi created MDEP-598:
---

 Summary: CLONE - Unpack goal fails in java versions earlier than 7
 Key: MDEP-598
 URL: https://issues.apache.org/jira/browse/MDEP-598
 Project: Maven Dependency Plugin
  Issue Type: Bug
  Components: unpack
Affects Versions: 2.10
Reporter: Sam Yi
Assignee: Robert Scholte


When using the unpack goal with Java 1.5 or 1.6, the following error message 
will appear:

{{\[ERROR\] Failed to execute goal 
org.apache.maven.plugins:maven-dependency-plugin:2.10:unpack (unpack) on 
project ID-JRE_8.0: Execution unpack of goal 
org.apache.maven.plugins:maven-dependency-plugin:2.10:unpack failed: An API 
incompatibility was encountered while executing 
org.apache.maven.plugins:maven-dependency-plugin:2.10:unpack: 
java.lang.NoSuchMethodError: java.io.File.toPath()Ljava/nio/file/Path;}}

This is obviously calling a method introduced in Java 7. This contradicts the 
about page\[1\] that indicates that JDK 1.5 is the minimum required.

This bug does not appear until version 2.10. Version 2.9 works fine.

\[1\] 
http://maven.apache.org/plugins-archives/maven-dependency-plugin-2.10/project-summary.html



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

[jira] [Created] (MJAVADOC-513) Aggregate: make order of classpath entries predictable

[Konrad Windszus (JIRA)]

Konrad Windszus created MJAVADOC-513:


 Summary: Aggregate: make order of classpath entries predictable
 Key: MJAVADOC-513
 URL: https://issues.apache.org/jira/browse/MJAVADOC-513
 Project: Maven Javadoc Plugin
  Issue Type: Improvement
  Components: javadoc
Affects Versions: 3.0.0
Reporter: Konrad Windszus


The order of the classpath entries being generated in 
{{AbstractJavadocMojo.getPathElements()}} 
(https://github.com/apache/maven-javadoc-plugin/blob/12dbbde29cf6277ca311cb8afffdf02dbfe0c9b4/src/main/java/org/apache/maven/plugins/javadoc/AbstractJavadocMojo.java#L2601)
 is internally relying on a {{HashMap}} for the compile time artifacts. That is 
an issue if the classpath is not 100% clean (i.e. the same package is exported 
by multiple artifacts) because then the success depends on the order which is 
not predicable for regular {{HashMaps}}. Unclean classpaths are unfortunately 
pretty common in reality. 

To make builds more reliable please use a {{LinkedHashMap}} instead as that 
will keep the insertion order. 

Also since elements being returned first have a higher precedence the ones 
being maintained via {{additionalDependencies}} should be added first (after 
the module's target directory but before the compileArtifacts) to allow to 
enforce usage of a certain module for dedicated classes.



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

[jira] [Commented] (MNG-6256) Maven script can break if "-f" path contains special characters

[Robert Scholte (JIRA)]

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

Robert Scholte commented on MNG-6256:
-

{noformat}

set FILE_ARG=
:arg_loop
if "%~1" == "-f" (
 setx FILE_ARG="%~2"
 shift
 goto process_file_arg
)
if "%~1" == "--file" (
 setx FILE_ARG="%~2"
 shift
 goto process_file_arg
)

{noformat}

 

switching to {{setx}} seems to work. Not sure what the impact will be, so maybe 
better not do it for 3.5.x

> Maven script can break if "-f" path contains special characters 
> 
>
> Key: MNG-6256
> URL: https://issues.apache.org/jira/browse/MNG-6256
> Project: Maven
>  Issue Type: Bug
>  Components: Command Line
>Affects Versions: 3.5.0
> Environment: Windows 10 with PowerShell
>Reporter: Christoph Etzel
>Priority: Major
> Fix For: 3.5.3-candidate
>
>
> Executing maven on Windows using the {{\-f}} or {{--file}} parameter to 
> specify an alternate POM file can break the script if the path contains 
> special characters. 
> It was originally discovered on a Windows Jenkins instance with working 
> directory located under C:\Program Files (x86)\Jenkins..
> Example:
> {code:java}mvn -f "folderWithClosing)Bracket/pomFolder"{code}
> Command line output: {{"Bracket/pomFolder" kann syntaktisch an dieser Stelle 
> nicht verarbeitet werden.}}
> Just for fun: Starting calc from maven script using {{\-f}}
> {code:java}mvn -f " ' & start calc"{code}
> Command line output: {{POM file  '}} and a new calculator process
> The bug was introduced with commit 
> https://github.com/apache/maven/commit/f8ab2a650f32d5d87126d341d9bbfccbf99fd0ca
>  for issue MNG-5889.
> Workaround: Use maven 3.3.9 or below
> Possible fix: Escape {{%FILE_ARG%}} and {{%POM_DIR%}} with {{"}} in {{echo}} 
> commands in {{maven.cmd}} (line 120 and 129).



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

[GitHub] maven-archetype pull request #21: fixed typo repsoitory

[deki]

GitHub user deki opened a pull request:

https://github.com/apache/maven-archetype/pull/21

fixed typo repsoitory



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

$ git pull https://github.com/deki/maven-archetype patch-1

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

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


commit 5132ee8e96c306d79a1e09af3bef21ccbe68f9ee
Author: Dennis Kieselhorst 
Date:   2018-02-09T13:12:13Z

fixed typo repsoitory




---

[jira] [Updated] (SCM-860) add goal creates creates wrong paths if parent pom is not at root directory

[Michael Kutschke (JIRA)]

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

Michael Kutschke updated SCM-860:
-
Description: 
For reference: 
[https://stackoverflow.com/questions/48689960/maven-scm-plugin-and-relative-paths]

 

When the pom is not at the root directory, the add goal creates a command that 
includes a relative path from the pom's directory instead of the root 
directory. Either that, or relative paths like /.. are dropped.

 Directory structure of the project:
*  .git
** src
*** parent
 pom.xml
*** submodule
 pom.xml
 addme.product

Example pom:

 
{code:xml}
http://maven.apache.org/POM/4.0.0; 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance; 
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 
http://maven.apache.org/xsd/maven-4.0.0.xsd;>



scm:git:file://../../.git
  


4.0.0
grp
artif
1.0.0
pom



  ../submodule 






org.apache.maven.plugins
maven-release-plugin
2.5.3

true
true


org.eclipse.tycho:tycho-versions-plugin:${tycho-version}:update-eclipse-metadata
 
org.apache.maven.plugins:maven-scm-plugin:1.9.5:add 




org.eclipse.tycho:tycho-versions-plugin:${tycho-version}:update-eclipse-metadata
 
org.apache.maven.plugins:maven-scm-plugin:1.9.5:add 



   

   org.apache.maven.plugins
   maven-scm-plugin
   1.9.5
   
 
   default-cli
   
 add
 checkin
   
   
 
**/META-INF/MANIFEST.MF,**/feature.xml,**/*.product
 **/target/**
   Changing the version to reflect the pom versions 
for the release
   ${project.basedir}/../..
   ${project.basedir}/../..
   
 
   
 



{code}

Leads to output like this:

[INFO] Executing: cmd.exe /X /C "git add -- 
src\parent\src\submodule\addme.product"
[INFO] Working directory: D:\git\project\src\parent\..\..
[ERROR] Provider message:
[ERROR] The git-add command failed.
[ERROR] Command output:
[ERROR] fatal: pathspec 'src\parent\src\submodule\addme.product' did not match 
any files


I think this is the jgit provider, but am unsure how to check that it is not 
the gitexe provider.

  was:
For reference: 
[https://stackoverflow.com/questions/48689960/maven-scm-plugin-and-relative-paths]

 

When the pom is not at the root directory, the add goal creates a command that 
includes a relative path from the pom's directory instead of the root 
directory. Either that, or relative paths like /.. are dropped.

 Directory structure of the project:
 - .git
 - src
- parent
   - pom.xml
- submodule
   - pom.xml
   - addme.product

Example pom:

 
{code:xml}
http://maven.apache.org/POM/4.0.0; 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance; 
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 
http://maven.apache.org/xsd/maven-4.0.0.xsd;>



scm:git:file://../../.git
  


4.0.0
grp
artif
1.0.0
pom



  ../submodule 






org.apache.maven.plugins
maven-release-plugin
2.5.3

true
true


org.eclipse.tycho:tycho-versions-plugin:${tycho-version}:update-eclipse-metadata
 
org.apache.maven.plugins:maven-scm-plugin:1.9.5:add 




org.eclipse.tycho:tycho-versions-plugin:${tycho-version}:update-eclipse-metadata
 
org.apache.maven.plugins:maven-scm-plugin:1.9.5:add 



   

   org.apache.maven.plugins
   maven-scm-plugin
   1.9.5
   
 
   default-cli
   
 add
 checkin
   
   
 
**/META-INF/MANIFEST.MF,**/feature.xml,**/*.product
 **/target/**
   Changing the version to reflect the pom versions 
for the release
   ${project.basedir}/../..
   ${project.basedir}/../..
   
 
   
 

[jira] [Comment Edited] (MJAVADOC-511) Doclint regression in 3.0.0

[Andy Seaborne (JIRA)]

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

Andy Seaborne edited comment on MJAVADOC-511 at 2/9/18 9:27 AM:


There are many blog pages describing the use of 
{{-Xdoclint:none}}. It would be helpful to 
at least warn when this is used and ignored.

I encountered this effect while upgrading a build to work with Java9 using the 
information in 
https://cwiki.apache.org/confluence/display/MAVEN/Java+9+-+Jigsaw


was (Author: andy.seaborne):
There are many blog pages describing the use of 
{{-Xdoclint:none}}. It would be helpful to 
at least warn when this is used and ignored.


> Doclint regression in 3.0.0
> ---
>
> Key: MJAVADOC-511
> URL: https://issues.apache.org/jira/browse/MJAVADOC-511
> Project: Maven Javadoc Plugin
>  Issue Type: Bug
>  Components: javadoc
>Affects Versions: 3.0.0
>Reporter: Aurélien
>Assignee: Robert Scholte
>Priority: Major
>
> Before 3.0.0 it was possible to disable doclint validation by using the 
> parameter {{}}
> {code:java}
> -Xdoclint:none{code}
>  
> Since 3.0.0 this parameter is ignored and the javadoc plugin raises many 
> errors again.
>  
> I understand there is a new parameter, "doclint", to control the doclint 
> validation. However, if the "old way" is not the intended way, would it be 
> possible to deprecate the old option (and show a warning) before actually 
> removing this parameter?



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

[jira] [Commented] (MJAVADOC-511) Doclint regression in 3.0.0

[Andy Seaborne (JIRA)]

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

Andy Seaborne commented on MJAVADOC-511:


There are many blog pages describing the use of 
{{-Xdoclint:none}}. It would be helpful to 
at least warn when this is used and ignored.


> Doclint regression in 3.0.0
> ---
>
> Key: MJAVADOC-511
> URL: https://issues.apache.org/jira/browse/MJAVADOC-511
> Project: Maven Javadoc Plugin
>  Issue Type: Bug
>  Components: javadoc
>Affects Versions: 3.0.0
>Reporter: Aurélien
>Assignee: Robert Scholte
>Priority: Major
>
> Before 3.0.0 it was possible to disable doclint validation by using the 
> parameter {{}}
> {code:java}
> -Xdoclint:none{code}
>  
> Since 3.0.0 this parameter is ignored and the javadoc plugin raises many 
> errors again.
>  
> I understand there is a new parameter, "doclint", to control the doclint 
> validation. However, if the "old way" is not the intended way, would it be 
> possible to deprecate the old option (and show a warning) before actually 
> removing this parameter?



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

[jira] [Created] (SCM-860) add goal creates creates wrong paths if parent pom is not at root directory

[Michael Kutschke (JIRA)]

Michael Kutschke created SCM-860:


 Summary: add goal creates creates wrong paths if parent pom is not 
at root directory
 Key: SCM-860
 URL: https://issues.apache.org/jira/browse/SCM-860
 Project: Maven SCM
  Issue Type: Bug
  Components: maven-scm-provider-jgit
Affects Versions: 1.9.5
 Environment: Windows, mvn 3.5.2, mvn:scm 1.9.5
Reporter: Michael Kutschke


For reference: 
[https://stackoverflow.com/questions/48689960/maven-scm-plugin-and-relative-paths]

 

When the pom is not at the root directory, the add goal creates a command that 
includes a relative path from the pom's directory instead of the root 
directory. Either that, or relative paths like /.. are dropped.

 Directory structure of the project:
 - .git
 - src
- parent
   - pom.xml
- submodule
   - pom.xml
   - addme.product

Example pom:

 
{code:xml}
http://maven.apache.org/POM/4.0.0; 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance; 
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 
http://maven.apache.org/xsd/maven-4.0.0.xsd;>



scm:git:file://../../.git
  


4.0.0
grp
artif
1.0.0
pom



  ../submodule 






org.apache.maven.plugins
maven-release-plugin
2.5.3

true
true


org.eclipse.tycho:tycho-versions-plugin:${tycho-version}:update-eclipse-metadata
 
org.apache.maven.plugins:maven-scm-plugin:1.9.5:add 




org.eclipse.tycho:tycho-versions-plugin:${tycho-version}:update-eclipse-metadata
 
org.apache.maven.plugins:maven-scm-plugin:1.9.5:add 



   

   org.apache.maven.plugins
   maven-scm-plugin
   1.9.5
   
 
   default-cli
   
 add
 checkin
   
   
 
**/META-INF/MANIFEST.MF,**/feature.xml,**/*.product
 **/target/**
   Changing the version to reflect the pom versions 
for the release
   ${project.basedir}/../..
   ${project.basedir}/../..
   
 
   
 



{code}

Leads to output like this:

[INFO] Executing: cmd.exe /X /C "git add -- 
src\parent\src\submodule\addme.product"
[INFO] Working directory: D:\git\project\src\parent\..\..
[ERROR] Provider message:
[ERROR] The git-add command failed.
[ERROR] Command output:
[ERROR] fatal: pathspec 'src\parent\src\submodule\addme.product' did not match 
any files


I think this is the jgit provider, but am unsure how to check that it is not 
the gitexe provider.



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

[jira] [Issue Comment Deleted] (MJAR-244) Missing documentation: unsatisfied link

[Karl Heinz Marbaise (JIRA)]

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

Karl Heinz Marbaise updated MJAR-244:
-
Comment: was deleted

(was: No simply a missing link ...should be fixed of course...)

> Missing documentation: unsatisfied link 
> 
>
> Key: MJAR-244
> URL: https://issues.apache.org/jira/browse/MJAR-244
> Project: Maven JAR Plugin
>  Issue Type: Bug
>  Components: site
>Affects Versions: 3.0.2
>Reporter: Ernst Reissner
>Priority: Major
>
> On homepage [https://maven.apache.org/plugins/maven-jar-plugin/]
> the link "Creating an executable jar file" is not satisfied.
> Is this no longer possible? Then this has to be removed.



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

[jira] [Commented] (MJAR-244) Missing documentation: unsatisfied link

[Karl Heinz Marbaise (JIRA)]

[ 
https://issues.apache.org/jira/browse/MJAR-244?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16358070#comment-16358070
 ] 

Karl Heinz Marbaise commented on MJAR-244:
--

No simply a missing link ...should be fixed of course...

> Missing documentation: unsatisfied link 
> 
>
> Key: MJAR-244
> URL: https://issues.apache.org/jira/browse/MJAR-244
> Project: Maven JAR Plugin
>  Issue Type: Bug
>  Components: site
>Affects Versions: 3.0.2
>Reporter: Ernst Reissner
>Priority: Major
>
> On homepage [https://maven.apache.org/plugins/maven-jar-plugin/]
> the link "Creating an executable jar file" is not satisfied.
> Is this no longer possible? Then this has to be removed.



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