[jira] [Commented] (WAGON-485) ScpWagon parses file size to int causing overflow for large files
[
https://issues.apache.org/jira/browse/WAGON-485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15812972#comment-15812972
]
Hudson commented on WAGON-485:
--
SUCCESS: Integrated in Jenkins build maven-wagon #1334 (See
[https://builds.apache.org/job/maven-wagon/1334/])
[WAGON-485] ScpWagon parses file size to int causing overflow for large
(michaelo:
[http://git-wip-us.apache.org/repos/asf/?p=maven-wagon.git=commit=3512a321ef678209167fa978d5aafe2fdf6bfff7])
* (edit)
wagon-providers/wagon-ssh/src/main/java/org/apache/maven/wagon/providers/ssh/jsch/ScpWagon.java
> ScpWagon parses file size to int causing overflow for large files
> -
>
> Key: WAGON-485
> URL: https://issues.apache.org/jira/browse/WAGON-485
> Project: Maven Wagon
> Issue Type: Bug
> Components: wagon-ssh
>Affects Versions: 2.10
>Reporter: Silvio Assuncao
>Assignee: Michael Osipov
>Priority: Critical
> Fix For: 2.12
>
>
> {{ScpWagon}} class parses a string value to integer (file size) but if you
> have a large file (3.6 GB for example) the file size is 3865470566 in bytes,
> the number is larger than the {{MAX_VALUE}} of integer.
> {code:title=ScpWagon.java|borderStyle=solid}
> public void fillInputData( InputData inputData )
> throws TransferFailedException, ResourceDoesNotExistException {
> ...
> int filesize = Integer.valueOf( line.substring( 5, index ) ).intValue();
> fireTransferDebug( "Remote file size: " + filesize );
> resource.setContentLength( filesize );
> ...
> {code}
> I changed the line to parse using {{Long}} because the
> *resource.setContentLength* method receive a long value too.
> {code:title=ScpWagon.java|borderStyle=solid}
> long filesize = Long.valueOf( line.substring( 5, index ) );
> {code}
> Please check the pull-request https://github.com/apache/maven-wagon/pull/32
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (WAGON-485) ScpWagon parses file size to int causing overflow for large files
[
https://issues.apache.org/jira/browse/WAGON-485?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed WAGON-485.
Resolution: Fixed
Fixed with
[3512a321ef678209167fa978d5aafe2fdf6bfff7|https://git-wip-us.apache.org/repos/asf?p=maven-wagon.git;a=commit;h=3512a321ef678209167fa978d5aafe2fdf6bfff7].
> ScpWagon parses file size to int causing overflow for large files
> -
>
> Key: WAGON-485
> URL: https://issues.apache.org/jira/browse/WAGON-485
> Project: Maven Wagon
> Issue Type: Bug
> Components: wagon-ssh
>Affects Versions: 2.10
>Reporter: Silvio Assuncao
>Assignee: Michael Osipov
>Priority: Critical
> Fix For: 2.12
>
>
> {{ScpWagon}} class parses a string value to integer (file size) but if you
> have a large file (3.6 GB for example) the file size is 3865470566 in bytes,
> the number is larger than the {{MAX_VALUE}} of integer.
> {code:title=ScpWagon.java|borderStyle=solid}
> public void fillInputData( InputData inputData )
> throws TransferFailedException, ResourceDoesNotExistException {
> ...
> int filesize = Integer.valueOf( line.substring( 5, index ) ).intValue();
> fireTransferDebug( "Remote file size: " + filesize );
> resource.setContentLength( filesize );
> ...
> {code}
> I changed the line to parse using {{Long}} because the
> *resource.setContentLength* method receive a long value too.
> {code:title=ScpWagon.java|borderStyle=solid}
> long filesize = Long.valueOf( line.substring( 5, index ) );
> {code}
> Please check the pull-request https://github.com/apache/maven-wagon/pull/32
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (WAGON-485) ScpWagon parses file size to int causing overflow for large files
[
https://issues.apache.org/jira/browse/WAGON-485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15812920#comment-15812920
]
ASF GitHub Bot commented on WAGON-485:
--
Github user asfgit closed the pull request at:
https://github.com/apache/maven-wagon/pull/32
> ScpWagon parses file size to int causing overflow for large files
> -
>
> Key: WAGON-485
> URL: https://issues.apache.org/jira/browse/WAGON-485
> Project: Maven Wagon
> Issue Type: Bug
> Components: wagon-ssh
>Affects Versions: 2.10
>Reporter: Silvio Assuncao
>Assignee: Michael Osipov
>Priority: Critical
> Fix For: 2.12
>
>
> {{ScpWagon}} class parses a string value to integer (file size) but if you
> have a large file (3.6 GB for example) the file size is 3865470566 in bytes,
> the number is larger than the {{MAX_VALUE}} of integer.
> {code:title=ScpWagon.java|borderStyle=solid}
> public void fillInputData( InputData inputData )
> throws TransferFailedException, ResourceDoesNotExistException {
> ...
> int filesize = Integer.valueOf( line.substring( 5, index ) ).intValue();
> fireTransferDebug( "Remote file size: " + filesize );
> resource.setContentLength( filesize );
> ...
> {code}
> I changed the line to parse using {{Long}} because the
> *resource.setContentLength* method receive a long value too.
> {code:title=ScpWagon.java|borderStyle=solid}
> long filesize = Long.valueOf( line.substring( 5, index ) );
> {code}
> Please check the pull-request https://github.com/apache/maven-wagon/pull/32
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (WAGON-485) ScpWagon parses file size to int causing overflow for large files
[
https://issues.apache.org/jira/browse/WAGON-485?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated WAGON-485:
-
Summary: ScpWagon parses file size to int causing overflow for large files
(was: ScpWagon file size parsing to int causes overflow for large files)
> ScpWagon parses file size to int causing overflow for large files
> -
>
> Key: WAGON-485
> URL: https://issues.apache.org/jira/browse/WAGON-485
> Project: Maven Wagon
> Issue Type: Bug
> Components: wagon-ssh
>Affects Versions: 2.10
>Reporter: Silvio Assuncao
>Assignee: Michael Osipov
>Priority: Critical
> Fix For: 2.12
>
>
> {{ScpWagon}} class parses a string value to integer (file size) but if you
> have a large file (3.6 GB for example) the file size is 3865470566 in bytes,
> the number is larger than the {{MAX_VALUE}} of integer.
> {code:title=ScpWagon.java|borderStyle=solid}
> public void fillInputData( InputData inputData )
> throws TransferFailedException, ResourceDoesNotExistException {
> ...
> int filesize = Integer.valueOf( line.substring( 5, index ) ).intValue();
> fireTransferDebug( "Remote file size: " + filesize );
> resource.setContentLength( filesize );
> ...
> {code}
> I changed the line to parse using {{Long}} because the
> *resource.setContentLength* method receive a long value too.
> {code:title=ScpWagon.java|borderStyle=solid}
> long filesize = Long.valueOf( line.substring( 5, index ) );
> {code}
> Please check the pull-request https://github.com/apache/maven-wagon/pull/32
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (WAGON-485) ScpWagon file size parsing to int causes overflow for large files
[
https://issues.apache.org/jira/browse/WAGON-485?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated WAGON-485:
-
Summary: ScpWagon file size parsing to int causes overflow for large files
(was: Integer Filesize)
> ScpWagon file size parsing to int causes overflow for large files
> -
>
> Key: WAGON-485
> URL: https://issues.apache.org/jira/browse/WAGON-485
> Project: Maven Wagon
> Issue Type: Bug
> Components: wagon-ssh
>Affects Versions: 2.10
>Reporter: Silvio Assuncao
>Assignee: Michael Osipov
>Priority: Critical
> Fix For: 2.12
>
>
> {{ScpWagon}} class parses a string value to integer (file size) but if you
> have a large file (3.6 GB for example) the file size is 3865470566 in bytes,
> the number is larger than the {{MAX_VALUE}} of integer.
> {code:title=ScpWagon.java|borderStyle=solid}
> public void fillInputData( InputData inputData )
> throws TransferFailedException, ResourceDoesNotExistException {
> ...
> int filesize = Integer.valueOf( line.substring( 5, index ) ).intValue();
> fireTransferDebug( "Remote file size: " + filesize );
> resource.setContentLength( filesize );
> ...
> {code}
> I changed the line to parse using {{Long}} because the
> *resource.setContentLength* method receive a long value too.
> {code:title=ScpWagon.java|borderStyle=solid}
> long filesize = Long.valueOf( line.substring( 5, index ) );
> {code}
> Please check the pull-request https://github.com/apache/maven-wagon/pull/32
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (WAGON-485) Integer Filesize
[
https://issues.apache.org/jira/browse/WAGON-485?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated WAGON-485:
-
Description:
{{ScpWagon}} class parses a string value to integer (file size) but if you have
a large file (3.6 GB for example) the file size is 3865470566 in bytes, the
number is larger than the {{MAX_VALUE}} of integer.
{code:title=ScpWagon.java|borderStyle=solid}
public void fillInputData( InputData inputData )
throws TransferFailedException, ResourceDoesNotExistException {
...
int filesize = Integer.valueOf( line.substring( 5, index ) ).intValue();
fireTransferDebug( "Remote file size: " + filesize );
resource.setContentLength( filesize );
...
{code}
I changed the line to parse using {{Long}} because the
*resource.setContentLength* method receive a long value too.
{code:title=ScpWagon.java|borderStyle=solid}
long filesize = Long.valueOf( line.substring( 5, index ) );
{code}
Please check the pull-request https://github.com/apache/maven-wagon/pull/32
was:
ScpWagon class parse a String value to Integer (Filesize) but if you have a
large file (3.6GB for example) the file size is 3865470566 in bytes, the number
is more than the MAX_VALUE of Integer.
{code:title=ScpWagon.java|borderStyle=solid}
public void fillInputData( InputData inputData )
throws TransferFailedException, ResourceDoesNotExistException {
...
int filesize = Integer.valueOf( line.substring( 5, index ) ).intValue();
fireTransferDebug( "Remote file size: " + filesize );
resource.setContentLength( filesize );
...
{code}
I changed the line to parse using Long, because the *resource.setContentLength*
method receive a long value too
{code:title=ScpWagon.java|borderStyle=solid}
long filesize = Long.valueOf( line.substring( 5, index ) );
{code}
Please check the pull-request https://github.com/apache/maven-wagon/pull/32
> Integer Filesize
>
>
> Key: WAGON-485
> URL: https://issues.apache.org/jira/browse/WAGON-485
> Project: Maven Wagon
> Issue Type: Bug
> Components: wagon-ssh
>Affects Versions: 2.10
>Reporter: Silvio Assuncao
>Assignee: Michael Osipov
>Priority: Critical
> Fix For: 2.12
>
>
> {{ScpWagon}} class parses a string value to integer (file size) but if you
> have a large file (3.6 GB for example) the file size is 3865470566 in bytes,
> the number is larger than the {{MAX_VALUE}} of integer.
> {code:title=ScpWagon.java|borderStyle=solid}
> public void fillInputData( InputData inputData )
> throws TransferFailedException, ResourceDoesNotExistException {
> ...
> int filesize = Integer.valueOf( line.substring( 5, index ) ).intValue();
> fireTransferDebug( "Remote file size: " + filesize );
> resource.setContentLength( filesize );
> ...
> {code}
> I changed the line to parse using {{Long}} because the
> *resource.setContentLength* method receive a long value too.
> {code:title=ScpWagon.java|borderStyle=solid}
> long filesize = Long.valueOf( line.substring( 5, index ) );
> {code}
> Please check the pull-request https://github.com/apache/maven-wagon/pull/32
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (WAGON-485) Integer Filesize
[
https://issues.apache.org/jira/browse/WAGON-485?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated WAGON-485:
-
Fix Version/s: 2.12
> Integer Filesize
>
>
> Key: WAGON-485
> URL: https://issues.apache.org/jira/browse/WAGON-485
> Project: Maven Wagon
> Issue Type: Bug
> Components: wagon-ssh
>Affects Versions: 2.10
>Reporter: Silvio Assuncao
>Assignee: Michael Osipov
>Priority: Critical
> Fix For: 2.12
>
>
> ScpWagon class parse a String value to Integer (Filesize) but if you have a
> large file (3.6GB for example) the file size is 3865470566 in bytes, the
> number is more than the MAX_VALUE of Integer.
> {code:title=ScpWagon.java|borderStyle=solid}
> public void fillInputData( InputData inputData )
> throws TransferFailedException, ResourceDoesNotExistException {
> ...
> int filesize = Integer.valueOf( line.substring( 5, index ) ).intValue();
> fireTransferDebug( "Remote file size: " + filesize );
> resource.setContentLength( filesize );
> ...
> {code}
> I changed the line to parse using Long, because the
> *resource.setContentLength* method receive a long value too
> {code:title=ScpWagon.java|borderStyle=solid}
> long filesize = Long.valueOf( line.substring( 5, index ) );
> {code}
> Please check the pull-request https://github.com/apache/maven-wagon/pull/32
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (WAGON-485) Integer Filesize
[
https://issues.apache.org/jira/browse/WAGON-485?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov reassigned WAGON-485:
Assignee: Michael Osipov
> Integer Filesize
>
>
> Key: WAGON-485
> URL: https://issues.apache.org/jira/browse/WAGON-485
> Project: Maven Wagon
> Issue Type: Bug
> Components: wagon-ssh
>Affects Versions: 2.10
>Reporter: Silvio Assuncao
>Assignee: Michael Osipov
>Priority: Critical
> Fix For: 2.12
>
>
> ScpWagon class parse a String value to Integer (Filesize) but if you have a
> large file (3.6GB for example) the file size is 3865470566 in bytes, the
> number is more than the MAX_VALUE of Integer.
> {code:title=ScpWagon.java|borderStyle=solid}
> public void fillInputData( InputData inputData )
> throws TransferFailedException, ResourceDoesNotExistException {
> ...
> int filesize = Integer.valueOf( line.substring( 5, index ) ).intValue();
> fireTransferDebug( "Remote file size: " + filesize );
> resource.setContentLength( filesize );
> ...
> {code}
> I changed the line to parse using Long, because the
> *resource.setContentLength* method receive a long value too
> {code:title=ScpWagon.java|borderStyle=solid}
> long filesize = Long.valueOf( line.substring( 5, index ) );
> {code}
> Please check the pull-request https://github.com/apache/maven-wagon/pull/32
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (MNG-6154) load properties from file not using plugin
[
https://issues.apache.org/jira/browse/MNG-6154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Miroslav Zaťko closed MNG-6154.
---
Resolution: Won't Fix
It is possible to achieve the same using simple maven extension so I am closing
this request.
> load properties from file not using plugin
> --
>
> Key: MNG-6154
> URL: https://issues.apache.org/jira/browse/MNG-6154
> Project: Maven
> Issue Type: New Feature
>Reporter: Miroslav Zaťko
>
> In many usecases there is need of load properties from file at build start.
> It could be probably done similar way as it is for {{}} in
> {{settings-security.xml}} where we can use {{}} referring file
> where is master password stored instead of listing it directly. However
> something like
> {quote}
>
>path1/to1/file1
>path2/to2/file2
>..
>
> {quote}
> would be better probably and we can offer this property-name.
> Other possibility, maybe easier is to make values from {{}} more
> like properties and make it's values available directly in pom.
> This feature is definitely missing in maven since beginning. Using plugins
> like properties-maven-plugin is not usable when running particular goal (e.g.
> {{mvn liquibase:update}}), not lifecycle build.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (WAGON-485) Integer Filesize
[
https://issues.apache.org/jira/browse/WAGON-485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15812837#comment-15812837
]
ASF GitHub Bot commented on WAGON-485:
--
Github user stephenc commented on the issue:
https://github.com/apache/maven-wagon/pull/32
LGTM
> Integer Filesize
>
>
> Key: WAGON-485
> URL: https://issues.apache.org/jira/browse/WAGON-485
> Project: Maven Wagon
> Issue Type: Bug
> Components: wagon-ssh
>Affects Versions: 2.10
>Reporter: Silvio Assuncao
>Priority: Critical
>
> ScpWagon class parse a String value to Integer (Filesize) but if you have a
> large file (3.6GB for example) the file size is 3865470566 in bytes, the
> number is more than the MAX_VALUE of Integer.
> {code:title=ScpWagon.java|borderStyle=solid}
> public void fillInputData( InputData inputData )
> throws TransferFailedException, ResourceDoesNotExistException {
> ...
> int filesize = Integer.valueOf( line.substring( 5, index ) ).intValue();
> fireTransferDebug( "Remote file size: " + filesize );
> resource.setContentLength( filesize );
> ...
> {code}
> I changed the line to parse using Long, because the
> *resource.setContentLength* method receive a long value too
> {code:title=ScpWagon.java|borderStyle=solid}
> long filesize = Long.valueOf( line.substring( 5, index ) );
> {code}
> Please check the pull-request https://github.com/apache/maven-wagon/pull/32
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (DOXIASITETOOLS-172) Width, height and border values not used for banner display
[
https://issues.apache.org/jira/browse/DOXIASITETOOLS-172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15812796#comment-15812796
]
Michael Osipov commented on DOXIASITETOOLS-172:
---
Just checked the patch, two issues:
1. Set {{alt}} just like Fluido's {{site.vm}} does
2. Don't set {{border="0"}} as default, this isn't documented anywhere. Just
leave it empty.
> Width, height and border values not used for banner display
> ---
>
> Key: DOXIASITETOOLS-172
> URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-172
> Project: Maven Doxia Sitetools
> Issue Type: Bug
> Components: Site renderer
>Affects Versions: 1.7.4
>Reporter: Michael Benz
>Priority: Minor
> Attachments: enable-width-height-border-doxia-sitetools.patch
>
>
> Similar to the issue MSKINS-16 that was fixed for the Fluido skin the Default
> Skin ignores the width and height and border settings in the site descriptor.
> The changes in site.xml were introduced here:
> DOXIASITETOOLS-58
> {code}
>
> Name
> Logo.svg
> 30
> 10
> Logo Title
> 2
>
> {code}
> Created HTML:
> {code}
>
> {code}
> The CSS in maven-base.css would anyways not allow for a border around any
> image - one would need to create a new skin for borders or remove the
> border:none from the img tag.
> {code}
> /* from maven-base.css */
> img {
> border:none;
> }
> /* (...) */
> #banner img {
> border: none;
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (DOXIASITETOOLS-172) Width, height and border values not used for banner display
[
https://issues.apache.org/jira/browse/DOXIASITETOOLS-172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15812777#comment-15812777
]
Michael Osipov edited comment on DOXIASITETOOLS-172 at 1/9/17 8:36 PM:
---
You just found a bug in the default skin CSS, please go ahead and file a ticket
with a patch which removes the {{border: none}}. This style is pretty useless
because we kill our own decoration model setting with that. It should be up to
the user to decide about a border style.
was (Author: michael-o):
You just found a bug in the default skin CSS, please go ahead, file a ticket
with a patch which removes the {{border: none}}. This style is pretty useless
because we kill our own decoration model setting with that. It should be up to
the user to decide about a border style.
> Width, height and border values not used for banner display
> ---
>
> Key: DOXIASITETOOLS-172
> URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-172
> Project: Maven Doxia Sitetools
> Issue Type: Bug
> Components: Site renderer
>Affects Versions: 1.7.4
>Reporter: Michael Benz
>Priority: Minor
> Attachments: enable-width-height-border-doxia-sitetools.patch
>
>
> Similar to the issue MSKINS-16 that was fixed for the Fluido skin the Default
> Skin ignores the width and height and border settings in the site descriptor.
> The changes in site.xml were introduced here:
> DOXIASITETOOLS-58
> {code}
>
> Name
> Logo.svg
> 30
> 10
> Logo Title
> 2
>
> {code}
> Created HTML:
> {code}
>
> {code}
> The CSS in maven-base.css would anyways not allow for a border around any
> image - one would need to create a new skin for borders or remove the
> border:none from the img tag.
> {code}
> /* from maven-base.css */
> img {
> border:none;
> }
> /* (...) */
> #banner img {
> border: none;
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (DOXIASITETOOLS-172) Width, height and border values not used for banner display
[
https://issues.apache.org/jira/browse/DOXIASITETOOLS-172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15812777#comment-15812777
]
Michael Osipov commented on DOXIASITETOOLS-172:
---
You just found a bug in the default skin CSS, please go ahead, file a ticket
with a patch which removes the {{border: none}}. This style is pretty useless
because we kill our own decoration model setting with that. It should be up to
the user to decide about a border style.
> Width, height and border values not used for banner display
> ---
>
> Key: DOXIASITETOOLS-172
> URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-172
> Project: Maven Doxia Sitetools
> Issue Type: Bug
> Components: Site renderer
>Affects Versions: 1.7.4
>Reporter: Michael Benz
>Priority: Minor
> Attachments: enable-width-height-border-doxia-sitetools.patch
>
>
> Similar to the issue MSKINS-16 that was fixed for the Fluido skin the Default
> Skin ignores the width and height and border settings in the site descriptor.
> The changes in site.xml were introduced here:
> DOXIASITETOOLS-58
> {code}
>
> Name
> Logo.svg
> 30
> 10
> Logo Title
> 2
>
> {code}
> Created HTML:
> {code}
>
> {code}
> The CSS in maven-base.css would anyways not allow for a border around any
> image - one would need to create a new skin for borders or remove the
> border:none from the img tag.
> {code}
> /* from maven-base.css */
> img {
> border:none;
> }
> /* (...) */
> #banner img {
> border: none;
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (WAGON-485) Integer Filesize
[
https://issues.apache.org/jira/browse/WAGON-485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15812762#comment-15812762
]
ASF GitHub Bot commented on WAGON-485:
--
Github user oassuncao commented on the issue:
https://github.com/apache/maven-wagon/pull/32
I squash the commits.
Thanks
> Integer Filesize
>
>
> Key: WAGON-485
> URL: https://issues.apache.org/jira/browse/WAGON-485
> Project: Maven Wagon
> Issue Type: Bug
> Components: wagon-ssh
>Affects Versions: 2.10
>Reporter: Silvio Assuncao
>Priority: Critical
>
> ScpWagon class parse a String value to Integer (Filesize) but if you have a
> large file (3.6GB for example) the file size is 3865470566 in bytes, the
> number is more than the MAX_VALUE of Integer.
> {code:title=ScpWagon.java|borderStyle=solid}
> public void fillInputData( InputData inputData )
> throws TransferFailedException, ResourceDoesNotExistException {
> ...
> int filesize = Integer.valueOf( line.substring( 5, index ) ).intValue();
> fireTransferDebug( "Remote file size: " + filesize );
> resource.setContentLength( filesize );
> ...
> {code}
> I changed the line to parse using Long, because the
> *resource.setContentLength* method receive a long value too
> {code:title=ScpWagon.java|borderStyle=solid}
> long filesize = Long.valueOf( line.substring( 5, index ) );
> {code}
> Please check the pull-request https://github.com/apache/maven-wagon/pull/32
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (WAGON-485) Integer Filesize
[
https://issues.apache.org/jira/browse/WAGON-485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15812724#comment-15812724
]
ASF GitHub Bot commented on WAGON-485:
--
Github user michael-o commented on the issue:
https://github.com/apache/maven-wagon/pull/32
Please squash them.
> Integer Filesize
>
>
> Key: WAGON-485
> URL: https://issues.apache.org/jira/browse/WAGON-485
> Project: Maven Wagon
> Issue Type: Bug
> Components: wagon-ssh
>Affects Versions: 2.10
>Reporter: Silvio Assuncao
>Priority: Critical
>
> ScpWagon class parse a String value to Integer (Filesize) but if you have a
> large file (3.6GB for example) the file size is 3865470566 in bytes, the
> number is more than the MAX_VALUE of Integer.
> {code:title=ScpWagon.java|borderStyle=solid}
> public void fillInputData( InputData inputData )
> throws TransferFailedException, ResourceDoesNotExistException {
> ...
> int filesize = Integer.valueOf( line.substring( 5, index ) ).intValue();
> fireTransferDebug( "Remote file size: " + filesize );
> resource.setContentLength( filesize );
> ...
> {code}
> I changed the line to parse using Long, because the
> *resource.setContentLength* method receive a long value too
> {code:title=ScpWagon.java|borderStyle=solid}
> long filesize = Long.valueOf( line.substring( 5, index ) );
> {code}
> Please check the pull-request https://github.com/apache/maven-wagon/pull/32
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (WAGON-485) Integer Filesize
[
https://issues.apache.org/jira/browse/WAGON-485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15812722#comment-15812722
]
ASF GitHub Bot commented on WAGON-485:
--
Github user oassuncao commented on the issue:
https://github.com/apache/maven-wagon/pull/32
Changed the code to use `Long.parseLong`
> Integer Filesize
>
>
> Key: WAGON-485
> URL: https://issues.apache.org/jira/browse/WAGON-485
> Project: Maven Wagon
> Issue Type: Bug
> Components: wagon-ssh
>Affects Versions: 2.10
>Reporter: Silvio Assuncao
>Priority: Critical
>
> ScpWagon class parse a String value to Integer (Filesize) but if you have a
> large file (3.6GB for example) the file size is 3865470566 in bytes, the
> number is more than the MAX_VALUE of Integer.
> {code:title=ScpWagon.java|borderStyle=solid}
> public void fillInputData( InputData inputData )
> throws TransferFailedException, ResourceDoesNotExistException {
> ...
> int filesize = Integer.valueOf( line.substring( 5, index ) ).intValue();
> fireTransferDebug( "Remote file size: " + filesize );
> resource.setContentLength( filesize );
> ...
> {code}
> I changed the line to parse using Long, because the
> *resource.setContentLength* method receive a long value too
> {code:title=ScpWagon.java|borderStyle=solid}
> long filesize = Long.valueOf( line.substring( 5, index ) );
> {code}
> Please check the pull-request https://github.com/apache/maven-wagon/pull/32
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (WAGON-485) Integer Filesize
[
https://issues.apache.org/jira/browse/WAGON-485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15812708#comment-15812708
]
ASF GitHub Bot commented on WAGON-485:
--
Github user michael-o commented on a diff in the pull request:
https://github.com/apache/maven-wagon/pull/32#discussion_r95234762
--- Diff:
wagon-providers/wagon-ssh/src/main/java/org/apache/maven/wagon/providers/ssh/jsch/ScpWagon.java
---
@@ -297,7 +297,7 @@ public void fillInputData( InputData inputData )
throw new IOException( "Invalid transfer header: " + line
);
}
-int filesize = Integer.valueOf( line.substring( 5, index )
).intValue();
+long filesize = Long.valueOf( line.substring( 5, index ) );
--- End diff --
Good point. Waiting for this to be integrated and I will ran all tests
against the patch.
> Integer Filesize
>
>
> Key: WAGON-485
> URL: https://issues.apache.org/jira/browse/WAGON-485
> Project: Maven Wagon
> Issue Type: Bug
> Components: wagon-ssh
>Affects Versions: 2.10
>Reporter: Silvio Assuncao
>Priority: Critical
>
> ScpWagon class parse a String value to Integer (Filesize) but if you have a
> large file (3.6GB for example) the file size is 3865470566 in bytes, the
> number is more than the MAX_VALUE of Integer.
> {code:title=ScpWagon.java|borderStyle=solid}
> public void fillInputData( InputData inputData )
> throws TransferFailedException, ResourceDoesNotExistException {
> ...
> int filesize = Integer.valueOf( line.substring( 5, index ) ).intValue();
> fireTransferDebug( "Remote file size: " + filesize );
> resource.setContentLength( filesize );
> ...
> {code}
> I changed the line to parse using Long, because the
> *resource.setContentLength* method receive a long value too
> {code:title=ScpWagon.java|borderStyle=solid}
> long filesize = Long.valueOf( line.substring( 5, index ) );
> {code}
> Please check the pull-request https://github.com/apache/maven-wagon/pull/32
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (WAGON-485) Integer Filesize
[
https://issues.apache.org/jira/browse/WAGON-485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15812675#comment-15812675
]
ASF GitHub Bot commented on WAGON-485:
--
Github user Tunaki commented on a diff in the pull request:
https://github.com/apache/maven-wagon/pull/32#discussion_r95232415
--- Diff:
wagon-providers/wagon-ssh/src/main/java/org/apache/maven/wagon/providers/ssh/jsch/ScpWagon.java
---
@@ -297,7 +297,7 @@ public void fillInputData( InputData inputData )
throw new IOException( "Invalid transfer header: " + line
);
}
-int filesize = Integer.valueOf( line.substring( 5, index )
).intValue();
+long filesize = Long.valueOf( line.substring( 5, index ) );
--- End diff --
Small note, `Long.parseLong` is better here as it wouldn't involve an
unboxing conversion.
> Integer Filesize
>
>
> Key: WAGON-485
> URL: https://issues.apache.org/jira/browse/WAGON-485
> Project: Maven Wagon
> Issue Type: Bug
> Components: wagon-ssh
>Affects Versions: 2.10
>Reporter: Silvio Assuncao
>Priority: Critical
>
> ScpWagon class parse a String value to Integer (Filesize) but if you have a
> large file (3.6GB for example) the file size is 3865470566 in bytes, the
> number is more than the MAX_VALUE of Integer.
> {code:title=ScpWagon.java|borderStyle=solid}
> public void fillInputData( InputData inputData )
> throws TransferFailedException, ResourceDoesNotExistException {
> ...
> int filesize = Integer.valueOf( line.substring( 5, index ) ).intValue();
> fireTransferDebug( "Remote file size: " + filesize );
> resource.setContentLength( filesize );
> ...
> {code}
> I changed the line to parse using Long, because the
> *resource.setContentLength* method receive a long value too
> {code:title=ScpWagon.java|borderStyle=solid}
> long filesize = Long.valueOf( line.substring( 5, index ) );
> {code}
> Please check the pull-request https://github.com/apache/maven-wagon/pull/32
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (WAGON-485) Integer Filesize
[
https://issues.apache.org/jira/browse/WAGON-485?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Silvio Assuncao updated WAGON-485:
--
Description:
ScpWagon class parse a String value to Integer (Filesize) but if you have a
large file (3.6GB for example) the file size is 3865470566 in bytes, the number
is more than the MAX_VALUE of Integer.
{code:title=ScpWagon.java|borderStyle=solid}
public void fillInputData( InputData inputData )
throws TransferFailedException, ResourceDoesNotExistException {
...
int filesize = Integer.valueOf( line.substring( 5, index ) ).intValue();
fireTransferDebug( "Remote file size: " + filesize );
resource.setContentLength( filesize );
...
{code}
I changed the line to parse using Long, because the *resource.setContentLength*
method receive a long value too
{code:title=ScpWagon.java|borderStyle=solid}
long filesize = Long.valueOf( line.substring( 5, index ) );
{code}
Please check the pull-request https://github.com/apache/maven-wagon/pull/32
was:
ScpWagon class parse a String value to Integer (Filesize) but if you have a
large file (3.6GB for example) the file size is 3865470566 in bytes, the number
is more than the MAX_VALUE of Integer.
{code:title=ScpWagon.java|borderStyle=solid}
public void fillInputData( InputData inputData )
throws TransferFailedException, ResourceDoesNotExistException {
...
int filesize = Integer.valueOf( line.substring( 5, index ) ).intValue();
fireTransferDebug( "Remote file size: " + filesize );
resource.setContentLength( filesize );
...
{code}
I changed the line to parse using Long, because the `resource.setContentLength`
receive a long value too
{code:title=ScpWagon.java|borderStyle=solid}
long filesize = Long.valueOf( line.substring( 5, index ) );
{code}
Please check the pull-request https://github.com/apache/maven-wagon/pull/32
> Integer Filesize
>
>
> Key: WAGON-485
> URL: https://issues.apache.org/jira/browse/WAGON-485
> Project: Maven Wagon
> Issue Type: Bug
> Components: wagon-ssh
>Affects Versions: 2.10
>Reporter: Silvio Assuncao
>Priority: Critical
>
> ScpWagon class parse a String value to Integer (Filesize) but if you have a
> large file (3.6GB for example) the file size is 3865470566 in bytes, the
> number is more than the MAX_VALUE of Integer.
> {code:title=ScpWagon.java|borderStyle=solid}
> public void fillInputData( InputData inputData )
> throws TransferFailedException, ResourceDoesNotExistException {
> ...
> int filesize = Integer.valueOf( line.substring( 5, index ) ).intValue();
> fireTransferDebug( "Remote file size: " + filesize );
> resource.setContentLength( filesize );
> ...
> {code}
> I changed the line to parse using Long, because the
> *resource.setContentLength* method receive a long value too
> {code:title=ScpWagon.java|borderStyle=solid}
> long filesize = Long.valueOf( line.substring( 5, index ) );
> {code}
> Please check the pull-request https://github.com/apache/maven-wagon/pull/32
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (WAGON-485) Integer Filesize
[
https://issues.apache.org/jira/browse/WAGON-485?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Silvio Assuncao updated WAGON-485:
--
Description:
ScpWagon class parse a String value to Integer (Filesize) but if you have a
large file (3.6GB for example) the file size is 3865470566 in bytes, the number
is more than the MAX_VALUE of Integer.
{code:title=ScpWagon.java|borderStyle=solid}
public void fillInputData( InputData inputData )
throws TransferFailedException, ResourceDoesNotExistException {
...
int filesize = Integer.valueOf( line.substring( 5, index ) ).intValue();
fireTransferDebug( "Remote file size: " + filesize );
resource.setContentLength( filesize );
...
{code}
I changed the line to parse using Long, because the `resource.setContentLength`
receive a long value too
{code:title=ScpWagon.java|borderStyle=solid}
long filesize = Long.valueOf( line.substring( 5, index ) );
{code}
Please check the pull-request https://github.com/apache/maven-wagon/pull/32
was:
ScpWagon class parse a String value to Integer (Filesize) but if you have a
large file (3.6GB) the file size is 3865470566 in bytes, the number is more
than the MAX_VALUE of Integer.
{code:title=ScpWagon.java|borderStyle=solid}
public void fillInputData( InputData inputData )
throws TransferFailedException, ResourceDoesNotExistException {
...
int filesize = Integer.valueOf( line.substring( 5, index ) ).intValue();
fireTransferDebug( "Remote file size: " + filesize );
resource.setContentLength( filesize );
...
{code}
I changed the line to parse using Long, because the `resource.setContentLength`
receive a long value too
{code:title=ScpWagon.java|borderStyle=solid}
long filesize = Long.valueOf( line.substring( 5, index ) );
{code}
Please check the pull-request https://github.com/apache/maven-wagon/pull/32
> Integer Filesize
>
>
> Key: WAGON-485
> URL: https://issues.apache.org/jira/browse/WAGON-485
> Project: Maven Wagon
> Issue Type: Bug
> Components: wagon-ssh
>Affects Versions: 2.10
>Reporter: Silvio Assuncao
>Priority: Critical
>
> ScpWagon class parse a String value to Integer (Filesize) but if you have a
> large file (3.6GB for example) the file size is 3865470566 in bytes, the
> number is more than the MAX_VALUE of Integer.
> {code:title=ScpWagon.java|borderStyle=solid}
> public void fillInputData( InputData inputData )
> throws TransferFailedException, ResourceDoesNotExistException {
> ...
> int filesize = Integer.valueOf( line.substring( 5, index ) ).intValue();
> fireTransferDebug( "Remote file size: " + filesize );
> resource.setContentLength( filesize );
> ...
> {code}
> I changed the line to parse using Long, because the
> `resource.setContentLength` receive a long value too
> {code:title=ScpWagon.java|borderStyle=solid}
> long filesize = Long.valueOf( line.substring( 5, index ) );
> {code}
> Please check the pull-request https://github.com/apache/maven-wagon/pull/32
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (WAGON-485) Integer Filesize
[
https://issues.apache.org/jira/browse/WAGON-485?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Silvio Assuncao updated WAGON-485:
--
Description:
ScpWagon class parse a String value to Integer (Filesize) but if you have a
large file (3.6GB) the file size is 3865470566 in bytes, the number is more
than the MAX_VALUE of Integer.
{code:title=ScpWagon.java|borderStyle=solid}
public void fillInputData( InputData inputData )
throws TransferFailedException, ResourceDoesNotExistException {
...
int filesize = Integer.valueOf( line.substring( 5, index ) ).intValue();
fireTransferDebug( "Remote file size: " + filesize );
resource.setContentLength( filesize );
...
{code}
I changed the line to parse using Long, because the `resource.setContentLength`
receive a long value too
{code:title=ScpWagon.java|borderStyle=solid}
long filesize = Long.valueOf( line.substring( 5, index ) );
{code}
Please check the pull-request https://github.com/apache/maven-wagon/pull/32
was:
ScpWagon class parse a String value to Integer (Filesize) but if you have a
large file (3.6GB) the file size is 3865470566 in bytes, the number is more
than the MAX_VALUE of Integer.
{code:title=ScpWagon.java|borderStyle=solid}
public void fillInputData( InputData inputData )
throws TransferFailedException, ResourceDoesNotExistException {
...
int filesize = Integer.valueOf( line.substring( 5, index ) ).intValue();
fireTransferDebug( "Remote file size: " + filesize );
resource.setContentLength( filesize );
...
{code}
Changed to parse using Long, because the `resource.setContentLength` receive a
long value too
{code:title=ScpWagon.java|borderStyle=solid}
long filesize = Long.valueOf( line.substring( 5, index ) );
{code}
Please check the pull-request https://github.com/apache/maven-wagon/pull/32
> Integer Filesize
>
>
> Key: WAGON-485
> URL: https://issues.apache.org/jira/browse/WAGON-485
> Project: Maven Wagon
> Issue Type: Bug
> Components: wagon-ssh
>Affects Versions: 2.10
>Reporter: Silvio Assuncao
>Priority: Critical
>
> ScpWagon class parse a String value to Integer (Filesize) but if you have a
> large file (3.6GB) the file size is 3865470566 in bytes, the number is more
> than the MAX_VALUE of Integer.
> {code:title=ScpWagon.java|borderStyle=solid}
> public void fillInputData( InputData inputData )
> throws TransferFailedException, ResourceDoesNotExistException {
> ...
> int filesize = Integer.valueOf( line.substring( 5, index ) ).intValue();
> fireTransferDebug( "Remote file size: " + filesize );
> resource.setContentLength( filesize );
> ...
> {code}
> I changed the line to parse using Long, because the
> `resource.setContentLength` receive a long value too
> {code:title=ScpWagon.java|borderStyle=solid}
> long filesize = Long.valueOf( line.substring( 5, index ) );
> {code}
> Please check the pull-request https://github.com/apache/maven-wagon/pull/32
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (WAGON-485) Integer Filesize
[
https://issues.apache.org/jira/browse/WAGON-485?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Silvio Assuncao updated WAGON-485:
--
Description:
ScpWagon class parse a String value to Integer (Filesize) but if you have a
large file (3.6GB) the file size is 3865470566 in bytes, the number is more
than the MAX_VALUE of Integer.
{code:title=ScpWagon.java|borderStyle=solid}
public void fillInputData( InputData inputData )
throws TransferFailedException, ResourceDoesNotExistException {
...
int filesize = Integer.valueOf( line.substring( 5, index ) ).intValue();
fireTransferDebug( "Remote file size: " + filesize );
resource.setContentLength( filesize );
...
{code}
Changed to parse using Long, because the `resource.setContentLength` receive a
long value too
{code:title=ScpWagon.java|borderStyle=solid}
long filesize = Long.valueOf( line.substring( 5, index ) );
{code}
Please check the pull-request https://github.com/apache/maven-wagon/pull/32
was:
ScpWagon class parse a String value to Integer (Filesize) but if you have a
large file (3.6GB) the file size is 3865470566 in bytes, the number is more
than the MAX_VALUE of Integer.
```
int filesize = Integer.valueOf( line.substring( 5, index ) ).intValue();
fireTransferDebug( "Remote file size: " + filesize );
resource.setContentLength( filesize );
```
Changed to parse using Long, because the `resource.setContentLength` receive a
long value too
```
long filesize = Long.valueOf( line.substring( 5, index ) );
```
Please check the pull-request https://github.com/apache/maven-wagon/pull/32
> Integer Filesize
>
>
> Key: WAGON-485
> URL: https://issues.apache.org/jira/browse/WAGON-485
> Project: Maven Wagon
> Issue Type: Bug
> Components: wagon-ssh
>Affects Versions: 2.10
>Reporter: Silvio Assuncao
>Priority: Critical
>
> ScpWagon class parse a String value to Integer (Filesize) but if you have a
> large file (3.6GB) the file size is 3865470566 in bytes, the number is more
> than the MAX_VALUE of Integer.
> {code:title=ScpWagon.java|borderStyle=solid}
> public void fillInputData( InputData inputData )
> throws TransferFailedException, ResourceDoesNotExistException {
> ...
> int filesize = Integer.valueOf( line.substring( 5, index ) ).intValue();
> fireTransferDebug( "Remote file size: " + filesize );
> resource.setContentLength( filesize );
> ...
> {code}
> Changed to parse using Long, because the `resource.setContentLength` receive
> a long value too
> {code:title=ScpWagon.java|borderStyle=solid}
> long filesize = Long.valueOf( line.substring( 5, index ) );
> {code}
> Please check the pull-request https://github.com/apache/maven-wagon/pull/32
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (WAGON-485) Integer Filesize
[ https://issues.apache.org/jira/browse/WAGON-485?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Silvio Assuncao updated WAGON-485: -- Description: ScpWagon class parse a String value to Integer (Filesize) but if you have a large file (3.6GB) the file size is 3865470566 in bytes, the number is more than the MAX_VALUE of Integer. ``` int filesize = Integer.valueOf( line.substring( 5, index ) ).intValue(); fireTransferDebug( "Remote file size: " + filesize ); resource.setContentLength( filesize ); ``` Changed to parse using Long, because the `resource.setContentLength` receive a long value too ``` long filesize = Long.valueOf( line.substring( 5, index ) ); ``` Please check the pull-request https://github.com/apache/maven-wagon/pull/32 was: ScpWagon class parse a String value to Integer (Filesize) but if you have a large file (3.6GB) the file size is 3865470566 in bytes, the number is more than the MAX_VALUE of Integer. Changed to parse using Long, because the `resource.setContentLength` receive a long value too Please check the pull-request https://github.com/apache/maven-wagon/pull/32 > Integer Filesize > > > Key: WAGON-485 > URL: https://issues.apache.org/jira/browse/WAGON-485 > Project: Maven Wagon > Issue Type: Bug > Components: wagon-ssh >Affects Versions: 2.10 >Reporter: Silvio Assuncao >Priority: Critical > > ScpWagon class parse a String value to Integer (Filesize) but if you have a > large file (3.6GB) the file size is 3865470566 in bytes, the number is more > than the MAX_VALUE of Integer. > ``` > int filesize = Integer.valueOf( line.substring( 5, index ) ).intValue(); > fireTransferDebug( "Remote file size: " + filesize ); > resource.setContentLength( filesize ); > ``` > Changed to parse using Long, because the `resource.setContentLength` receive > a long value too > ``` > long filesize = Long.valueOf( line.substring( 5, index ) ); > ``` > Please check the pull-request https://github.com/apache/maven-wagon/pull/32 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (WAGON-485) Integer Filesize
Silvio Assuncao created WAGON-485: - Summary: Integer Filesize Key: WAGON-485 URL: https://issues.apache.org/jira/browse/WAGON-485 Project: Maven Wagon Issue Type: Bug Components: wagon-ssh Affects Versions: 2.10 Reporter: Silvio Assuncao Priority: Critical ScpWagon class parse a String value to Integer (Filesize) but if you have a large file (3.6GB) the file size is 3865470566 in bytes, the number is more than the MAX_VALUE of Integer. Changed to parse using Long, because the `resource.setContentLength` receive a long value too Please check the pull-request https://github.com/apache/maven-wagon/pull/32 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MNG-5962) mvn fails when the current directory has spaces in between
[
https://issues.apache.org/jira/browse/MNG-5962?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Schulte updated MNG-5962:
---
Assignee: (was: Christian Schulte)
> mvn fails when the current directory has spaces in between
> --
>
> Key: MNG-5962
> URL: https://issues.apache.org/jira/browse/MNG-5962
> Project: Maven
> Issue Type: Bug
> Components: Command Line
>Affects Versions: 3.3.3, 3.3.9
> Environment: Windows 7
>Reporter: Miriam Lee
>Priority: Minor
> Labels: easyfix, newbie
> Fix For: 3.5.0
>
> Attachments: MNG-5962-apache-maven.patch
>
> Original Estimate: 2h
> Remaining Estimate: 2h
>
> Executing {{mvn.cmd}} when the current directory has spaces in between
> outputs {{The system cannot find the path specified.}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MNG-6053) Unsafe System Properties copy in MavenRepositorySystemUtils, causing NPEs
[
https://issues.apache.org/jira/browse/MNG-6053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Schulte updated MNG-6053:
---
Assignee: Guillaume Boué (was: Christian Schulte)
> Unsafe System Properties copy in MavenRepositorySystemUtils, causing NPEs
> -
>
> Key: MNG-6053
> URL: https://issues.apache.org/jira/browse/MNG-6053
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.3.9
> Environment: Eclipse m2e 1.7
>Reporter: Fred Bricon
>Assignee: Guillaume Boué
> Fix For: 3.5.0
>
>
> This bug has been reported in m2e
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=493871:
> {quote}
> I'm occasionally, not 100% reliably reproducible, but regularly enough (like
> it occurs every now and then, not just once) seeing the error below, in the
> Error Log of Eclipse during workspace rebuilds. This is with M2E 1.7.0. --
> I'm not sure if this is just "annoying" or actually prevents M2E from
> correctly configuring projects (?). Either way, perhaps it would be possible
> to "harden" respective code to prevent this?
> java.lang.NullPointerException
> at java.util.Hashtable.put(Hashtable.java:459)
> at
> org.apache.maven.repository.internal.MavenRepositorySystemUtils.newSession(MavenRepositorySystemUtils.java:133)
> at
> org.apache.maven.internal.aether.DefaultRepositorySystemSessionFactory.newRepositorySession(DefaultRepositorySystemSessionFactory.java:98)
> at
> org.apache.maven.DefaultMaven.newRepositorySession(DefaultMaven.java:352)
> at
> org.eclipse.m2e.core.internal.embedder.MavenImpl.createRepositorySession(MavenImpl.java:309)
> {quote}
> Looking at
> https://github.com/apache/maven/blob/86b656167923923e2e416def4a48303b4e6248fa/maven-aether-provider/src/main/java/org/apache/maven/repository/internal/MavenRepositorySystemUtils.java#L132,
> it seems some system property is null (maybe due to some concurrency issue),
> and given that Hashtable doesn't support null values, then it throws an NPE
> on the put() call
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (DOXIASITETOOLS-172) Width, height and border values not used for banner display
[
https://issues.apache.org/jira/browse/DOXIASITETOOLS-172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Benz updated DOXIASITETOOLS-172:
Description:
Similar to the issue MSKINS-16 that was fixed for the Fluido skin the Default
Skin ignores the width and height and border settings in the site descriptor.
The changes in site.xml were introduced here:
DOXIASITETOOLS-58
{code}
Name
Logo.svg
30
10
Logo Title
2
{code}
Created HTML:
{code}
{code}
The CSS in maven-base.css would anyways not allow for a border around any image
- one would need to create a new skin for borders or remove the border:none
from the img tag.
{code}
/* from maven-base.css */
img {
border:none;
}
/* (...) */
#banner img {
border: none;
}
{code}
was:
Similar to the issue MSKINS-16 that was fixed for the Fluido skin the Default
Skin ignores the width and height and border settings in the site descriptor.
The changes in site.xml were introduced here:
DOXIASITETOOLS-58
{code}
Name
Logo.svg
30
10
Logo Title
2
{code}
Created HTML:
{code}
{code}
> Width, height and border values not used for banner display
> ---
>
> Key: DOXIASITETOOLS-172
> URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-172
> Project: Maven Doxia Sitetools
> Issue Type: Bug
> Components: Site renderer
>Affects Versions: 1.7.4
>Reporter: Michael Benz
>Priority: Minor
> Attachments: enable-width-height-border-doxia-sitetools.patch
>
>
> Similar to the issue MSKINS-16 that was fixed for the Fluido skin the Default
> Skin ignores the width and height and border settings in the site descriptor.
> The changes in site.xml were introduced here:
> DOXIASITETOOLS-58
> {code}
>
> Name
> Logo.svg
> 30
> 10
> Logo Title
> 2
>
> {code}
> Created HTML:
> {code}
>
> {code}
> The CSS in maven-base.css would anyways not allow for a border around any
> image - one would need to create a new skin for borders or remove the
> border:none from the img tag.
> {code}
> /* from maven-base.css */
> img {
> border:none;
> }
> /* (...) */
> #banner img {
> border: none;
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (DOXIASITETOOLS-172) Width, height and border values not used for banner display
[
https://issues.apache.org/jira/browse/DOXIASITETOOLS-172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Benz updated DOXIASITETOOLS-172:
Attachment: enable-width-height-border-doxia-sitetools.patch
Patch for doxi-sitetools to enable width and height for banner.
Also border would be correctly set but CSS value border:none overrides this
from img and img #banner.
> Width, height and border values not used for banner display
> ---
>
> Key: DOXIASITETOOLS-172
> URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-172
> Project: Maven Doxia Sitetools
> Issue Type: Bug
> Components: Site renderer
>Affects Versions: 1.7.4
>Reporter: Michael Benz
>Priority: Minor
> Attachments: enable-width-height-border-doxia-sitetools.patch
>
>
> Similar to the issue MSKINS-16 that was fixed for the Fluido skin the Default
> Skin ignores the width and height and border settings in the site descriptor.
> The changes in site.xml were introduced here:
> DOXIASITETOOLS-58
> {code}
>
> Name
> Logo.svg
> 30
> 10
> Logo Title
> 2
>
> {code}
> Created HTML:
> {code}
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MNG-5961) Maven possibly not aware of log4j2
[
https://issues.apache.org/jira/browse/MNG-5961?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15811577#comment-15811577
]
Arnaud HERITIER commented on MNG-5961:
--
This fix is trivial [~stephenc] we could re-apply it with no risk
> Maven possibly not aware of log4j2
> --
>
> Key: MNG-5961
> URL: https://issues.apache.org/jira/browse/MNG-5961
> Project: Maven
> Issue Type: Bug
> Components: Logging
>Affects Versions: 3.3.9
>Reporter: Mike Drob
>Assignee: Arnaud HERITIER
> Fix For: needing-scrub-3.4.0-fallout
>
>
> Using a fresh install of maven 3.3.9 I followed the steps at
> https://garygregory.wordpress.com/2015/03/23/watch-maven-in-color to add
> color highlighting to my output. Everything works as expected, however on all
> usages I would get the warning:
> {noformat}
> [WARN] The SLF4J binding actually used is not supported by Maven:
> org.apache.logging.slf4j.Log4jLoggerFactory
> [WARN] Maven supported bindings are:
> [WARN] (from
> jar:file:/opt/apache-maven-3.3.9/lib/maven-embedder-3.3.9.jar!/META-INF/maven/slf4j-configuration.properties)
> - ch.qos.logback.classic.LoggerContext
> - org.slf4j.helpers.Log4jLoggerFactory
> - org.slf4j.impl.SimpleLoggerFactory
> {noformat}
> This looks pretty harmless, and I was able to suppress it by manually adding
> the line
> {code}
> org.apache.logging.slf4j.Log4jLoggerFactory
> org.apache.maven.cli.logging.impl.Log4j2Configuration
> {code}
> to {{/META-INF/maven/slf4j-configuration.properties}} in
> {{maven-embedder-3.3.9.jar}}.
> I'm not sure that this is a "correct" solution, and I'm not even confident I
> could explain what effect it has, hence not posting a patch, but somebody
> with more knowledge might be able to triage this better. Or offer an
> "official" way to do colorized output.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MDEP-541) Allow for a space character as a pathSeparator in dependency:build-classpath
[
https://issues.apache.org/jira/browse/MDEP-541?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15811557#comment-15811557
]
James Phillpotts commented on MDEP-541:
---
Another use-case - setting the {{Class-Path}} manifest entries when creating an
executable jar with reduced dependencies using the maven shade plugin.
> Allow for a space character as a pathSeparator in dependency:build-classpath
>
>
> Key: MDEP-541
> URL: https://issues.apache.org/jira/browse/MDEP-541
> Project: Maven Dependency Plugin
> Issue Type: Improvement
> Components: build-classpath
>Reporter: Giedrius Noreikis
>
> Currently, the {{dependency:build-classpath}} goal does not allow a space
> character to be specified as a {{pathSeparator}}, which is necessary to
> generate {{Class-Path}} values for manifests.
> Because of a check {{isPathSepSet = StringUtils.isNotEmpty( pathSeparator )}}
> in {{BuildClasspathMojo.java}}, the parameter gets ignored in this case, and
> the classpath is built with a default separator.
> The possible workaround is to fix the path with
> {{build-helper:regex-property}}:
> {code:xml}
>
> org.codehaus.mojo
> build-helper-maven-plugin
>
>
> fix-classpath-for-manifest
> prepare-package
> regex-property
>
> appClasspath
> ${appClasspath}
> ;
>
> false
>
>
>
>
> {code}
> but a fix would allow for a more straightforward solution.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MNG-6110) Upgrade Aether to Maven Resolver
[ https://issues.apache.org/jira/browse/MNG-6110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly updated MNG-6110: -- Summary: Upgrade Aether to Maven Resolver (was: Upgrade Aether to Maven Resolver 1.2) > Upgrade Aether to Maven Resolver > > > Key: MNG-6110 > URL: https://issues.apache.org/jira/browse/MNG-6110 > Project: Maven > Issue Type: Dependency upgrade > Components: Dependencies >Affects Versions: 3.3.9 >Reporter: Harald Wellmann >Assignee: Christian Schulte > Fix For: 3.5.0 > > > Replace Aether by Maven Resolver to make use of the latest bugfixes and > enhancements related to dependency collection. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MNG-6152) Add a Jenkinsfile so that builds.apache.org can use multibranch pipeline
[ https://issues.apache.org/jira/browse/MNG-6152?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly updated MNG-6152: -- Fix Version/s: 3.5.0 > Add a Jenkinsfile so that builds.apache.org can use multibranch pipeline > > > Key: MNG-6152 > URL: https://issues.apache.org/jira/browse/MNG-6152 > Project: Maven > Issue Type: Task > Components: core >Reporter: Stephen Connolly >Assignee: Stephen Connolly > Fix For: 3.5.0 > > > We want to enable multibranch pipeline support on our CI infrastructure so > that all branches can get integration test verification -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (MNG-6152) Add a Jenkinsfile so that builds.apache.org can use multibranch pipeline
[ https://issues.apache.org/jira/browse/MNG-6152?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly resolved MNG-6152. --- Resolution: Fixed > Add a Jenkinsfile so that builds.apache.org can use multibranch pipeline > > > Key: MNG-6152 > URL: https://issues.apache.org/jira/browse/MNG-6152 > Project: Maven > Issue Type: Task > Components: core >Reporter: Stephen Connolly >Assignee: Stephen Connolly > Fix For: 3.5.0 > > > We want to enable multibranch pipeline support on our CI infrastructure so > that all branches can get integration test verification -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (MNG-6151) Force Push master from 737de43e392fc15a0ce366db98d70aa18b3f6c03
[ https://issues.apache.org/jira/browse/MNG-6151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly resolved MNG-6151. --- Resolution: Fixed Fix Version/s: 3.5.0 > Force Push master from 737de43e392fc15a0ce366db98d70aa18b3f6c03 > --- > > Key: MNG-6151 > URL: https://issues.apache.org/jira/browse/MNG-6151 > Project: Maven > Issue Type: Task > Components: core >Reporter: Stephen Connolly >Assignee: Stephen Connolly > Fix For: 3.5.0 > > > See > https://mail-archives.apache.org/mod_mbox/maven-dev/201612.mbox/%3CCA%2BnPnMxERdjJq5ChMNP-HN_AvZOs8sm7Ud5aVcEza0BPnm5ZOw%40mail.gmail.com%3E -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MNG-5976) Replace Plexus Utils OS with Commons Lang SystemUtils
[
https://issues.apache.org/jira/browse/MNG-5976?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Connolly updated MNG-5976:
--
Fix Version/s: wontfix-candidate
> Replace Plexus Utils OS with Commons Lang SystemUtils
> -
>
> Key: MNG-5976
> URL: https://issues.apache.org/jira/browse/MNG-5976
> Project: Maven
> Issue Type: Improvement
> Components: Command Line, Embedding
>Affects Versions: 3.3.9
>Reporter: Michael Osipov
>Assignee: Michael Osipov
> Fix For: wontfix-candidate
>
>
> The {{Os}} class have two issues compared to {{SystemUtils}}:
> 1. It modifies the property values by lowercasing it.
> 2. OS detection has a handful of relic operating systems listed which make
> the detection error-prone. E.g., recent versions of Windows are reported as
> OS family {{dos}} is is plain wrong.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Reopened] (MNG-5976) Replace Plexus Utils OS with Commons Lang SystemUtils
[
https://issues.apache.org/jira/browse/MNG-5976?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Connolly reopened MNG-5976:
---
> Replace Plexus Utils OS with Commons Lang SystemUtils
> -
>
> Key: MNG-5976
> URL: https://issues.apache.org/jira/browse/MNG-5976
> Project: Maven
> Issue Type: Improvement
> Components: Command Line, Embedding
>Affects Versions: 3.3.9
>Reporter: Michael Osipov
>Assignee: Michael Osipov
> Fix For: wontfix-candidate
>
>
> The {{Os}} class have two issues compared to {{SystemUtils}}:
> 1. It modifies the property values by lowercasing it.
> 2. OS detection has a handful of relic operating systems listed which make
> the detection error-prone. E.g., recent versions of Windows are reported as
> OS family {{dos}} is is plain wrong.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MNG-6135) Maven plugins and core extensions are not dependencies, they should be resolved the same way as projects.
[
https://issues.apache.org/jira/browse/MNG-6135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Connolly updated MNG-6135:
--
Fix Version/s: (was: needing-scrub-3.4.0-fallout)
3.6.0-candidate
> Maven plugins and core extensions are not dependencies, they should be
> resolved the same way as projects.
> -
>
> Key: MNG-6135
> URL: https://issues.apache.org/jira/browse/MNG-6135
> Project: Maven
> Issue Type: Bug
>Reporter: Christian Schulte
>Assignee: Christian Schulte
>Priority: Critical
> Fix For: 3.6.0-candidate
>
>
> Due to a bug in the Maven resolver, plugin and core extensions were resolved
> incorrectly: the direct {{test}} and {{provided}} dependencies were ignored.
> Ironically, this fix breaks some plugins because direct {{test}} dependencies
> now take precedence over transitive {{compile}} one: see MNG-5739
> (we know only one case where {{provided}} case has an impact: MPLUGIN-296,
> and in this only case, the new behaviour is more consistent than the previous)
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MNG-6073) Addition of a core extension point to the model builder supporting model finalization.
[ https://issues.apache.org/jira/browse/MNG-6073?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly updated MNG-6073: -- Fix Version/s: (was: needing-scrub-3.4.0-fallout) 3.6.0-candidate > Addition of a core extension point to the model builder supporting model > finalization. > -- > > Key: MNG-6073 > URL: https://issues.apache.org/jira/browse/MNG-6073 > Project: Maven > Issue Type: New Feature >Reporter: Christian Schulte >Assignee: Christian Schulte >Priority: Trivial > Fix For: 3.6.0-candidate > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MNG-5761) Dependency management is not transitive.
[ https://issues.apache.org/jira/browse/MNG-5761?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly updated MNG-5761: -- Fix Version/s: (was: needing-scrub-3.4.0-fallout) 3.6.0-candidate > Dependency management is not transitive. > > > Key: MNG-5761 > URL: https://issues.apache.org/jira/browse/MNG-5761 > Project: Maven > Issue Type: Bug > Components: Dependencies >Affects Versions: 3.2.5 >Reporter: Jeff Schnitzer >Assignee: Christian Schulte >Priority: Critical > Fix For: 3.6.0-candidate > > Attachments: MNG-5761.zip > > > A detailed description of the issue is here: > http://stackoverflow.com/questions/28312975/maven-dependencymanagement-version-ignored-in-transitive-dependencies > The short of it is that maven appears to be using the wrong > version in a transitive dependency. There are two > relevant sections in the build, one pulled in by guice > and one pulled in by gwizard-parent. These are the dependency paths from the > top: > gwizard-example -> gwizard-config -> gwizard-parent > gwizard-example -> gwizard-config -> guice -> guice-parent > gwizard-parent's dependencyManagement specifies guava 18 > guice-parent's dependencyManagement specifies guava 16 > Guava 16 is winning. This seems highly undesirable, and in fact it breaks our > build. I would expect that in a version # fight, "closest to the top" should > win. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MNG-6079) 3.4 regression: cannot override version of a dependencyManagement in a submodule any more
[
https://issues.apache.org/jira/browse/MNG-6079?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Connolly updated MNG-6079:
--
Fix Version/s: (was: needing-scrub-3.4.0-fallout)
3.6.0-candidate
> 3.4 regression: cannot override version of a dependencyManagement in a
> submodule any more
> -
>
> Key: MNG-6079
> URL: https://issues.apache.org/jira/browse/MNG-6079
> Project: Maven
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: needing-scrub-3.4.0-fallout
>Reporter: Samuel Langlois
>Assignee: Christian Schulte
> Fix For: 3.6.0-candidate
>
> Attachments: parent-pom.xml, pom.xml
>
>
> When you import a {{}} section from another pom, you
> can use a property for the version:
> {code}
>
>
>
> org.apache.maven.surefire
> surefire
> ${surefire.version}
> pom
> import
>
>
>
> {code}
> In Maven 3.3 and before, that version could be overridden in submodules, by
> overriding the property.
> In Maven 3.4, this doesn't work any more: redefining the property doesn't
> change the dependencies which are defined.
> I attach a simple example that uses surefire dependencies.
> {{mvn dependency:list}} will yield different results:
> * surefire-api:jar:2.12 with Maven 3.3, because this is the overridden
> version in the pom
> * surefire-api:jar:2.10 with Maven 3.4 (as of snapshot 2016-08-06), which is
> the version defined in the parent pom
> It is admittedly a corner case, or potentially a bug fix. In Maven 3.4, the
> behaviour of is now more consistent with the one of
> , where you can't redefine a dependency version simply by
> overriding a property.
> It is however a change in behaviour -- which broke my build.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MNG-5600) Dependency management import should support exclusions.
[
https://issues.apache.org/jira/browse/MNG-5600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Connolly updated MNG-5600:
--
Fix Version/s: (was: needing-scrub-3.4.0-fallout)
3.6.0-candidate
> Dependency management import should support exclusions.
> ---
>
> Key: MNG-5600
> URL: https://issues.apache.org/jira/browse/MNG-5600
> Project: Maven
> Issue Type: Improvement
> Components: Dependencies
>Reporter: Radai Rosenblatt
>Assignee: Christian Schulte
> Fix For: 3.6.0-candidate
>
>
> suppose i have a multi-module project that uses spring, and so have this in
> dependency-managements in a parent pom:
> {code:xml}
>
> org.springframework
> spring-framework-bom
> ${org.springframework.version}
> pom
> import
>
> {code}
> spring artifacts (or at least a lot of them) have a dependency on
> commons-logging. right now, if i want to exclude commons-logging i have to
> add an exclusion to every spring dependency in every module of my project,
> which is actually more XML overall than giving up on using the bom dependency
> altogether and listing all spring dependencies with excludes once in the
> parent dependency management.
> I'd like to be able to do this:
> {code:xml}
>
> org.springframework
> spring-framework-bom
> ${org.springframework.version}
> pom
> import
>
>
> commons-logging
> commons-logging
>
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MNG-6049) Add behavior to filter resolved version ranges of an artifact
[
https://issues.apache.org/jira/browse/MNG-6049?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Connolly updated MNG-6049:
--
Fix Version/s: (was: needing-scrub-3.4.0-fallout)
3.6.0-candidate
> Add behavior to filter resolved version ranges of an artifact
> -
>
> Key: MNG-6049
> URL: https://issues.apache.org/jira/browse/MNG-6049
> Project: Maven
> Issue Type: Improvement
> Components: core, Dependencies
>Reporter: Uwe Barthel
>Assignee: Christian Schulte
>Priority: Critical
> Fix For: 3.6.0-candidate
>
>
> The discussion on issue MNG-3092 shows the seriously needs of different kinds
> of version range resolving in Maven.
> This solution provides a hook for Maven extensions/plugins to change the list
> of resolved version range results as required.
> The {{DefaultVersionRangeResolver}} will be extended with a filter for
> version range results. A new interface {{VersionRangeResultFilter}} is added
> and a non-filtering {{DefaultVersionRangeResultFilter}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MNG-5971) Imported dependencies should be available to inheritance processing
[
https://issues.apache.org/jira/browse/MNG-5971?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Connolly updated MNG-5971:
--
Fix Version/s: (was: needing-scrub-3.4.0-fallout)
3.6.0-candidate
> Imported dependencies should be available to inheritance processing
> ---
>
> Key: MNG-5971
> URL: https://issues.apache.org/jira/browse/MNG-5971
> Project: Maven
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 3.3.3
>Reporter: Stephane Nicoll
>Assignee: Christian Schulte
>Priority: Trivial
> Fix For: 3.6.0-candidate
>
> Attachments: bom-cloud.zip
>
>
> When a project extends from a parent with a {{dependencyManagement}} section,
> it is not always possible to properly override (and align) the version to use
> for a group of dependencies.
> We typically use Bill Of Materials to gather a group of modules and make sure
> their versions are consistent.
> The following project demonstrates the issue:
> https://github.com/snicoll-scratches/maven-dependency-management
> The first commit is a working use case where the parent uses a bom with
> version A and we use the same bom with version B in the child. Version B is
> used as expected.
> The second commit demonstrates the faulty scenario. Rather than using a bom
> in the parent, we use a direct dependency (provided by that bom). We still
> use the bom with a different version. In that case all the dependencies but
> the one provided by the parent are overridden (leading to mixed versions for
> the dependencies provided by the BOM).
> It looks like the distance is still used to compute the version while the
> graph of dependencies should be flatten at each step for a proper override.
> Thoughts? Thanks!
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MNG-5935) Optional true getting lost in managed dependencies when transitive
[ https://issues.apache.org/jira/browse/MNG-5935?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly updated MNG-5935: -- Fix Version/s: (was: needing-scrub-3.4.0-fallout) 3.6.0-candidate > Optional true getting lost in managed dependencies when transitive > -- > > Key: MNG-5935 > URL: https://issues.apache.org/jira/browse/MNG-5935 > Project: Maven > Issue Type: Bug > Components: Dependencies >Affects Versions: 3.3.9 > Environment: Apache Maven 3.3.9 > (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T17:41:47+01:00) > Maven home: C:\Temp\apache-maven-3.3.9 > Java version: 1.8.0_66, vendor: Oracle Corporation > Java home: C:\Prog\Java\v8_66\jre > Default locale: nl_NL, platform encoding: Cp1252 > OS name: "windows 7", version: "6.1", arch: "amd64", family: "dos" >Reporter: Marcel Schutte >Assignee: Christian Schulte > Fix For: 3.6.0-candidate > > Attachments: Parent.zip, buildoutput.txt > > > Run 'mvn package' on the project in the attached Parent.zip. Note that the > dependency Jar2 gets packaged in WEB-INF/lib and the other dependencies (Jar, > Jar1 and Jar3) do not. > I think the inclusion of Jar2 is incorrect, because project 'Web' declares > its dependency on 'Jar' to be optional and Jar2 being a transitive dependency > of Jar should inherit this. > If you look at the other Jarx dependencies, they have different combinations > of ways to become optional and have their versions managed. Only the case > when optionality is inherited and the dependency management for the version > is in another pom, yields incorrect results. > Please note that I believe the maven-war-plugin is not the cause of this > behavior. I have built and used a modified version of maven-war-plugin which > as the first thing in its WarMojo.execute() lists the result of > getProject().getArtifacts() including the value of each Artifact's > isOptional() method. Already at this point only Jar2 has optional false. > I am using maven-war-plugin in this bug report for the following reasons: > * maven-war-plugin uses the optional flag of dependencies in deciding whether > to package it or not, making this behavior visible > * I don't know of another way to visualize the value of the optional flag in > core maven (running with -X outputs the dependency tree in a section with > header 'Dependency collection stats', but this only shows the scope value) > * maven-dependency-plugin:resolve also only shows scope and not optionality > * obviously, maven-war-plugin is exactly what I intend to use and where I > found the bug -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MNG-6075) Increase the model validation level to the next minor level version.
[ https://issues.apache.org/jira/browse/MNG-6075?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly updated MNG-6075: -- Fix Version/s: (was: needing-scrub-3.4.0-fallout) 3.6.0-candidate > Increase the model validation level to the next minor level version. > > > Key: MNG-6075 > URL: https://issues.apache.org/jira/browse/MNG-6075 > Project: Maven > Issue Type: Task >Reporter: Christian Schulte >Assignee: Christian Schulte >Priority: Critical > Fix For: 3.6.0-candidate > > > Maven 3 has warned about various model related issues clearly stating that > not reacting to those warnings may break with a future Maven version. > Starting with Maven 3.4, the model validation level has been increased to the > next minor version so that such warnings will become errors as of 3.4. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MNG-5227) Make 'optional' flag of a dependency manageable.
[
https://issues.apache.org/jira/browse/MNG-5227?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Connolly updated MNG-5227:
--
Fix Version/s: (was: needing-scrub-3.4.0-fallout)
3.6.0-candidate
> Make 'optional' flag of a dependency manageable.
>
>
> Key: MNG-5227
> URL: https://issues.apache.org/jira/browse/MNG-5227
> Project: Maven
> Issue Type: New Feature
> Components: Artifacts and Repositories
>Affects Versions: 3.0.3
>Reporter: Christian Schulte
>Assignee: Christian Schulte
>Priority: Minor
> Fix For: 3.6.0-candidate
>
> Attachments: MNG-5227.patch, MNG-5227.patch
>
>
> {code}
>
>
>
> groupId
> artifactId
> version
> false
>
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MNG-5527) Dependency management import should support relocations.
[
https://issues.apache.org/jira/browse/MNG-5527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Connolly updated MNG-5527:
--
Fix Version/s: (was: needing-scrub-3.4.0-fallout)
3.6.0-candidate
> Dependency management import should support relocations.
>
>
> Key: MNG-5527
> URL: https://issues.apache.org/jira/browse/MNG-5527
> Project: Maven
> Issue Type: Bug
> Components: Dependencies
> Environment: maven-3.1.0
> Fedora 18 x86_64
>Reporter: Matous Jobanek
>Assignee: Christian Schulte
> Fix For: 3.6.0-candidate
>
>
> Consider the following scenario:
> {code:xml}
>
> 4.0.0
> old.groupId.bom
> my-artifactId-bom
> 1.0
> pom
>
>
> new.groupId.bom
> my-artifactId-bom
> 2.0
>
>
>
> {code}
> {code:xml}
>
> 4.0.0
> my.project.groupId
> my-project
> 1.0
> war
>
>
>
> old.groupId.bom
> my-artifactId-bom
> 1.0
> pom
> import
>
>
>
> ...
>
> {code}
> The expected result according to [1]:
> During building the "my-project" it should print the WARNING with the
> information about the relocation and it should be automatically redirected
> from old.groupId.bom:my-artifactId-bom:1.0 to
> new.groupId.bom:my-artifactId-bom:2.0 and use dependencies from the new pom.
> Actual results:
> There is no WARNING and no redirection to the new pom and maven is trying to
> obtain dependencies from the old pom (old.groupId.bom:my-artifactId-bom:1.0).
>
> Nevertheless, when the pom is declared as a "normal dependency" (not in the
> "dependencyManagement" part) it works without any problem - it prints the
> WARNING and redirects to the new pom, but this is not the case we are using.
> [1] http://maven.apache.org/guides/mini/guide-relocation.html
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MNG-6148) Can't package and assemble with JDK9/Jigsaw
[ https://issues.apache.org/jira/browse/MNG-6148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly updated MNG-6148: -- Fix Version/s: 3.5.1-candidate > Can't package and assemble with JDK9/Jigsaw > --- > > Key: MNG-6148 > URL: https://issues.apache.org/jira/browse/MNG-6148 > Project: Maven > Issue Type: Bug >Reporter: Robert Scholte >Priority: Minor > Fix For: 3.5.1-candidate > > > Rootcause is project verona: Here are the related plugins with their fixed > versions: > * maven-assembly-plugin:3.0.0 > * maven-jar-plugin:3.0.0 > * maven-javadoc-plugin:2.10.4 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MNG-5670) ConcurrentModificationException during DefaultMaven.newRepositorySession
[ https://issues.apache.org/jira/browse/MNG-5670?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly updated MNG-5670: -- Fix Version/s: 3.5.0-candidate > ConcurrentModificationException during DefaultMaven.newRepositorySession > > > Key: MNG-5670 > URL: https://issues.apache.org/jira/browse/MNG-5670 > Project: Maven > Issue Type: Bug > Components: Embedding >Reporter: Igor Fedorenko >Assignee: igorfie > Fix For: 3.2.3, 3.5.0-candidate > > > DefaultMaven.newRepositorySession will fail with > ConcurrentModificationException if System.properties is modified concurrently > by another thread. See https://bugs.eclipse.org/bugs/show_bug.cgi?id=439227 > for original bug report against m2e. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MNG-6078) Can't overwrite properties which have been defined in .mvn/maven.config
[
https://issues.apache.org/jira/browse/MNG-6078?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Connolly updated MNG-6078:
--
Fix Version/s: (was: needing-scrub-3.4.0-fallout)
3.5.0-candidate
> Can't overwrite properties which have been defined in .mvn/maven.config
> ---
>
> Key: MNG-6078
> URL: https://issues.apache.org/jira/browse/MNG-6078
> Project: Maven
> Issue Type: Improvement
> Components: Command Line
>Affects Versions: 3.3.9
>Reporter: Karl Heinz Marbaise
>Assignee: Karl Heinz Marbaise
> Fix For: 3.5.0-candidate
>
>
> Currently properties which have been defined in {{.mvn/maven.config}} can't
> be overwritten via command line. This should be made possible.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MNG-6109) PluginDescriptor doesn't read since value of parameter
[ https://issues.apache.org/jira/browse/MNG-6109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly updated MNG-6109: -- Fix Version/s: (was: needing-scrub-3.4.0-fallout) > PluginDescriptor doesn't read since value of parameter > -- > > Key: MNG-6109 > URL: https://issues.apache.org/jira/browse/MNG-6109 > Project: Maven > Issue Type: Bug > Components: Plugin API >Affects Versions: 3.3.9 >Reporter: Robert Scholte >Assignee: Robert Scholte > Fix For: 3.5.0-candidate > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MNG-6109) PluginDescriptor doesn't read since value of parameter
[ https://issues.apache.org/jira/browse/MNG-6109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly updated MNG-6109: -- Fix Version/s: 3.5.0-candidate > PluginDescriptor doesn't read since value of parameter > -- > > Key: MNG-6109 > URL: https://issues.apache.org/jira/browse/MNG-6109 > Project: Maven > Issue Type: Bug > Components: Plugin API >Affects Versions: 3.3.9 >Reporter: Robert Scholte >Assignee: Robert Scholte > Fix For: 3.5.0-candidate > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MNG-5951) add an option to avoid path addition to inherited URLs
[
https://issues.apache.org/jira/browse/MNG-5951?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Connolly updated MNG-5951:
--
Fix Version/s: (was: needing-scrub-3.4.0-fallout)
3.5.0-candidate
> add an option to avoid path addition to inherited URLs
> --
>
> Key: MNG-5951
> URL: https://issues.apache.org/jira/browse/MNG-5951
> Project: Maven
> Issue Type: Improvement
> Components: Inheritance and Interpolation
>Affects Versions: 3.0.5, 3.1.1, 3.2.5, 3.3.9
>Reporter: Jörg Sesterhenn
>Assignee: Hervé Boutemy
> Fix For: 3.5.0-candidate
>
> Attachments: MNG-5951.zip
>
>
> What I am trying to achieve is
> the definition of a project.url in a parent pom
> in a way that all children inherit a url ending with
> {code}
> ${project.groupId}/${project.artifactId}/${project.version}/
> {code}
> in order to be able to publish sites of all artifacts in all versions in
> parallel
> without having to redefine the url in every child pom.
> This is currently not working as expected in maven due to the default child
> urls calculation which leads to urls that add up parent urls like
> http://my.domain.de/sites/de.enterprise.calculatorsGroupId/calculator-artifactID/1.0.0-SNAPSHOT/internetAppParentPOM/calculatorParentPom/calculator-artifactID/
> The part *"internetAppParentPOM/calculatorParentPom/"* is added by automatic
> child url calculation (those are the artifactIds of all parent poms beneath
> our enterprise parent pom where the url is defined) and *is expexted to not
> be there at all*. The repeated artifactID at the end of the url is
> superfluous as well but tollerable.
> I expect maven-core to be changed so that I can turn on/off the automatic
> calculation of child URLs as an option which is by default on (current
> behaviour so nothing will change unless configured explicitly).
> See the discussion in MSITE-672.
> As this can not be done in the maven-site-plugin there needs to be a change
> in Maven itself (core), in Maven Model Builder, ie the way effective model is
> calculated, and more precisely in the inheritance step:
> http://maven.apache.org/ref/current/maven-model-builder/.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MNG-5297) Site should tell 'prerequisites.maven is deprecated'
[ https://issues.apache.org/jira/browse/MNG-5297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly updated MNG-5297: -- Fix Version/s: 3.5.0-candidate > Site should tell 'prerequisites.maven is deprecated' > > > Key: MNG-5297 > URL: https://issues.apache.org/jira/browse/MNG-5297 > Project: Maven > Issue Type: Bug > Components: Sites & Reporting >Affects Versions: 3.0.4 >Reporter: Kengo TODA >Assignee: Jason van Zyl >Priority: Minor > Fix For: 3.3.9, 3.5.0-candidate > > > MNG-4840 said 'enforcement of the build environment is left to the Maven > Enforcer Plugin'. > http://jira.codehaus.org/browse/MNG-4840?focusedCommentId=253900=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-253900 > But currently, there is no 'deprecated' mark at Maven site. > http://maven.apache.org/ref/3.0.4/maven-model/maven.html#prerequisites > I think site should has 'deprecated' mark like 'reports' element. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MNG-5878) add support for module name != artifactId in every calculated URLs (project, SCM, site): special project.directory property
[
https://issues.apache.org/jira/browse/MNG-5878?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Connolly updated MNG-5878:
--
Fix Version/s: (was: needing-scrub-3.4.0-fallout)
3.5.0-candidate
> add support for module name != artifactId in every calculated URLs (project,
> SCM, site): special project.directory property
> ---
>
> Key: MNG-5878
> URL: https://issues.apache.org/jira/browse/MNG-5878
> Project: Maven
> Issue Type: New Feature
> Components: Inheritance and Interpolation
>Affects Versions: 3.3.3
>Reporter: Michael Osipov
>Assignee: Hervé Boutemy
> Fix For: 3.5.0-candidate
>
>
> Say you have this project structure:
> {noformat}
> /
> |-- module1
> |-- module2
> {noformat}
> and artifactIds are named:
> {noformat}
> my-parent
> |-- my-module1
> |-- my-module2
> {noformat}
> Prefix {{my-}} is omitted for brevity in module names. For instance, Jersey
> does that.
> When the SCM report is built, the artifactId is always used for path
> composition which leads to incorrect URLs. You can of course set the
> parameter {{checkoutDirectoryName}} but this would be extremely tedious for
> all modules down the tree.
> The code should obtain the module name and use it for URL composition.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MNG-6059) Important use cases not covered, as child.inherit.append.path affects all children
[
https://issues.apache.org/jira/browse/MNG-6059?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Connolly updated MNG-6059:
--
Fix Version/s: (was: needing-scrub-3.4.0-fallout)
3.5.0-candidate
> Important use cases not covered, as child.inherit.append.path affects all
> children
> --
>
> Key: MNG-6059
> URL: https://issues.apache.org/jira/browse/MNG-6059
> Project: Maven
> Issue Type: Improvement
> Components: Inheritance and Interpolation
> Environment: Apache Maven 3.4.0-SNAPSHOT
> (227085283b6379038ec16f4cf9ad2e8869cef694; 2016-07-06T21:29:12+02:00)
>Reporter: Andreas Sewe
>Assignee: Hervé Boutemy
> Fix For: 3.5.0-candidate
>
>
> The {{child.inherit.append.path}} attribute introduced with MNG-5951
> unfortunately does not support the use case where the children of the element
> with the attribute should follow different inheritance rules. Take a typical
> configuration for Github, for example (taken from
> ):
> {noformat}
>
>
> scm:git:git://github.com/simpligility/ossrh-demo.git
>
> scm:git:ssh://github.com:simpligility/ossrh-demo.git
> http://github.com/simpligility/ossrh-demo/tree/master
>
> {noformat}
> If the {{ossrh-demo.git}} repository contains a child module called
> {{some-module}}, then that child’s {{scm/url}} should become
> {{http://github.com/simpligility/ossrh-demo/tree/master/some-module}} as per
> the normal inheritance rules, but both the {{scm/connection}} and
> {{scm/developerConnection}} URLs should remain unchanged.
> Unfortunately, this is not possible with {{*child*.inherit.append.path}},
> which acts on all children simultaneously.
> IMHO, this is a conceptual problem. In particular, setting
> {{child.inherit.append.path}} on the *root* element to just control a single
> child ({{project/url}}) feels wrong, as the attribute is in all likelihood
> not even located close to the {{}} element it controls.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MNG-6137) Clean up duplicate dependencies caused by incomplete Wagon HTTP Provider exclusions
[
https://issues.apache.org/jira/browse/MNG-6137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Connolly updated MNG-6137:
--
Fix Version/s: (was: needing-scrub-3.4.0-fallout)
3.5.0-candidate
> Clean up duplicate dependencies caused by incomplete Wagon HTTP Provider
> exclusions
> ---
>
> Key: MNG-6137
> URL: https://issues.apache.org/jira/browse/MNG-6137
> Project: Maven
> Issue Type: Task
> Components: Deployment
>Affects Versions: 3.3.9
>Reporter: Michael Osipov
>Assignee: Michael Osipov
> Fix For: 3.5.0-candidate
>
>
> Some dependencies are duplicated in {{maven.home/lib}} because not all shaded
> dependencies of Wagon HTTP Provider are excluded. This can easily be cleaned
> up when Wagon 2.11 is merged.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MNG-5457) Show repository id when downloading or uploading from/to a remote repository
[
https://issues.apache.org/jira/browse/MNG-5457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Connolly updated MNG-5457:
--
Fix Version/s: (was: needing-scrub-3.4.0-fallout)
3.5.0-candidate
> Show repository id when downloading or uploading from/to a remote repository
>
>
> Key: MNG-5457
> URL: https://issues.apache.org/jira/browse/MNG-5457
> Project: Maven
> Issue Type: Improvement
> Components: General
>Affects Versions: 3.0.5
>Reporter: Hervé Boutemy
>Assignee: Michael Osipov
> Fix For: 3.5.0-candidate
>
> Attachments: 2016-05-18_204749.png
>
>
> currently, the log only show the url being downloaded:
> {noformat}Downloading:
> http://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-plugins/23/maven-plugins-23.pom
> Downloaded:
> http://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-plugins/23/maven-plugins-23.pom
> (9 KB at 98.7 KB/sec){noformat}
> nothing is told about the repository id.
> But as shown in MNG-5181, repository id is an important information since it
> is stored in local repository to limit artifact scope: it would be useful
> IMHO to display the id in the output, like
> {noformat}Downloading from central:
> http://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-plugins/23/maven-plugins-23.pom
> Downloaded from central:
> http://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-plugins/23/maven-plugins-23.pom
> (9 KB at 98.7 KB/sec){noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MNG-6114) Elements from the global settings should be ordered before elements from the user settings.
[ https://issues.apache.org/jira/browse/MNG-6114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly updated MNG-6114: -- Fix Version/s: (was: needing-scrub-3.4.0-fallout) 3.5.0-candidate > Elements from the global settings should be ordered before elements from the > user settings. > --- > > Key: MNG-6114 > URL: https://issues.apache.org/jira/browse/MNG-6114 > Project: Maven > Issue Type: Bug >Reporter: Christian Schulte >Assignee: Christian Schulte > Fix For: 3.5.0-candidate > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MNG-6136) Upgrade Maven Wagon to 2.11
[ https://issues.apache.org/jira/browse/MNG-6136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly updated MNG-6136: -- Fix Version/s: (was: needing-scrub-3.4.0-fallout) 3.5.0-candidate > Upgrade Maven Wagon to 2.11 > --- > > Key: MNG-6136 > URL: https://issues.apache.org/jira/browse/MNG-6136 > Project: Maven > Issue Type: Task > Components: Deployment >Affects Versions: 3.3.9 >Reporter: Michael Osipov >Assignee: Michael Osipov > Fix For: 3.5.0-candidate > > > Let's absorb latest improvements to Wagon into Maven. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MNG-5567) Zip files are not included in classpaths at all
[
https://issues.apache.org/jira/browse/MNG-5567?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Connolly updated MNG-5567:
--
Fix Version/s: (was: needing-scrub-3.4.0-fallout)
3.5.0-candidate
> Zip files are not included in classpaths at all
> ---
>
> Key: MNG-5567
> URL: https://issues.apache.org/jira/browse/MNG-5567
> Project: Maven
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 3.3.9
>Reporter: Pablo La Greca
>Assignee: Michael Osipov
>Priority: Critical
> Fix For: 3.5.0-candidate
>
>
> when i added a dependency that was zip file
> eg
> {code:xml}
> hsqldb
> hsqldb
> 1.7.3.0
> provided
> zip
>
> {code}
> this file was not included in the test classpath and so the test would not
> pass
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MNG-6113) Rename the 'Central Repository' to 'Maven Central Repository' in the 4.0.0 super POM.
[ https://issues.apache.org/jira/browse/MNG-6113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly updated MNG-6113: -- Fix Version/s: (was: needing-scrub-3.4.0-fallout) 3.5.0-candidate > Rename the 'Central Repository' to 'Maven Central Repository' in the 4.0.0 > super POM. > - > > Key: MNG-6113 > URL: https://issues.apache.org/jira/browse/MNG-6113 > Project: Maven > Issue Type: Wish >Reporter: Christian Schulte >Assignee: Christian Schulte >Priority: Trivial > Fix For: 3.5.0-candidate > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MNG-6150) Javadoc improvements for 3.5.0
[ https://issues.apache.org/jira/browse/MNG-6150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly updated MNG-6150: -- Fix Version/s: 3.5.0-candidate > Javadoc improvements for 3.5.0 > -- > > Key: MNG-6150 > URL: https://issues.apache.org/jira/browse/MNG-6150 > Project: Maven > Issue Type: Improvement > Components: core >Reporter: Stephen Connolly >Priority: Trivial > Fix For: 3.5.0-candidate > > > Catch all for Javadoc improvements -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MNG-5359) Declared execution in PluginMgmt gets bound to lifecycle (regression)
[ https://issues.apache.org/jira/browse/MNG-5359?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly updated MNG-5359: -- Fix Version/s: (was: needing-scrub-3.4.0-fallout) 3.5.0-candidate > Declared execution in PluginMgmt gets bound to lifecycle (regression) > - > > Key: MNG-5359 > URL: https://issues.apache.org/jira/browse/MNG-5359 > Project: Maven > Issue Type: Bug > Components: Plugins and Lifecycle >Affects Versions: 3.0.1, 3.0.2, 3.0.3, 3.0.4 > Environment: Mac OS 10.7.5, Apple JDK 1.6.0_35 > (Same behavior seen on Windows XP with Sun JDK 1.6.0 as well) >Reporter: Anders Hammar >Assignee: Christian Schulte > Fix For: 3.5.0-candidate > > Attachments: MNG-5359-IT.patch, binding-test.zip > > > If a plugin execution binding is declared in pluginManagement it gets bound > to the build lifecycle in Maven 3.0.x, but not with Maven 2.2.1. > My understanding is that the behavior in Maven 3.0 is wrong; an execution > binding needs to be declared in build/plugins/plugin to be bound. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MNG-6074) Maven should produce an error if no model version has been set in a POM file used to build an effective model.
[
https://issues.apache.org/jira/browse/MNG-6074?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Connolly updated MNG-6074:
--
Fix Version/s: (was: needing-scrub-3.4.0-fallout)
3.5.0-candidate
> Maven should produce an error if no model version has been set in a POM file
> used to build an effective model.
> --
>
> Key: MNG-6074
> URL: https://issues.apache.org/jira/browse/MNG-6074
> Project: Maven
> Issue Type: Improvement
>Reporter: Christian Schulte
>Assignee: Christian Schulte
>Priority: Critical
> Fix For: 3.5.0-candidate
>
>
> Maven currently only validates the model version to equal {{4.0.0}} when set.
> The XML element is optional. Starting with Maven 3.4.0 a warning message
> should be printed whenever no model version has been set so that it becomes
> possible to use that version to decide about Maven behaviour. For example: In
> Maven 3.5 we could add support for a new model version {{4.1.0}} which may be
> used to decide about how Maven 3.5 should behave. Behaviour for model version
> {{4.0.0}} will be the same as in Maven 3.4. Behaviour for model version
> {{4.1.0}} could be different. For this the model version needs to be set.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MNG-6112) Central repository in the 4.0.0 super POM should declare update policy 'never'.
[ https://issues.apache.org/jira/browse/MNG-6112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly updated MNG-6112: -- Fix Version/s: (was: needing-scrub-3.4.0-fallout) 3.5.0-candidate > Central repository in the 4.0.0 super POM should declare update policy > 'never'. > --- > > Key: MNG-6112 > URL: https://issues.apache.org/jira/browse/MNG-6112 > Project: Maven > Issue Type: Bug >Reporter: Christian Schulte >Assignee: Christian Schulte > Fix For: 3.5.0-candidate > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MNG-5823) mvnDebug doesn't work with M2_HOME with spaces - missing quotes
[
https://issues.apache.org/jira/browse/MNG-5823?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Connolly updated MNG-5823:
--
Fix Version/s: (was: needing-scrub-3.4.0-fallout)
3.5.0-candidate
> mvnDebug doesn't work with M2_HOME with spaces - missing quotes
> ---
>
> Key: MNG-5823
> URL: https://issues.apache.org/jira/browse/MNG-5823
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.3.1
> Environment: Windows, Cygwin
>Reporter: Tobias Oberlies
>Assignee: Christian Schulte
> Fix For: 3.5.0-candidate
>
>
> When calling {{mvnDebug}} in a Cygwin shell, I get the following error
> {noformat}
> Preparing to Execute Maven in Debug Mode
> dirname: extra operand `Files/Maven/apache-maven-3.3.1/bin/mvnDebug'
> Try `dirname --help' for more information.
> env: /mvn: No such file or directory
> {noformat}
> The root cause are missing quotes in and around the dirname call. The script
> currently calls
> {noformat}
> env MAVEN_OPTS="$MAVEN_OPTS $MAVEN_DEBUG_OPTS" $(dirname $0)/mvn "$@"
> {noformat}
> but the call should be
> {noformat}
> env MAVEN_OPTS="$MAVEN_OPTS $MAVEN_DEBUG_OPTS" "$(dirname "$0")/mvn" "$@"
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MNG-5904) Remove the whole Ant Build
[ https://issues.apache.org/jira/browse/MNG-5904?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly updated MNG-5904: -- Fix Version/s: (was: needing-scrub-3.4.0-fallout) 3.5.0-candidate > Remove the whole Ant Build > -- > > Key: MNG-5904 > URL: https://issues.apache.org/jira/browse/MNG-5904 > Project: Maven > Issue Type: Improvement > Components: core >Affects Versions: needing-scrub-3.4.0-fallout >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Minor > Fix For: 3.5.0-candidate > > > We should remove the whole Ant build cause we have a large number of Maven > versions which could be used to start building Maven itself. > So i don't see any usefulness in it anymore. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MNG-5968) Default plugin version updates.
[ https://issues.apache.org/jira/browse/MNG-5968?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly updated MNG-5968: -- Fix Version/s: (was: needing-scrub-3.4.0-fallout) 3.5.0-candidate > Default plugin version updates. > --- > > Key: MNG-5968 > URL: https://issues.apache.org/jira/browse/MNG-5968 > Project: Maven > Issue Type: Improvement >Reporter: Christian Schulte >Assignee: Christian Schulte >Priority: Minor > Fix For: 3.5.0-candidate > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MNG-5837) Syntax error in bin/mvn on Solaris SPARC
[
https://issues.apache.org/jira/browse/MNG-5837?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Connolly updated MNG-5837:
--
Fix Version/s: (was: needing-scrub-3.4.0-fallout)
3.5.0-candidate
> Syntax error in bin/mvn on Solaris SPARC
>
>
> Key: MNG-5837
> URL: https://issues.apache.org/jira/browse/MNG-5837
> Project: Maven
> Issue Type: Bug
> Components: Command Line
>Affects Versions: 3.3.1
> Environment: Solaris 10
>Reporter: Erlend Birkedal
>Assignee: Christian Schulte
> Fix For: 3.5.0-candidate
>
>
> When running {{mvn}} on Solaris 10 we get the following error:
> {code:none}/opt/apache-maven-3.3.1/bin/mvn: syntax error at line 200: `('
> unexpected{code}
> Looks like similas issues as in MNG-5658
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MNG-5967) Dependency updates.
[ https://issues.apache.org/jira/browse/MNG-5967?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly updated MNG-5967: -- Fix Version/s: (was: needing-scrub-3.4.0-fallout) 3.5.0-candidate > Dependency updates. > --- > > Key: MNG-5967 > URL: https://issues.apache.org/jira/browse/MNG-5967 > Project: Maven > Issue Type: Dependency upgrade > Components: Dependencies >Reporter: Christian Schulte >Assignee: Christian Schulte >Priority: Trivial > Fix For: 3.5.0-candidate > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MNG-6149) MetadataResolutionResult#getGraph() never resolves request type 'test'
[
https://issues.apache.org/jira/browse/MNG-6149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Connolly updated MNG-6149:
--
Fix Version/s: (was: old-3.4.0-needing-scrub)
3.5.1
> MetadataResolutionResult#getGraph() never resolves request type 'test'
> --
>
> Key: MNG-6149
> URL: https://issues.apache.org/jira/browse/MNG-6149
> Project: Maven
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 3.3.9
>Reporter: Michael Osipov
>Assignee: Michael Osipov
> Fix For: 3.5.1
>
>
> Some copy-and-paste error resolves {{runtime}} scope twice, once to
> {{runtime}} and to {{test}}. It should be {{runtime}} => {{runtime}} and
> {{test}} => {{test}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MNG-6069) Migrate to non deprecated parts of Commons CLI
[
https://issues.apache.org/jira/browse/MNG-6069?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Connolly updated MNG-6069:
--
Fix Version/s: (was: 3.5.0)
old-3.4.0-needing-scrub
> Migrate to non deprecated parts of Commons CLI
> --
>
> Key: MNG-6069
> URL: https://issues.apache.org/jira/browse/MNG-6069
> Project: Maven
> Issue Type: Improvement
> Components: Embedding
>Affects Versions: 3.3.9
>Reporter: Karl Heinz Marbaise
>Priority: Minor
> Fix For: old-3.4.0-needing-scrub
>
>
> At the moment all parts of {{OptionBuilder...}} are marked deprecated in
> {{CLIManager}}. They should be migrated to:
> {code:java}
> Option.builder( HELP ).longOpt( "help" ).desc( "Display help information"
> ).build()
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MNG-6065) Creating opiton --fail-level / -fl which is error by default, but could be changed to warning/warn.
[
https://issues.apache.org/jira/browse/MNG-6065?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Connolly updated MNG-6065:
--
Fix Version/s: (was: 3.5.0)
old-3.4.0-needing-scrub
> Creating opiton --fail-level / -fl which is error by default, but could be
> changed to warning/warn.
>
>
> Key: MNG-6065
> URL: https://issues.apache.org/jira/browse/MNG-6065
> Project: Maven
> Issue Type: Improvement
>Affects Versions: 3.5.0
>Reporter: Robert Scholte
> Fix For: old-3.4.0-needing-scrub
>
>
> I've been thinking the option {{--fail-level}} / {{-fl}} which is {{error}}
> by default, but could be changed to {{warning}}/{{warn}}. We've had similar
> request and they make sense: one should be able to execute a build without
> any warnings.
> I did an attempt to hook into the Logger to but that seems very tricky. The
> other option is to have this level available in the API, so Maven core and
> plugins can verify it for themselves and decide to throw an Exception. It is
> a simple implementation, but now every component is responsible for checking
> it, not really my preferred solution.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MNG-6012) Missing profile is only notified at the end of a run
[ https://issues.apache.org/jira/browse/MNG-6012?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly updated MNG-6012: -- Fix Version/s: (was: 3.5.0) old-3.4.0-needing-scrub > Missing profile is only notified at the end of a run > > > Key: MNG-6012 > URL: https://issues.apache.org/jira/browse/MNG-6012 > Project: Maven > Issue Type: New Feature >Affects Versions: 3.3.9 >Reporter: Sebb > Fix For: old-3.4.0-needing-scrub > > > A missing profile is only notified at the end of a run. > Since this may mean that the run is useless, it would be helpful if: > 1) It was also noted near the start, so the user could cancel the run. > It's still helpful at the end, as it saves scrolling back to see if there was > a problem. > 2) There were an option to fail a run if a profile is not found. This option > should be settable in a POM and in settings.xml -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MNG-5988) Dependency mediation should prioritize transitive dependencies based on scope.
[
https://issues.apache.org/jira/browse/MNG-5988?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Connolly updated MNG-5988:
--
Fix Version/s: (was: 3.5.0)
old-3.4.0-needing-scrub
> Dependency mediation should prioritize transitive dependencies based on scope.
> --
>
> Key: MNG-5988
> URL: https://issues.apache.org/jira/browse/MNG-5988
> Project: Maven
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 3.2.3
>Reporter: Jostein Gogstad
>Assignee: Christian Schulte
>Priority: Critical
> Fix For: old-3.4.0-needing-scrub
>
> Attachments: Collected.svg, MNG-5988.zip, PRE.svg, Resolved.svg
>
>
> The
> [documentation|https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html]
> states that dependency mediation only supports "nearest definition",
> regardless of the scope of the parent dependency.
> If both compile- and test scoped dependencies shares the same transitive
> dependency, the test-scoped one will win if it has shallower depth. That in
> turn will lead to runtime exceptions since the transitive dependency is no
> longer on the classpath.
> Take the following pom from a typical [Spring
> Boot|http://projects.spring.io/spring-boot/] application. Since the
> {{camel-test-spring}} dependency also depends on spring, it wins and Spring
> is no longer available to the application at runtime.
> {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/maven-v4_0_0.xsd;>
> 4.0.0
> com.example
> bugreport
> jar
> 1.0.0-SNAPSHOT
>
>
> org.springframework.boot
> spring-boot-starter-web
> 1.3.2.RELEASE
>
>
> org.apache.camel
> camel-test-spring
> 2.16.2
> test
>
>
>
> {code}
> Now look for {{spring-beans}} or {{spring-context}} in the following
> dependency graphs:
> {code:xml|title=mvn dependency:tree (with camel-test-spring)}
> [INFO] --- maven-dependency-plugin:2.8:tree (default-cli) @ bugreport ---
> [INFO] com.example:bugreport:jar:1.0.0-SNAPSHOT
> [INFO] +-
> org.springframework.boot:spring-boot-starter-web:jar:1.3.2.RELEASE:compile
> [INFO] | +-
> org.springframework.boot:spring-boot-starter:jar:1.3.2.RELEASE:compile
> [INFO] | | +- org.springframework.boot:spring-boot:jar:1.3.2.RELEASE:compile
> [INFO] | | +-
> org.springframework.boot:spring-boot-autoconfigure:jar:1.3.2.RELEASE:compile
> [INFO] | | +-
> org.springframework.boot:spring-boot-starter-logging:jar:1.3.2.RELEASE:compile
> [INFO] | | | +- ch.qos.logback:logback-classic:jar:1.1.3:compile
> [INFO] | | | | \- ch.qos.logback:logback-core:jar:1.1.3:compile
> [INFO] | | | +- org.slf4j:jcl-over-slf4j:jar:1.7.13:compile
> [INFO] | | | +- org.slf4j:jul-to-slf4j:jar:1.7.13:compile
> [INFO] | | | \- org.slf4j:log4j-over-slf4j:jar:1.7.13:compile
> [INFO] | | \- org.yaml:snakeyaml:jar:1.16:runtime
> [INFO] | +-
> org.springframework.boot:spring-boot-starter-tomcat:jar:1.3.2.RELEASE:compile
> [INFO] | | +- org.apache.tomcat.embed:tomcat-embed-core:jar:8.0.30:compile
> [INFO] | | +- org.apache.tomcat.embed:tomcat-embed-el:jar:8.0.30:compile
> [INFO] | | +-
> org.apache.tomcat.embed:tomcat-embed-logging-juli:jar:8.0.30:compile
> [INFO] | | \-
> org.apache.tomcat.embed:tomcat-embed-websocket:jar:8.0.30:compile
> [INFO] | +-
> org.springframework.boot:spring-boot-starter-validation:jar:1.3.2.RELEASE:compile
> [INFO] | | \- org.hibernate:hibernate-validator:jar:5.2.2.Final:compile
> [INFO] | | +- javax.validation:validation-api:jar:1.1.0.Final:compile
> [INFO] | | +- org.jboss.logging:jboss-logging:jar:3.2.1.Final:compile
> [INFO] | | \- com.fasterxml:classmate:jar:1.1.0:compile
> [INFO] | +- com.fasterxml.jackson.core:jackson-databind:jar:2.6.5:compile
> [INFO] | | +-
> com.fasterxml.jackson.core:jackson-annotations:jar:2.6.0:compile
> [INFO] | | \- com.fasterxml.jackson.core:jackson-core:jar:2.6.5:compile
> [INFO] | +- org.springframework:spring-web:jar:4.2.4.RELEASE:compile
> [INFO] | \- org.springframework:spring-webmvc:jar:4.2.4.RELEASE:compile
> [INFO] \- org.apache.camel:camel-test-spring:jar:2.16.2:test
> [INFO]+- org.apache.camel:camel-test:jar:2.16.2:test
> [INFO]| +- org.apache.camel:camel-core:jar:2.16.2:test
> [INFO]| | \- org.slf4j:slf4j-api:jar:1.6.6:compile
> [INFO]| \- junit:junit:jar:4.11:test
> [INFO]| \- org.hamcrest:hamcrest-core:jar:1.3:test
> [INFO]+- org.apache.camel:camel-spring:jar:2.16.2:test
> [INFO]+-
[jira] [Updated] (MNG-5579) Unify error output/check logic from shell and batch scripts
[
https://issues.apache.org/jira/browse/MNG-5579?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Connolly updated MNG-5579:
--
Fix Version/s: (was: 3.5.0)
old-3.4.0-needing-scrub
> Unify error output/check logic from shell and batch scripts
> ---
>
> Key: MNG-5579
> URL: https://issues.apache.org/jira/browse/MNG-5579
> Project: Maven
> Issue Type: Improvement
> Components: Command Line
>Affects Versions: 3.1.1
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Minor
> Fix For: old-3.4.0-needing-scrub
>
>
> Currently,
> both output two different messages.
> Shell:
> {quote}
> Error: JAVA_HOME is not defined correctly.
>We cannot execute $JAVACMD
> {quote}
> while batch says:
> {quote}
> Error: JAVA_HOME not found in your environment.
> Please set the JAVA_HOME variable in your environment to match the
> location of your Java installation.
> {quote}
> Same applies for {{M2_HOME}}. Additionally, testing for the Java command is
> handled different in both scripts. The batch script relies on JAVA_HOME while
> the shell script can ignore it. Both should require {{JAVA_HOME}} or warn
> about and use {{which java}}, respectively {{java}} in {{PATH}} ({{for %%X
> in (java.exe) do (set JAVACMD=%%~$PATH:X)}}) on Windows. After that should
> proceed to checking {{M2_HOME}}.
> Any thoughts?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MNG-5404) Wrong resolution of dependency scope by Maven 3
[
https://issues.apache.org/jira/browse/MNG-5404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Connolly updated MNG-5404:
--
Fix Version/s: (was: 3.5.0)
3.4.0
> Wrong resolution of dependency scope by Maven 3
> ---
>
> Key: MNG-5404
> URL: https://issues.apache.org/jira/browse/MNG-5404
> Project: Maven
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 3.0.4
>Reporter: Dmitry Batrak
>Assignee: Jason van Zyl
> Fix For: 3.4.0
>
> Attachments: build.log, compile-as-transitive-of-provided.tgz,
> example.zip
>
>
> For the following POM:
> {noformat}
>
> 4.0.0
> test
> A
> 1.0
>
>
> org.apache.axis2
> axis2-xmlbeans
> 1.5
> provided
>
>
> org.apache.axis2
> axis2-codegen
> 1.5
>
>
> org.apache.geronimo.specs
> geronimo-stax-api_1.0_spec
>
>
>
>
>
> {noformat}
> running 'mvn dependency:resolve' using Maven 3.0.4 yields a wrong result.
> Namely, geronimo-stax-api_1.0_spec dependency is reported as having the
> resolved scope of 'compile'. With Maven 2.2.1 I get the 'provided' scope, as
> expected.
> Debug log is attached.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MNG-5197) locally declared test dependency's first-generation transitive dependency version incorrectly overrides (n > 1)th-generation compile-scoped dependency version
[ https://issues.apache.org/jira/browse/MNG-5197?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly updated MNG-5197: -- Fix Version/s: (was: 3.5.0) 3.4.0 > locally declared test dependency's first-generation transitive dependency > version incorrectly overrides (n > 1)th-generation compile-scoped dependency > version > -- > > Key: MNG-5197 > URL: https://issues.apache.org/jira/browse/MNG-5197 > Project: Maven > Issue Type: Bug > Components: Dependencies >Affects Versions: 2.2.1, 3.0.3 > Environment: OSX, Windows 7 >Reporter: Matt Benson >Assignee: Christian Schulte > Fix For: 3.4.0 > > Attachments: test-versions.tar.gz > > > This bug seems to relate to MNG-4457, MNG-4156, and potentially others, but I > have opened a new issue since nothing I found while searching could be > described in precisely the same way. > The test project I am attaching defines three modules: > thing1 > thing2 > thing3 > thing1 depends on hamcrest-core 1.2 > thing2 depends on thing1 and junit 4.10 > thing3 depends on thing2 and junit 4.10 > If you install these, you can then view the dependency trees for thing2 and > thing3 and see that thing1 correctly resolves v1.2 for hamcrest-core. > thing3, however, apparently overrides the version back to 1.1, apparently > accessed transitively via junit. > Thanks to Mark Struberg for his help in isolating this behavior! -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Reopened] (MNG-5197) locally declared test dependency's first-generation transitive dependency version incorrectly overrides (n > 1)th-generation compile-scoped dependency version
[ https://issues.apache.org/jira/browse/MNG-5197?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly reopened MNG-5197: --- Not targetted for 3.5.0 > locally declared test dependency's first-generation transitive dependency > version incorrectly overrides (n > 1)th-generation compile-scoped dependency > version > -- > > Key: MNG-5197 > URL: https://issues.apache.org/jira/browse/MNG-5197 > Project: Maven > Issue Type: Bug > Components: Dependencies >Affects Versions: 2.2.1, 3.0.3 > Environment: OSX, Windows 7 >Reporter: Matt Benson >Assignee: Christian Schulte > Fix For: 3.4.0 > > Attachments: test-versions.tar.gz > > > This bug seems to relate to MNG-4457, MNG-4156, and potentially others, but I > have opened a new issue since nothing I found while searching could be > described in precisely the same way. > The test project I am attaching defines three modules: > thing1 > thing2 > thing3 > thing1 depends on hamcrest-core 1.2 > thing2 depends on thing1 and junit 4.10 > thing3 depends on thing2 and junit 4.10 > If you install these, you can then view the dependency trees for thing2 and > thing3 and see that thing1 correctly resolves v1.2 for hamcrest-core. > thing3, however, apparently overrides the version back to 1.1, apparently > accessed transitively via junit. > Thanks to Mark Struberg for his help in isolating this behavior! -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MNG-6106) Remove maven.home default value setter from m2.conf
[
https://issues.apache.org/jira/browse/MNG-6106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Connolly updated MNG-6106:
--
Fix Version/s: (was: 3.4.0)
3.5.0
> Remove maven.home default value setter from m2.conf
> ---
>
> Key: MNG-6106
> URL: https://issues.apache.org/jira/browse/MNG-6106
> Project: Maven
> Issue Type: Bug
> Components: Bootstrap & Build, core
>Affects Versions: 3.3.9
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Minor
> Fix For: 3.5.0
>
>
> The {{set maven.home default ${user.home\}/m2}} seems to be a relic from
> ancient times: {{maven.home}} property is always defined by {{mvn}} launch
> script
> Even if it would be used, it wouldn't work because {{user.home}} never
> contains Maven's installation files. (?)
> This line can safely be removed.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MNG-6110) Upgrade Aether to Maven Resolver 1.2
[ https://issues.apache.org/jira/browse/MNG-6110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly updated MNG-6110: -- Fix Version/s: (was: 3.4.0) 3.5.0 > Upgrade Aether to Maven Resolver 1.2 > > > Key: MNG-6110 > URL: https://issues.apache.org/jira/browse/MNG-6110 > Project: Maven > Issue Type: Dependency upgrade > Components: Dependencies >Affects Versions: 3.3.9 >Reporter: Harald Wellmann >Assignee: Christian Schulte > Fix For: 3.5.0 > > > Replace Aether by Maven Resolver to make use of the latest bugfixes and > enhancements related to dependency collection. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MNG-6140) update documentation's dependency graph with resolver + resolver-provider + slf4j-provider
[ https://issues.apache.org/jira/browse/MNG-6140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly updated MNG-6140: -- Fix Version/s: (was: 3.4.0) 3.5.0 > update documentation's dependency graph with resolver + resolver-provider + > slf4j-provider > -- > > Key: MNG-6140 > URL: https://issues.apache.org/jira/browse/MNG-6140 > Project: Maven > Issue Type: Task > Components: Documentation: General >Reporter: Hervé Boutemy >Assignee: Hervé Boutemy > Fix For: 3.5.0 > > > http://maven.apache.org/ref/3-LATEST/ -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MNG-6102) Introduce ${maven.conf} in m2.conf
[
https://issues.apache.org/jira/browse/MNG-6102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Connolly updated MNG-6102:
--
Fix Version/s: (was: 3.4.0)
3.5.0
> Introduce ${maven.conf} in m2.conf
> --
>
> Key: MNG-6102
> URL: https://issues.apache.org/jira/browse/MNG-6102
> Project: Maven
> Issue Type: Improvement
> Components: Bootstrap & Build, core, Settings, Toolchains
>Affects Versions: 3.3.9
>Reporter: Michael Osipov
>Assignee: Michael Osipov
> Fix For: 3.5.0
>
>
> Package maintainers always try to fit a product into the file hierarchy
> given/mandated by the OS/distribution. They separate the application from the
> configuration to have one common place for every bit. Currently, Maven does
> not properly support his. {{conf/}} is tightly coupled with {{maven.home}}
> property and cannot be changed unless the Java code changes. Impossible for a
> maintainer to stick to
> [FHS|https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard] or
> [{{heir(7)}}|https://www.freebsd.org/cgi/man.cgi?query=hier=opensearch].
> By introducing a {{maven.conf}} property in {{m2.conf}}, a maintainer can
> easily move the configuration files to {{/usr/local/etc/maven3}}, decouple it
> from the installation.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MNG-6117) ${session.parallel} not correctly set
[
https://issues.apache.org/jira/browse/MNG-6117?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Connolly updated MNG-6117:
--
Fix Version/s: (was: 3.4.0)
3.5.0
> ${session.parallel} not correctly set
> -
>
> Key: MNG-6117
> URL: https://issues.apache.org/jira/browse/MNG-6117
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.3.9
>Reporter: Richard Raumberger
>Assignee: Guillaume Boué
> Fix For: 3.5.0
>
>
> Running {{mvn help:evaluate -T 3}} and resolving the property
> {{session.parallel}} returns {{true}} when run with Maven 3.0.5.
> When running it with 3.3.9, this property resolves to {{false}}.
> {code}
> mvn help:evaluate -T 3
> [INFO] Scanning for projects...
> [INFO]
> [INFO] Using the MultiThreadedBuilder implementation with a thread count of 3
> [INFO]
> [INFO]
>
> [INFO] Building Maven Stub Project (No POM) 1
> [INFO]
>
> [INFO]
> [INFO] --- maven-help-plugin:2.2:evaluate (default-cli) @ standalone-pom ---
> [INFO] No artifact parameter specified, using
> 'org.apache.maven:standalone-pom:pom:1' as project.
> [INFO] Enter the Maven expression i.e. ${project.groupId} or 0 to exit?:
> ${session.parallel}
> [INFO]
> false
> {code}
> E.g. Surefire
> [relies|https://github.com/apache/maven-surefire/blob/fb9b699e27dae905393a5bc4d5c6ae39606c3172/maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java#L658]
> on this property, to check whether Maven is running in parallel mode, as
> mentioned in the comments of
> [SUREFIRE-1301|https://issues.apache.org/jira/browse/SUREFIRE-1301].
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MNG-6138) Remove obsolete message_*.properties form maven-core
[
https://issues.apache.org/jira/browse/MNG-6138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Connolly updated MNG-6138:
--
Fix Version/s: (was: 3.4.0)
3.5.0
> Remove obsolete message_*.properties form maven-core
>
>
> Key: MNG-6138
> URL: https://issues.apache.org/jira/browse/MNG-6138
> Project: Maven
> Issue Type: Task
> Components: core
>Affects Versions: 3.3.9
>Reporter: Michael Osipov
>Assignee: Michael Osipov
> Fix For: 3.5.0
>
>
> The folowing files are not used in the entire project tree:
> {noformat}
> $ find . -name '*.properties'
> ./src/main/resources/org/apache/maven/messages/messages.properties
> ./src/main/resources/org/apache/maven/messages/messages_de.properties
> ./src/main/resources/org/apache/maven/messages/messages_el.properties
> ./src/main/resources/org/apache/maven/messages/messages_en.properties
> ./src/main/resources/org/apache/maven/messages/messages_es.properties
> ./src/main/resources/org/apache/maven/messages/messages_fr.properties
> ./src/main/resources/org/apache/maven/messages/messages_ja.properties
> ./src/main/resources/org/apache/maven/messages/messages_ko.properties
> ./src/main/resources/org/apache/maven/messages/messages_nl.properties
> ./src/main/resources/org/apache/maven/messages/messages_no.properties
> ./src/main/resources/org/apache/maven/messages/messages_pl.properties
> ./src/main/resources/org/apache/maven/messages/messages_zh_CN.properties
> {noformat}
> The have been added years ago, but never used. Since we do not strive for any
> i18n, they are safe to be removed.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MNG-6105) properties.internal.SystemProperties.addSystemProperties() is not really thread-safe
[
https://issues.apache.org/jira/browse/MNG-6105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Connolly updated MNG-6105:
--
Fix Version/s: (was: 3.4.0)
3.5.0
> properties.internal.SystemProperties.addSystemProperties() is not really
> thread-safe
>
>
> Key: MNG-6105
> URL: https://issues.apache.org/jira/browse/MNG-6105
> Project: Maven
> Issue Type: Bug
> Components: core
>Affects Versions: 3.3.9
> Environment: Apache Maven 3.3.9
> (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T17:41:47+01:00)
> Maven home: /usr/maven/default
> Java version: 1.8.0_102, vendor: Oracle Corporation
> Java home: /usr/java/jdk1.8.0_102/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "2.6.32-431.29.2.el6.x86_64", arch: "amd64",
> family: "unix"
>Reporter: Falko Modler
>Assignee: Guillaume Boué
> Fix For: 3.5.0
>
>
> We got a rather large Maven project with a couble of modules that execute
> {{maven-assembly-plugin}}. Our build runs in parallel mode via {{-Tx}}.
> From time to time we are seeing following exception causing the respective
> build to fail:
> {noformat}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-assembly-plugin:2.6:single (assembly-zip) on
> project some-module: Execution assembly-zip of goal
> org.apache.maven.plugins:maven-assembly-plugin:2.6:single failed.
> NullPointerException -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-assembly-plugin:2.6:single (assembly-zip)
> on project some-module: Execution assembly-zip of goal
> org.apache.maven.plugins:maven-assembly-plugin:2.6:single failed.
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:212)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
> at
> org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call(MultiThreadedBuilder.java:185)
> at
> org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call(MultiThreadedBuilder.java:181)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: org.apache.maven.plugin.PluginExecutionException: Execution
> assembly-zip of goal
> org.apache.maven.plugins:maven-assembly-plugin:2.6:single failed.
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:145)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:207)
> ... 11 more
> Caused by: java.lang.NullPointerException
> at java.util.Hashtable.put(Hashtable.java:459)
> at
> org.apache.maven.properties.internal.SystemProperties.addSystemProperties(SystemProperties.java:38)
> at
> org.apache.maven.project.artifact.MavenMetadataSource.getSystemProperties(MavenMetadataSource.java:756)
> at
> org.apache.maven.project.artifact.MavenMetadataSource.retrieveRelocatedProject(MavenMetadataSource.java:574)
> at
> org.apache.maven.project.artifact.MavenMetadataSource.retrieve(MavenMetadataSource.java:190)
> at
> org.apache.maven.repository.legacy.resolver.DefaultLegacyArtifactCollector.recurse(DefaultLegacyArtifactCollector.java:532)
> at
> org.apache.maven.repository.legacy.resolver.DefaultLegacyArtifactCollector.recurse(DefaultLegacyArtifactCollector.java:584)
> at
> org.apache.maven.repository.legacy.resolver.DefaultLegacyArtifactCollector.collect(DefaultLegacyArtifactCollector.java:144)
> at
> org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:493)
> at
> org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveWithExceptions(DefaultArtifactResolver.java:348)
> at
> org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:342)
> at
> org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:321)
> at
>
[jira] [Updated] (MNG-6088) after forked execution success, add an empty line
[ https://issues.apache.org/jira/browse/MNG-6088?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly updated MNG-6088: -- Fix Version/s: (was: 3.4.0) 3.5.0 > after forked execution success, add an empty line > - > > Key: MNG-6088 > URL: https://issues.apache.org/jira/browse/MNG-6088 > Project: Maven > Issue Type: Wish > Components: Embedding >Affects Versions: 3.3.9 >Reporter: Hervé Boutemy >Assignee: Hervé Boutemy > Fix For: 3.5.0 > > > while working on MSHARED-589 to improve maven-site-plugin output when forking > executions for reports preparation, I found that since start of forked > execution adds a newline before starting, end of the execution should add an > empty line also for better rendering > such newline can easily be added in maven-reporting-exec, but it seems more > logical to add it in Maven core instead -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MNG-6081) Log refactoring - Method Invocation Replaced By Variable
[
https://issues.apache.org/jira/browse/MNG-6081?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Connolly updated MNG-6081:
--
Fix Version/s: (was: 3.4.0)
3.5.0
> Log refactoring - Method Invocation Replaced By Variable
>
>
> Key: MNG-6081
> URL: https://issues.apache.org/jira/browse/MNG-6081
> Project: Maven
> Issue Type: Improvement
> Components: core
>Affects Versions: 3.3.9
>Reporter: Nemo Chen
>Assignee: Michael Osipov
>Priority: Minor
> Fix For: 3.5.0
>
> Attachments: MNG-6081.patch
>
>
> *Method Invocation Replaced By Variable*
> In file:
> apache-maven-3.3.9/maven-compat/src/main/java/org/apache/maven/artifact/resolver/DebugResolutionListener.java
> from line 70:
> {code}
> String keptVersion = kept.getVersion();
> if ( omittedVersion != null ? !omittedVersion.equals( keptVersion ) :
> keptVersion != null )
> {
> logger.debug( indent + omitted + " (removed - nearer found: " +
> kept.getVersion() + ")" );
> }
> {code}
> the "kept.getVersion()" can be replaced with "keptVersion" for the sake of
> simplicity and readability.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MNG-6029) Duplicate conditional and body in MetadataResolutionResult.java
[ https://issues.apache.org/jira/browse/MNG-6029?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly updated MNG-6029: -- Fix Version/s: (was: 3.4.0) 3.5.0 > Duplicate conditional and body in MetadataResolutionResult.java > --- > > Key: MNG-6029 > URL: https://issues.apache.org/jira/browse/MNG-6029 > Project: Maven > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 3.3.9 >Reporter: Michael Osipov >Assignee: Michael Osipov > Fix For: 3.5.0 > > > See PR: https://github.com/apache/maven/pull/79 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MNG-6092) warn if prerequisites.maven is used for non-plugin projects
[ https://issues.apache.org/jira/browse/MNG-6092?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly updated MNG-6092: -- Fix Version/s: (was: 3.4.0) 3.5.0 > warn if prerequisites.maven is used for non-plugin projects > --- > > Key: MNG-6092 > URL: https://issues.apache.org/jira/browse/MNG-6092 > Project: Maven > Issue Type: Wish > Components: core >Affects Versions: 3.3.9 >Reporter: Hervé Boutemy >Assignee: Karl Heinz Marbaise > Fix For: 3.5.0 > > > as seen in MNG'4840 and documented in MNG-5297, in Maven 3, > prerequisites.maven has a meaning for plugin projects: defining this for > non-plugins projects makes feel that it will be checked like it was done in > Maven 2, but this is not the case. > Adding a warning could help people avoid this habit taken with Maven 2 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MNG-6053) Unsafe System Properties copy in MavenRepositorySystemUtils, causing NPEs
[
https://issues.apache.org/jira/browse/MNG-6053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Connolly updated MNG-6053:
--
Fix Version/s: (was: 3.4.0)
3.5.0
> Unsafe System Properties copy in MavenRepositorySystemUtils, causing NPEs
> -
>
> Key: MNG-6053
> URL: https://issues.apache.org/jira/browse/MNG-6053
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.3.9
> Environment: Eclipse m2e 1.7
>Reporter: Fred Bricon
>Assignee: Christian Schulte
> Fix For: 3.5.0
>
>
> This bug has been reported in m2e
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=493871:
> {quote}
> I'm occasionally, not 100% reliably reproducible, but regularly enough (like
> it occurs every now and then, not just once) seeing the error below, in the
> Error Log of Eclipse during workspace rebuilds. This is with M2E 1.7.0. --
> I'm not sure if this is just "annoying" or actually prevents M2E from
> correctly configuring projects (?). Either way, perhaps it would be possible
> to "harden" respective code to prevent this?
> java.lang.NullPointerException
> at java.util.Hashtable.put(Hashtable.java:459)
> at
> org.apache.maven.repository.internal.MavenRepositorySystemUtils.newSession(MavenRepositorySystemUtils.java:133)
> at
> org.apache.maven.internal.aether.DefaultRepositorySystemSessionFactory.newRepositorySession(DefaultRepositorySystemSessionFactory.java:98)
> at
> org.apache.maven.DefaultMaven.newRepositorySession(DefaultMaven.java:352)
> at
> org.eclipse.m2e.core.internal.embedder.MavenImpl.createRepositorySession(MavenImpl.java:309)
> {quote}
> Looking at
> https://github.com/apache/maven/blob/86b656167923923e2e416def4a48303b4e6248fa/maven-aether-provider/src/main/java/org/apache/maven/repository/internal/MavenRepositorySystemUtils.java#L132,
> it seems some system property is null (maybe due to some concurrency issue),
> and given that Hashtable doesn't support null values, then it throws an NPE
> on the put() call
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MNG-6003) Drastically reduce JAVA_HOME discovery code
[
https://issues.apache.org/jira/browse/MNG-6003?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Connolly updated MNG-6003:
--
Fix Version/s: (was: 3.4.0)
3.5.0
> Drastically reduce JAVA_HOME discovery code
> ---
>
> Key: MNG-6003
> URL: https://issues.apache.org/jira/browse/MNG-6003
> Project: Maven
> Issue Type: Improvement
> Components: Command Line
>Affects Versions: 3.3.9
>Reporter: Michael Osipov
>Assignee: Michael Osipov
> Fix For: 3.5.0
>
>
> Our [installation documentation|https://maven.apache.org/install.html]
> several times requires that {{JAVA_HOME}} is set and points to a valid JDK.
> Though, tens of lines in {{mvn}} and {{mvn.cmd}} perform some magic to
> discover it when it is not set. This completely contradicts our requirement
> that {{JAVA_HOME}} must be set.
> We can drastically reduce this code by checking if {{JAVA_HOME}} is set and
> use it, if not perform {{which java}} and use that to run Maven. Not adhering
> to our requirements is deemed to undefined behavior. A developer must be able
> to set this simple env var properly. In most cases on Unix/Linux OpenJDK is
> installed anyway which means that {{which java}} points to a JDK anyway. For
> instance, the {{JAVA_HOME}} discovery on FreeBSD competely fails and sets it
> to {{/usr/local}} because {{/usr/local/bin/java}} is actually a wrapper
> script.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MNG-5579) Unify error output/check logic from shell and batch scripts
[
https://issues.apache.org/jira/browse/MNG-5579?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Connolly updated MNG-5579:
--
Fix Version/s: (was: 3.4.0)
3.5.0
> Unify error output/check logic from shell and batch scripts
> ---
>
> Key: MNG-5579
> URL: https://issues.apache.org/jira/browse/MNG-5579
> Project: Maven
> Issue Type: Improvement
> Components: Command Line
>Affects Versions: 3.1.1
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Minor
> Fix For: 3.5.0
>
>
> Currently,
> both output two different messages.
> Shell:
> {quote}
> Error: JAVA_HOME is not defined correctly.
>We cannot execute $JAVACMD
> {quote}
> while batch says:
> {quote}
> Error: JAVA_HOME not found in your environment.
> Please set the JAVA_HOME variable in your environment to match the
> location of your Java installation.
> {quote}
> Same applies for {{M2_HOME}}. Additionally, testing for the Java command is
> handled different in both scripts. The batch script relies on JAVA_HOME while
> the shell script can ignore it. Both should require {{JAVA_HOME}} or warn
> about and use {{which java}}, respectively {{java}} in {{PATH}} ({{for %%X
> in (java.exe) do (set JAVACMD=%%~$PATH:X)}}) on Windows. After that should
> proceed to checking {{M2_HOME}}.
> Any thoughts?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MNG-6001) Replace %HOME% with %USERPROFILE% in mvn.cmd
[
https://issues.apache.org/jira/browse/MNG-6001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Connolly updated MNG-6001:
--
Fix Version/s: (was: 3.4.0)
3.5.0
> Replace %HOME% with %USERPROFILE% in mvn.cmd
>
>
> Key: MNG-6001
> URL: https://issues.apache.org/jira/browse/MNG-6001
> Project: Maven
> Issue Type: Improvement
> Components: Command Line
>Affects Versions: 3.3.9
>Reporter: Michael Osipov
>Assignee: Michael Osipov
> Fix For: 3.5.0
>
>
> Setting {{HOME=%HOMEDRIVE%%HOMEPATH%}} is a relic from Windows NT times. The
> preferred way is to use {{%USERPROFILE%}} which is already done in Java 8
> internally.
> Let's use it to load the {{mavenrc}} scripts.
> Some references:
> * http://stackoverflow.com/a/36392591/696632
> * http://stackoverflow.com/a/21599376/696632
> * http://bugs.java.com/view_bug.do?bug_id=4787931
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MNG-5977) Improve output readability of our MavenTransferListener implementations
[
https://issues.apache.org/jira/browse/MNG-5977?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Connolly updated MNG-5977:
--
Fix Version/s: (was: 3.4.0)
3.5.0
> Improve output readability of our MavenTransferListener implementations
> ---
>
> Key: MNG-5977
> URL: https://issues.apache.org/jira/browse/MNG-5977
> Project: Maven
> Issue Type: Improvement
> Components: Command Line, Embedding
>Affects Versions: 3.3.9
>Reporter: Michael Osipov
>Assignee: Michael Osipov
> Fix For: 3.5.0
>
> Attachments: current.zip, improved-debug.zip, improved.zip
>
>
> The current output of Downloading/Downladed/Uploading/Uploaded transfer
> notification has some flaws:
> 1. It does not scale numbers between 1 and 1000 with appropriate units
> 2. It should use correct size ({{kB}}, {{MB}}, {{GB}} and time units ({{s}})
> but doesn't. (see https://en.wikipedia.org/wiki/Binary_prefix and
> https://en.wikipedia.org/wiki/Metric_prefix)
> 3. When Aether downloads in parallel (which applies for non-POM files) the
> progress interleaves due to race conditions to {{System.out}} and you do not
> know to which resource a progress belongs to.
> Let's use an improved version of MPIR {{DependenciesRenderer}}'s
> [{{FileDecimalFormat}}|https://github.com/apache/maven-plugins/blob/trunk/maven-project-info-reports-plugin/src/main/java/org/apache/maven/report/projectinfo/dependencies/renderer/DependenciesRenderer.java#L1583]
> for it.
> concrete examples:
> before
> {noformat}191/191 KB 27/48 KB 48/119 KB 80/87 KB 13/13 KB {noformat}
> after:
> {noformat}Progress (4): 500/800 B | 40/45 kB | 193 kB/315 kB | 1.3/9.0 MB |
> 12/30 MB{noformat}
> if total size is unavailable or the file has already been downloaded but not
> removed from the list, the output will be:
> {noformat}Progress (4): 800 B | 40/45 kB | 193 kB | 9.0 MB | 12 MB{noformat}
> or in debug mode:
> {noformat}Progress (5): xml-apis-1.3.04.jar () |
> maven-shared-utils-0.6.jar () | xercesImpl-2.9.1.jar () |
> commons-digester-1.6.jar () | maven-reporting-impl-2.3.jar
> (){noformat}
> If the scale is between 1 and 10, one decimal place will be printed out. If
> it is between 10 and 1000+, it will be an integer.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MNG-5975) Use Java 7's SimpleDateFormat in CLIReportingUtils#formatTimestamp
[ https://issues.apache.org/jira/browse/MNG-5975?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly updated MNG-5975: -- Fix Version/s: (was: 3.4.0) 3.5.0 > Use Java 7's SimpleDateFormat in CLIReportingUtils#formatTimestamp > -- > > Key: MNG-5975 > URL: https://issues.apache.org/jira/browse/MNG-5975 > Project: Maven > Issue Type: Improvement > Components: Embedding >Affects Versions: 3.3.9 >Reporter: Michael Osipov >Assignee: Michael Osipov > Fix For: 3.5.0 > > > The current code manually formats the timestamp because Commons Lang 3 was > not in the dependencies list. Now there is, drop custom code and use builtin > features. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MNG-5954) Remove outdated maven-embedder/src/main/resources/META-INF/MANIFEST.MF
[ https://issues.apache.org/jira/browse/MNG-5954?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly updated MNG-5954: -- Fix Version/s: (was: 3.4.0) 3.5.0 > Remove outdated maven-embedder/src/main/resources/META-INF/MANIFEST.MF > -- > > Key: MNG-5954 > URL: https://issues.apache.org/jira/browse/MNG-5954 > Project: Maven > Issue Type: Task > Components: Embedding >Affects Versions: 3.3.9 >Reporter: Michael Osipov >Assignee: Michael Osipov > Fix For: 3.5.0 > > > File is outdated and not used anymore. Remove it. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MNG-5962) mvn fails when the current directory has spaces in between
[
https://issues.apache.org/jira/browse/MNG-5962?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Connolly updated MNG-5962:
--
Fix Version/s: (was: 3.4.0)
3.5.0
> mvn fails when the current directory has spaces in between
> --
>
> Key: MNG-5962
> URL: https://issues.apache.org/jira/browse/MNG-5962
> Project: Maven
> Issue Type: Bug
> Components: Command Line
>Affects Versions: 3.3.3, 3.3.9
> Environment: Windows 7
>Reporter: Miriam Lee
>Assignee: Christian Schulte
>Priority: Minor
> Labels: easyfix, newbie
> Fix For: 3.5.0
>
> Attachments: MNG-5962-apache-maven.patch
>
> Original Estimate: 2h
> Remaining Estimate: 2h
>
> Executing {{mvn.cmd}} when the current directory has spaces in between
> outputs {{The system cannot find the path specified.}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MNG-5958) java.lang.String cannot be cast to org.apache.maven.lifecycle.mapping.LifecyclePhase
[
https://issues.apache.org/jira/browse/MNG-5958?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Connolly updated MNG-5958:
--
Fix Version/s: (was: 3.4.0)
3.5.0
> java.lang.String cannot be cast to
> org.apache.maven.lifecycle.mapping.LifecyclePhase
>
>
> Key: MNG-5958
> URL: https://issues.apache.org/jira/browse/MNG-5958
> Project: Maven
> Issue Type: Bug
> Components: Plugins and Lifecycle
>Affects Versions: 3.3.9
> Environment: win 8.1
>Reporter: Meytal Genah
>Assignee: Christian Schulte
>Priority: Minor
> Fix For: 3.5.0
>
>
> Our app uses flex mojo.
> We upgraded from Maven 3.3.3 to Maven 3.3.9 and when building we get:
> {noformat}[ERROR] Internal error: java.lang.ClassCastException:
> java.lang.String cannot be cast to
> org.apache.maven.lifecycle.mapping.LifecyclePhase -> [Help 1]
> org.apache.maven.InternalErrorException: Internal error:
> java.lang.ClassCastException: java.lang.String cannot be cast to
> org.apache.maven.lifecycle.mapping.LifecyclePhas
> e
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:121)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:863)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:288)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:199)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
> Caused by: java.lang.ClassCastException: java.lang.String cannot be cast to
> org.apache.maven.lifecycle.mapping.LifecyclePhase
> at
> org.apache.maven.lifecycle.internal.DefaultLifecyclePluginAnalyzer.getPluginsBoundByDefaultToAllLifecycles(DefaultLifecyclePluginAnalyzer.java:119)
> at
> org.apache.maven.model.plugin.DefaultLifecycleBindingsInjector.injectLifecycleBindings(DefaultLifecycleBindingsInjector.java:64)
> at
> org.apache.maven.model.building.DefaultModelBuilder.build(DefaultModelBuilder.java:451)
> at
> org.apache.maven.model.building.DefaultModelBuilder.build(DefaultModelBuilder.java:421)
> at
> org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:620)
> at
> org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:626)
> at
> org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:626)
> at
> org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:626)
> at
> org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:626)
> at
> org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:411)
> at
> org.apache.maven.graph.DefaultGraphBuilder.collectProjects(DefaultGraphBuilder.java:419)
> at
> org.apache.maven.graph.DefaultGraphBuilder.getProjectsForMavenReactor(DefaultGraphBuilder.java:410)
> at
> org.apache.maven.graph.DefaultGraphBuilder.build(DefaultGraphBuilder.java:83)
> at org.apache.maven.DefaultMaven.buildGraph(DefaultMaven.java:491)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:219)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:193)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:106)
> ... 11 more{noformat}
> I didn’t see anyone encountering the same problem. Maybe it is related to the
> fix of https://issues.apache.org/jira/browse/MNG-5805.
> Also, according to the stack trace, the invalid casting is in this line:
> {code:java}LifecyclePhase goals =
> goalsForLifecyclePhase.getValue();{code}
> this is the content of the pom.xml:
> {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/maven-v4_0_0.xsd;>
> 4.0.0
>
>com.myapp.plugin
> GUI
> trunk
>
> myapp-war
> 1.0
> war
> Plugin GUI WAR
>
> myapp-ui
>
>
