[jira] [Closed] (MNG-6489) Upgrade Maven Resolver to 1.3.0
[ https://issues.apache.org/jira/browse/MNG-6489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MNG-6489. --- Resolution: Fixed Fixed with [0345cd13142a8e4b859040ab0559ef4752fc6b67|https://gitbox.apache.org/repos/asf?p=maven.git;a=commit;h=0345cd13142a8e4b859040ab0559ef4752fc6b67]. > Upgrade Maven Resolver to 1.3.0 > --- > > Key: MNG-6489 > URL: https://issues.apache.org/jira/browse/MNG-6489 > Project: Maven > Issue Type: Dependency upgrade > Components: Artifacts and Repositories, Dependencies >Affects Versions: 3.5.4 >Reporter: Michael Osipov >Assignee: Michael Osipov >Priority: Major > Fix For: 3.6.0 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] slachiewicz commented on issue #153: [MNG-6069] Migrate to non deprecated parts of Commons CLI
slachiewicz commented on issue #153: [MNG-6069] Migrate to non deprecated parts of Commons CLI URL: https://github.com/apache/maven/pull/153#issuecomment-428441685 I found one typo in the code and now the tests are green. @khmarbaise can you check this for 3.6? This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Commented] (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:comment-tabpanel&focusedCommentId=16644472#comment-16644472
]
ASF GitHub Bot commented on MNG-6069:
-
slachiewicz commented on issue #153: [MNG-6069] Migrate to non deprecated parts
of Commons CLI
URL: https://github.com/apache/maven/pull/153#issuecomment-428441685
I found one typo in the code and now the tests are green.
@khmarbaise can you check this for 3.6?
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> 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, 3.5.0-alpha-1, 3.5.0-beta-1, 3.5.0
>Reporter: Karl Heinz Marbaise
>Assignee: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 3.6.x-candidate
>
>
> 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
(v7.6.3#76005)
[jira] [Commented] (MPLUGIN-337) Try to derive JDK requirements also from release parameter
[
https://issues.apache.org/jira/browse/MPLUGIN-337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16644451#comment-16644451
]
Hudson commented on MPLUGIN-337:
Build unstable in Jenkins: Maven TLP » maven-plugin-tools » master #49
See
https://builds.apache.org/job/maven-box/job/maven-plugin-tools/job/master/49/
> Try to derive JDK requirements also from release parameter
> --
>
> Key: MPLUGIN-337
> URL: https://issues.apache.org/jira/browse/MPLUGIN-337
> Project: Maven Plugin Tools
> Issue Type: Bug
> Components: Plugin Plugin
>Affects Versions: 3.5.1
>Reporter: Konrad Windszus
>Assignee: Olivier Lamy (*$^¨%`£)
>Priority: Major
> Fix For: 3.6.0
>
>
> Currently the JDK requirements are extracted
> (https://github.com/apache/maven-plugin-tools/blob/1087f55e8cdfd8c1fec605a7cb9004efaee4e592/maven-plugin-plugin/src/main/java/org/apache/maven/plugin/plugin/PluginReport.java#L759)
> from either
> # the explicitly set requirement (via plugin configuration parameter)
> # or by evaluating the maven-compiler-plugin's {{target}} parameter
> With Java 9 it is pretty common to use {{release}} instead
> (https://maven.apache.org/plugins/maven-compiler-plugin/compile-mojo.html#release).
> Therefore this parameter should be evaluated as well.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (MPLUGIN-253) requiresDependencyResolution not inherited
[
https://issues.apache.org/jira/browse/MPLUGIN-253?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Olivier Lamy (*$^¨%`£) closed MPLUGIN-253.
--
Resolution: Won't Fix
Assignee: Olivier Lamy (*$^¨%`£)
nothing is inherited by design.
old issue not sure we really need it
> requiresDependencyResolution not inherited
> --
>
> Key: MPLUGIN-253
> URL: https://issues.apache.org/jira/browse/MPLUGIN-253
> Project: Maven Plugin Tools
> Issue Type: Bug
>Affects Versions: 3.2
>Reporter: Robert Scholte
>Assignee: Olivier Lamy (*$^¨%`£)
>Priority: Major
>
> See MSITE-665. When using doclet tags the {{requiresDependencyResolution}}
> was inherited from {{SiteMojo}}, but with the annotations you have to set it
> explicitly.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (MPLUGIN-337) Try to derive JDK requirements also from release parameter
[
https://issues.apache.org/jira/browse/MPLUGIN-337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Olivier Lamy (*$^¨%`£) closed MPLUGIN-337.
--
> Try to derive JDK requirements also from release parameter
> --
>
> Key: MPLUGIN-337
> URL: https://issues.apache.org/jira/browse/MPLUGIN-337
> Project: Maven Plugin Tools
> Issue Type: Bug
> Components: Plugin Plugin
>Affects Versions: 3.5.1
>Reporter: Konrad Windszus
>Assignee: Olivier Lamy (*$^¨%`£)
>Priority: Major
> Fix For: 3.6.0
>
>
> Currently the JDK requirements are extracted
> (https://github.com/apache/maven-plugin-tools/blob/1087f55e8cdfd8c1fec605a7cb9004efaee4e592/maven-plugin-plugin/src/main/java/org/apache/maven/plugin/plugin/PluginReport.java#L759)
> from either
> # the explicitly set requirement (via plugin configuration parameter)
> # or by evaluating the maven-compiler-plugin's {{target}} parameter
> With Java 9 it is pretty common to use {{release}} instead
> (https://maven.apache.org/plugins/maven-compiler-plugin/compile-mojo.html#release).
> Therefore this parameter should be evaluated as well.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (MPLUGIN-337) Try to derive JDK requirements also from release parameter
[
https://issues.apache.org/jira/browse/MPLUGIN-337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Olivier Lamy (*$^¨%`£) resolved MPLUGIN-337.
Resolution: Fixed
> Try to derive JDK requirements also from release parameter
> --
>
> Key: MPLUGIN-337
> URL: https://issues.apache.org/jira/browse/MPLUGIN-337
> Project: Maven Plugin Tools
> Issue Type: Bug
> Components: Plugin Plugin
>Affects Versions: 3.5.1
>Reporter: Konrad Windszus
>Assignee: Olivier Lamy (*$^¨%`£)
>Priority: Major
> Fix For: 3.6.0
>
>
> Currently the JDK requirements are extracted
> (https://github.com/apache/maven-plugin-tools/blob/1087f55e8cdfd8c1fec605a7cb9004efaee4e592/maven-plugin-plugin/src/main/java/org/apache/maven/plugin/plugin/PluginReport.java#L759)
> from either
> # the explicitly set requirement (via plugin configuration parameter)
> # or by evaluating the maven-compiler-plugin's {{target}} parameter
> With Java 9 it is pretty common to use {{release}} instead
> (https://maven.apache.org/plugins/maven-compiler-plugin/compile-mojo.html#release).
> Therefore this parameter should be evaluated as well.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (MPLUGIN-337) Try to derive JDK requirements also from release parameter
[
https://issues.apache.org/jira/browse/MPLUGIN-337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Olivier Lamy (*$^¨%`£) reassigned MPLUGIN-337:
--
Assignee: Olivier Lamy (*$^¨%`£)
> Try to derive JDK requirements also from release parameter
> --
>
> Key: MPLUGIN-337
> URL: https://issues.apache.org/jira/browse/MPLUGIN-337
> Project: Maven Plugin Tools
> Issue Type: Bug
> Components: Plugin Plugin
>Affects Versions: 3.5.1
>Reporter: Konrad Windszus
>Assignee: Olivier Lamy (*$^¨%`£)
>Priority: Major
> Fix For: 3.6.0
>
>
> Currently the JDK requirements are extracted
> (https://github.com/apache/maven-plugin-tools/blob/1087f55e8cdfd8c1fec605a7cb9004efaee4e592/maven-plugin-plugin/src/main/java/org/apache/maven/plugin/plugin/PluginReport.java#L759)
> from either
> # the explicitly set requirement (via plugin configuration parameter)
> # or by evaluating the maven-compiler-plugin's {{target}} parameter
> With Java 9 it is pretty common to use {{release}} instead
> (https://maven.apache.org/plugins/maven-compiler-plugin/compile-mojo.html#release).
> Therefore this parameter should be evaluated as well.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MPLUGIN-337) Try to derive JDK requirements also from release parameter
[
https://issues.apache.org/jira/browse/MPLUGIN-337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Olivier Lamy (*$^¨%`£) updated MPLUGIN-337:
---
Fix Version/s: 3.6.0
> Try to derive JDK requirements also from release parameter
> --
>
> Key: MPLUGIN-337
> URL: https://issues.apache.org/jira/browse/MPLUGIN-337
> Project: Maven Plugin Tools
> Issue Type: Bug
> Components: Plugin Plugin
>Affects Versions: 3.5.1
>Reporter: Konrad Windszus
>Assignee: Olivier Lamy (*$^¨%`£)
>Priority: Major
> Fix For: 3.6.0
>
>
> Currently the JDK requirements are extracted
> (https://github.com/apache/maven-plugin-tools/blob/1087f55e8cdfd8c1fec605a7cb9004efaee4e592/maven-plugin-plugin/src/main/java/org/apache/maven/plugin/plugin/PluginReport.java#L759)
> from either
> # the explicitly set requirement (via plugin configuration parameter)
> # or by evaluating the maven-compiler-plugin's {{target}} parameter
> With Java 9 it is pretty common to use {{release}} instead
> (https://maven.apache.org/plugins/maven-compiler-plugin/compile-mojo.html#release).
> Therefore this parameter should be evaluated as well.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MPLUGIN-340) upgrade Ant version to 1.9.13
[ https://issues.apache.org/jira/browse/MPLUGIN-340?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy (*$^¨%`£) updated MPLUGIN-340: --- Fix Version/s: (was: 3.6.0) > upgrade Ant version to 1.9.13 > - > > Key: MPLUGIN-340 > URL: https://issues.apache.org/jira/browse/MPLUGIN-340 > Project: Maven Plugin Tools > Issue Type: Dependency upgrade > Components: maven-plugin-tools-ant >Affects Versions: 3.5.2 >Reporter: Hervé Boutemy >Priority: Major > > to benefit from > https://github.com/apache/ant/commit/857095da5153fd18504b46f276d84f1e76a66970 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (MPLUGIN-340) upgrade Ant version to 1.9.13
[ https://issues.apache.org/jira/browse/MPLUGIN-340?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy (*$^¨%`£) reassigned MPLUGIN-340: -- Assignee: (was: Olivier Lamy (*$^¨%`£)) > upgrade Ant version to 1.9.13 > - > > Key: MPLUGIN-340 > URL: https://issues.apache.org/jira/browse/MPLUGIN-340 > Project: Maven Plugin Tools > Issue Type: Dependency upgrade > Components: maven-plugin-tools-ant >Affects Versions: 3.5.2 >Reporter: Hervé Boutemy >Priority: Major > > to benefit from > https://github.com/apache/ant/commit/857095da5153fd18504b46f276d84f1e76a66970 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MNG-6441) Update to maven-resolver 1.3.0
[ https://issues.apache.org/jira/browse/MNG-6441?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylwester Lachiewicz updated MNG-6441: -- Summary: Update to maven-resolver 1.3.0 (was: Update to maven-resolver 1.1.2) > Update to maven-resolver 1.3.0 > -- > > Key: MNG-6441 > URL: https://issues.apache.org/jira/browse/MNG-6441 > Project: Maven > Issue Type: Improvement >Reporter: Sylwester Lachiewicz >Priority: Minor > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MNG-6164) Collections inconsistently immutable
[
https://issues.apache.org/jira/browse/MNG-6164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16644141#comment-16644141
]
Hudson commented on MNG-6164:
-
Build succeeded in Jenkins: Maven TLP » maven » master #90
See https://builds.apache.org/job/maven-box/job/maven/job/master/90/
> Collections inconsistently immutable
>
>
> Key: MNG-6164
> URL: https://issues.apache.org/jira/browse/MNG-6164
> Project: Maven
> Issue Type: Improvement
>Affects Versions: 3.5.0
>Reporter: Christian Schulte
>Assignee: Michael Osipov
>Priority: Minor
> Fix For: 3.6.0
>
>
> There are plenty of places where empty collections are returned from public
> API in methods written like:
> {code}
> public List getExceptions()
> {
> return exceptions == null ? Collections.emptyList() :
> exceptions;
> }
> {code}
> The issue with this is that the empty list is immutable but the collection
> returned for the nun-null case is not immutable.
> All those methods should return a collection with consistent "mutability":
> either mutable, either immutable.
> Given empty immutable collections do not cause harm until now, switching
> consistently to immutable collections is more conservative and should not be
> risky
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (MNG-6489) Upgrade Maven Resolver to 1.3.0
Michael Osipov created MNG-6489: --- Summary: Upgrade Maven Resolver to 1.3.0 Key: MNG-6489 URL: https://issues.apache.org/jira/browse/MNG-6489 Project: Maven Issue Type: Dependency upgrade Components: Artifacts and Repositories, Dependencies Affects Versions: 3.5.4 Reporter: Michael Osipov Assignee: Michael Osipov Fix For: 3.6.0 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MNG-6164) Collections inconsistently immutable
[
https://issues.apache.org/jira/browse/MNG-6164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16644104#comment-16644104
]
ASF GitHub Bot commented on MNG-6164:
-
michael-o commented on issue #141: [MNG-6164] Collections inconsistently
immutable.
URL: https://github.com/apache/maven/pull/141#issuecomment-428354940
Please close this one, it has been merged.
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Collections inconsistently immutable
>
>
> Key: MNG-6164
> URL: https://issues.apache.org/jira/browse/MNG-6164
> Project: Maven
> Issue Type: Improvement
>Affects Versions: 3.5.0
>Reporter: Christian Schulte
>Assignee: Michael Osipov
>Priority: Minor
> Fix For: 3.6.0
>
>
> There are plenty of places where empty collections are returned from public
> API in methods written like:
> {code}
> public List getExceptions()
> {
> return exceptions == null ? Collections.emptyList() :
> exceptions;
> }
> {code}
> The issue with this is that the empty list is immutable but the collection
> returned for the nun-null case is not immutable.
> All those methods should return a collection with consistent "mutability":
> either mutable, either immutable.
> Given empty immutable collections do not cause harm until now, switching
> consistently to immutable collections is more conservative and should not be
> risky
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (MNG-6164) Collections inconsistently immutable
[
https://issues.apache.org/jira/browse/MNG-6164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed MNG-6164.
---
Resolution: Fixed
Fixed with
[44826ab446d1115d464e73e7e308df36dcf7d39b|https://gitbox.apache.org/repos/asf?p=maven.git;a=commit;h=44826ab446d1115d464e73e7e308df36dcf7d39b].
> Collections inconsistently immutable
>
>
> Key: MNG-6164
> URL: https://issues.apache.org/jira/browse/MNG-6164
> Project: Maven
> Issue Type: Improvement
>Affects Versions: 3.5.0
>Reporter: Christian Schulte
>Assignee: Michael Osipov
>Priority: Minor
> Fix For: 3.6.0
>
>
> There are plenty of places where empty collections are returned from public
> API in methods written like:
> {code}
> public List getExceptions()
> {
> return exceptions == null ? Collections.emptyList() :
> exceptions;
> }
> {code}
> The issue with this is that the empty list is immutable but the collection
> returned for the nun-null case is not immutable.
> All those methods should return a collection with consistent "mutability":
> either mutable, either immutable.
> Given empty immutable collections do not cause harm until now, switching
> consistently to immutable collections is more conservative and should not be
> risky
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] michael-o commented on issue #141: [MNG-6164] Collections inconsistently immutable.
michael-o commented on issue #141: [MNG-6164] Collections inconsistently immutable. URL: https://github.com/apache/maven/pull/141#issuecomment-428354940 Please close this one, it has been merged. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Commented] (MNG-6164) Collections inconsistently immutable
[
https://issues.apache.org/jira/browse/MNG-6164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16644093#comment-16644093
]
Hudson commented on MNG-6164:
-
Build succeeded in Jenkins: Maven TLP » maven » MNG-6164 #17
See https://builds.apache.org/job/maven-box/job/maven/job/MNG-6164/17/
> Collections inconsistently immutable
>
>
> Key: MNG-6164
> URL: https://issues.apache.org/jira/browse/MNG-6164
> Project: Maven
> Issue Type: Improvement
>Affects Versions: 3.5.0
>Reporter: Christian Schulte
>Assignee: Michael Osipov
>Priority: Minor
> Fix For: 3.6.0
>
>
> There are plenty of places where empty collections are returned from public
> API in methods written like:
> {code}
> public List getExceptions()
> {
> return exceptions == null ? Collections.emptyList() :
> exceptions;
> }
> {code}
> The issue with this is that the empty list is immutable but the collection
> returned for the nun-null case is not immutable.
> All those methods should return a collection with consistent "mutability":
> either mutable, either immutable.
> Given empty immutable collections do not cause harm until now, switching
> consistently to immutable collections is more conservative and should not be
> risky
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MNG-6486) Upgrade to Wagon 3.2.0
[ https://issues.apache.org/jira/browse/MNG-6486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16644092#comment-16644092 ] Hudson commented on MNG-6486: - Build succeeded in Jenkins: Maven TLP » maven » MNG-6164 #17 See https://builds.apache.org/job/maven-box/job/maven/job/MNG-6164/17/ > Upgrade to Wagon 3.2.0 > -- > > Key: MNG-6486 > URL: https://issues.apache.org/jira/browse/MNG-6486 > Project: Maven > Issue Type: Dependency upgrade > Components: Dependencies >Affects Versions: 3.5.4 >Reporter: Michael Osipov >Assignee: Michael Osipov >Priority: Major > Fix For: 3.6.0 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MNG-6456) Log $JAVA_HOME when there is an issue with it
[
https://issues.apache.org/jira/browse/MNG-6456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16644086#comment-16644086
]
Michael Osipov commented on MNG-6456:
-
Why is {{echo $JAVA_HOME}} not enough?
> Log $JAVA_HOME when there is an issue with it
> -
>
> Key: MNG-6456
> URL: https://issues.apache.org/jira/browse/MNG-6456
> Project: Maven
> Issue Type: Improvement
> Components: Command Line
>Affects Versions: 3.5.4
>Reporter: Johanneke Lamberink
>Assignee: Michael Osipov
>Priority: Minor
> Fix For: waiting-for-feedback
>
>
> I've just spend more time than was necessary on debugging a problem where
> Maven complained about a missing $JAVA_HOME, because there was no logging of
> which $JAVA_HOME was used.
> It would be really helpful to be able to see the $JAVA_HOME being used by
> Maven, in addition to the current logging:
>
> {noformat}
> The JAVA_HOME environment variable is not defined correctly
> This environment variable is needed to run this program
> NB: JAVA_HOME should point to a JDK not a JRE{noformat}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MNG-6456) Log $JAVA_HOME when there is an issue with it
[
https://issues.apache.org/jira/browse/MNG-6456?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MNG-6456:
Fix Version/s: (was: 3.6.0-candidate)
waiting-for-feedback
> Log $JAVA_HOME when there is an issue with it
> -
>
> Key: MNG-6456
> URL: https://issues.apache.org/jira/browse/MNG-6456
> Project: Maven
> Issue Type: Improvement
> Components: Command Line
>Affects Versions: 3.5.4
>Reporter: Johanneke Lamberink
>Assignee: Michael Osipov
>Priority: Minor
> Fix For: waiting-for-feedback
>
>
> I've just spend more time than was necessary on debugging a problem where
> Maven complained about a missing $JAVA_HOME, because there was no logging of
> which $JAVA_HOME was used.
> It would be really helpful to be able to see the $JAVA_HOME being used by
> Maven, in addition to the current logging:
>
> {noformat}
> The JAVA_HOME environment variable is not defined correctly
> This environment variable is needed to run this program
> NB: JAVA_HOME should point to a JDK not a JRE{noformat}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] spiritualops commented on issue #1: [MASSEMBLY-775] remove false OS-specific warnings/errors
spiritualops commented on issue #1: [MASSEMBLY-775] remove false OS-specific warnings/errors URL: https://github.com/apache/maven-assembly-plugin/pull/1#issuecomment-428346552 How are zip archives deployed to Windows servers with this plugin? Just curious. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Commented] (MASSEMBLY-775) Emit WARNING instead of ERROR
[
https://issues.apache.org/jira/browse/MASSEMBLY-775?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16644077#comment-16644077
]
ASF GitHub Bot commented on MASSEMBLY-775:
--
spiritualops commented on issue #1: [MASSEMBLY-775] remove false OS-specific
warnings/errors
URL:
https://github.com/apache/maven-assembly-plugin/pull/1#issuecomment-428346552
How are zip archives deployed to Windows servers with this plugin? Just
curious.
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Emit WARNING instead of ERROR
> -
>
> Key: MASSEMBLY-775
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-775
> Project: Maven Assembly Plugin
> Issue Type: Improvement
>Affects Versions: 2.5.5
>Reporter: Karl Heinz Marbaise
>Priority: Minor
>
> I have currently a build which creates several tar/tar.gz/zip archives etc.
> {code}
> [INFO] Reading assembly descriptor: src/main/assembly/descriptor-inner-tar.xml
> [INFO] Reading assembly descriptor: src/main/assembly/descriptor.xml
> [INFO] Building tar: C:\...\xyz-X.y.z-SNAPSHOT-dist.tar
> [ERROR] OS=Windows and the assembly descriptor contains a *nix-specific
> root-relative-reference (starting with slash) /
> [ERROR] OS=Windows and the assembly descriptor contains a *nix-specific
> root-relative-reference (starting with slash) /
> {code}
> In my opinion the message could be a WARNING instead of an error ? WDYT ?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (MNG-6164) Collections inconsistently immutable
[
https://issues.apache.org/jira/browse/MNG-6164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov reassigned MNG-6164:
---
Assignee: Michael Osipov (was: Karl Heinz Marbaise)
> Collections inconsistently immutable
>
>
> Key: MNG-6164
> URL: https://issues.apache.org/jira/browse/MNG-6164
> Project: Maven
> Issue Type: Improvement
>Affects Versions: 3.5.0
>Reporter: Christian Schulte
>Assignee: Michael Osipov
>Priority: Minor
> Fix For: 3.6.0
>
>
> There are plenty of places where empty collections are returned from public
> API in methods written like:
> {code}
> public List getExceptions()
> {
> return exceptions == null ? Collections.emptyList() :
> exceptions;
> }
> {code}
> The issue with this is that the empty list is immutable but the collection
> returned for the nun-null case is not immutable.
> All those methods should return a collection with consistent "mutability":
> either mutable, either immutable.
> Given empty immutable collections do not cause harm until now, switching
> consistently to immutable collections is more conservative and should not be
> risky
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MNG-6164) Collections inconsistently immutable
[
https://issues.apache.org/jira/browse/MNG-6164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MNG-6164:
Fix Version/s: (was: 3.6.x-candidate)
3.6.0
> Collections inconsistently immutable
>
>
> Key: MNG-6164
> URL: https://issues.apache.org/jira/browse/MNG-6164
> Project: Maven
> Issue Type: Improvement
>Affects Versions: 3.5.0
>Reporter: Christian Schulte
>Assignee: Michael Osipov
>Priority: Minor
> Fix For: 3.6.0
>
>
> There are plenty of places where empty collections are returned from public
> API in methods written like:
> {code}
> public List getExceptions()
> {
> return exceptions == null ? Collections.emptyList() :
> exceptions;
> }
> {code}
> The issue with this is that the empty list is immutable but the collection
> returned for the nun-null case is not immutable.
> All those methods should return a collection with consistent "mutability":
> either mutable, either immutable.
> Given empty immutable collections do not cause harm until now, switching
> consistently to immutable collections is more conservative and should not be
> risky
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MNG-6391) Printout version of last built module in reactor build
[
https://issues.apache.org/jira/browse/MNG-6391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16643983#comment-16643983
]
Hudson commented on MNG-6391:
-
Build succeeded in Jenkins: Maven TLP » maven » MNG-6391 #28
See https://builds.apache.org/job/maven-box/job/maven/job/MNG-6391/28/
> Printout version of last built module in reactor build
> --
>
> Key: MNG-6391
> URL: https://issues.apache.org/jira/browse/MNG-6391
> Project: Maven
> Issue Type: Improvement
> Components: core
>Affects Versions: 3.5.3
>Reporter: Alexander Griesbaum
>Assignee: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 3.6.0
>
>
> MNG-6352 introduced printout of the version in a reactor build.
> If I build a multi-module project, not just the parent has the version
> printout but also the last built module.
> {code:java}
> [INFO]
>
> [INFO] Reactor Summary:
> [INFO]
> [INFO] parent 4.0.0-SNAPSHOT . SUCCESS [ 3.610 s]
> [INFO] parent-lib SUCCESS [ 0.492 s]
> [INFO] commons ... SUCCESS [ 25.444 s]
> [INFO] loadbalancer-starter .. SUCCESS [ 21.198 s]
> [INFO] proxy-config-starter 4.0.0-SNAPSHOT ... SUCCESS [ 7.496 s]
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> {code}
> If I remove the "proxy-config-starter" module, "loadbalancer-starter" got the
> version printout.
> Also this is not the order I configured the modules in the parent pom but I
> think this could be something on my side.
> {code:java}
>
> commons
> loadbalancer-starter
> parent-lib
> proxy-config-starter
>
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MENFORCER-285) error parameters 'rules' are missing or invalid
[
https://issues.apache.org/jira/browse/MENFORCER-285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16643971#comment-16643971
]
Karl Heinz Marbaise commented on MENFORCER-285:
---
If you call {{mvn enforcer:enforce}} than no life cycle is started. This means
that no configuration is used which is defined in the above pom file.
If you like to run {{mvn enforcer:enforcer}} and get the above configuration
you can use ([starting with Maven
3.3.1+|http://maven.apache.org/docs/3.3.1/release-notes.html]) it like this:
{{mvn enforcer:enforce@enforce}} which will use the configuration given by the
{{enforcer}}.
The position of the {{configuration}} tag has it's meaning and nothing to do
with {{old syntax}}. If you define the configuration as given in the above
example. The configuration is only applied for the execution block in which it
is contained. If you locate the {{configuration}} tag outside the execution
block it is applied globally for all executions including the execution via
command line. There exists a special id for execution from command line which
is named {{default-cli}} which can be used to make different configurations for
command line and life cycle which was the only possibility to have different
configurations before Maven 3.3.1... By using Maven 3.3.1+ you can have
multiple configurations defined in your pom file which you can select on
command line if you need.
The different locations for the configuration block gives you also the option
to define globally some common configurations for a plugin and in the
executions with another configuration tag you can overwrite or enhance
configurations.
So in the end this is no bug it's only a misunderstand how configuration of
plugins/life cycle works. So I close this issue.
> error parameters 'rules' are missing or invalid
> -
>
> Key: MENFORCER-285
> URL: https://issues.apache.org/jira/browse/MENFORCER-285
> Project: Maven Enforcer Plugin
> Issue Type: Bug
> Components: Plugin
>Affects Versions: 3.0.0-M1
> Environment: linux
>Reporter: Ernst Reissner
>Priority: Major
>
> I have the following config under build.plugins:
> {code:xml}
>
> org.apache.maven.plugins
> maven-enforcer-plugin
> 3.0.0-M1
>
>
> enforce
>
> enforce
>
>
>
>
>
> 3.5.0
>
>
>
>
> true
> true
>
>
>
>
> {code}
> Then
> {{mvn enforcer:enforce}}
> yields
> {code}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-enforcer-plugin:3.0.0-M1:enforce (default-cli)
> on project Relana: The parameters 'rules' for goal
> org.apache.maven.plugins:maven-enforcer-plugin:3.0.0-M1:enforce are missing
> or invalid -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-enforcer-plugin:3.0.0-M1:enforce
> (default-cli) on project Relana: The parameters 'rules' for goal
> org.apache.maven.plugins:maven-enforcer-plugin:3.0.0-M1:enforce are missing
> or invalid
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:213)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:154)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:146)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:117)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:81)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:309)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:194)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:107)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:993)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:345)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:191)
> 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.inv
[jira] [Closed] (MENFORCER-285) error parameters 'rules' are missing or invalid
[
https://issues.apache.org/jira/browse/MENFORCER-285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Heinz Marbaise closed MENFORCER-285.
-
Resolution: Not A Problem
> error parameters 'rules' are missing or invalid
> -
>
> Key: MENFORCER-285
> URL: https://issues.apache.org/jira/browse/MENFORCER-285
> Project: Maven Enforcer Plugin
> Issue Type: Bug
> Components: Plugin
>Affects Versions: 3.0.0-M1
> Environment: linux
>Reporter: Ernst Reissner
>Priority: Major
>
> I have the following config under build.plugins:
> {code:xml}
>
> org.apache.maven.plugins
> maven-enforcer-plugin
> 3.0.0-M1
>
>
> enforce
>
> enforce
>
>
>
>
>
> 3.5.0
>
>
>
>
> true
> true
>
>
>
>
> {code}
> Then
> {{mvn enforcer:enforce}}
> yields
> {code}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-enforcer-plugin:3.0.0-M1:enforce (default-cli)
> on project Relana: The parameters 'rules' for goal
> org.apache.maven.plugins:maven-enforcer-plugin:3.0.0-M1:enforce are missing
> or invalid -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-enforcer-plugin:3.0.0-M1:enforce
> (default-cli) on project Relana: The parameters 'rules' for goal
> org.apache.maven.plugins:maven-enforcer-plugin:3.0.0-M1:enforce are missing
> or invalid
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:213)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:154)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:146)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:117)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:81)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:309)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:194)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:107)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:993)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:345)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:191)
> 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:498)
> 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: org.apache.maven.plugin.PluginParameterException: The parameters
> 'rules' for goal
> org.apache.maven.plugins:maven-enforcer-plugin:3.0.0-M1:enforce are missing
> or invalid
> at
> org.apache.maven.plugin.internal.DefaultMavenPluginManager.populatePluginFields(DefaultMavenPluginManager.java:643)
> at
> org.apache.maven.plugin.internal.DefaultMavenPluginManager.getConfiguredMojo(DefaultMavenPluginManager.java:596)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:121)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
> ... 20 more
> [ERROR]
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please
> read the following articles:
> [ERROR] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/PluginParameterException
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MENFORCER-285) error parameters 'rules' are missing or invalid
[
https://issues.apache.org/jira/browse/MENFORCER-285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Heinz Marbaise updated MENFORCER-285:
--
Description:
I have the following config under build.plugins:
{code:xml}
org.apache.maven.plugins
maven-enforcer-plugin
3.0.0-M1
enforce
enforce
3.5.0
true
true
{code}
Then
{{mvn enforcer:enforce}}
yields
{code}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-enforcer-plugin:3.0.0-M1:enforce (default-cli)
on project Relana: The parameters 'rules' for goal
org.apache.maven.plugins:maven-enforcer-plugin:3.0.0-M1:enforce are missing or
invalid -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal
org.apache.maven.plugins:maven-enforcer-plugin:3.0.0-M1:enforce (default-cli)
on project Relana: The parameters 'rules' for goal
org.apache.maven.plugins:maven-enforcer-plugin:3.0.0-M1:enforce are missing or
invalid
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:213)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:154)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:146)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:117)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:81)
at
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:309)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:194)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:107)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:993)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:345)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:191)
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:498)
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: org.apache.maven.plugin.PluginParameterException: The parameters
'rules' for goal
org.apache.maven.plugins:maven-enforcer-plugin:3.0.0-M1:enforce are missing or
invalid
at
org.apache.maven.plugin.internal.DefaultMavenPluginManager.populatePluginFields(DefaultMavenPluginManager.java:643)
at
org.apache.maven.plugin.internal.DefaultMavenPluginManager.getConfiguredMojo(DefaultMavenPluginManager.java:596)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:121)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
... 20 more
[ERROR]
[ERROR]
[ERROR] For more information about the errors and possible solutions, please
read the following articles:
[ERROR] [Help 1]
http://cwiki.apache.org/confluence/display/MAVEN/PluginParameterException
{code}
was:
I have the following config under build.plugins:
org.apache.maven.plugins
maven-enforcer-plugin
3.0.0-M1
enforce
enforce
3.5.0
true
true
Then
mvn enforcer:enforce
yields
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-enforcer-plugin:3.0.0-M1:enforce (default-cli)
on project Relana: The parameters 'rules' for goal
org.apache.maven.plugins:maven-enforcer-plugin:3.0.0-M1:enforce are missing or
invalid -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal
org.apache.maven.plugins:maven-enforcer-plugin:3.0.0-M1:enforce (default-cli)
on project Relana: The paramet
[jira] [Commented] (MGPG-66) sign goal's "excludes" configuration ignored
[ https://issues.apache.org/jira/browse/MGPG-66?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16643930#comment-16643930 ] Marshall Schor commented on MGPG-66: Git patch attached. > sign goal's "excludes" configuration ignored > > > Key: MGPG-66 > URL: https://issues.apache.org/jira/browse/MGPG-66 > Project: Maven GPG Plugin > Issue Type: Bug >Affects Versions: 1.6 >Reporter: Marshall Schor >Priority: Major > Attachments: maven-gpg-plugin-MGPG-66-patch.txt > > > The class GpgSignAttachedMojo computes the excludes, and has a method > isExcluded(name), but that method is never called. As a result, the excludes > are ignored. > A fix is to add if ( ! isExcluded( file.getPath() ) ) around the code in the > loop over all attached artifacts. (I tried this and it seems to work) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MDEPLOY-244) maven deploy plugin 3.0.0-M1 breaks RPM deploys
[ https://issues.apache.org/jira/browse/MDEPLOY-244?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16643929#comment-16643929 ] Karl Heinz Marbaise commented on MDEPLOY-244: - [~alillie] That's absolute ok (To be honest. I expected that ;-)) . I just asked. If you could setup a test job would be great help > maven deploy plugin 3.0.0-M1 breaks RPM deploys > --- > > Key: MDEPLOY-244 > URL: https://issues.apache.org/jira/browse/MDEPLOY-244 > Project: Maven Deploy Plugin > Issue Type: Bug > Components: deploy:deploy-file >Affects Versions: 3.0.0-M1 >Reporter: William So >Priority: Critical > Attachments: test-maven-deploy.zip > > > After upgrading to maven deploy plugin to 3.0.0-M1, our Maven Builds that > uploads an RPM artifact broke. All other artifacts, like zips, pom, jar, > etc.. was able to upload without problems. But as soon as the build tried > to upload an RPM the upload threw an 401 Error: > > [Continue Pipeline] [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-deploy-plugin:3.0.0-M1:deploy (default-deploy) > on project company-fancyname-atg-apptype-ibm-qa4: ArtifactDeployerException: > Failed to deploy artifacts: Could not transfer artifact > com.sephops.fancyname:company-fancyname-atg-apptype-ibm-qa4:rpm:ProjectName-20181001.061415-35 > from/to company-snapshot-yum::default > (http://artifactory.com/artifactory/company-snapshot-yum-local): Failed to > transfer file: > http://artifactory.com/artifactory/company-snapshot-yum-local/com/sephops/fancyname/company-fancyname-atg-apptype-ibm-qa4/ProjectName-SNAPSHOT/company-fancyname-atg-apptype-ibm-qa4-ProjectName-20181001.061415-35.rpm. > Return code is: 401, ReasonPhrase: Unauthorized. -> [Help 1] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MGPG-66) sign goal's "excludes" configuration ignored
[ https://issues.apache.org/jira/browse/MGPG-66?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor updated MGPG-66: --- Attachment: maven-gpg-plugin-MGPG-66-patch.txt > sign goal's "excludes" configuration ignored > > > Key: MGPG-66 > URL: https://issues.apache.org/jira/browse/MGPG-66 > Project: Maven GPG Plugin > Issue Type: Bug >Affects Versions: 1.6 >Reporter: Marshall Schor >Priority: Major > Attachments: maven-gpg-plugin-MGPG-66-patch.txt > > > The class GpgSignAttachedMojo computes the excludes, and has a method > isExcluded(name), but that method is never called. As a result, the excludes > are ignored. > A fix is to add if ( ! isExcluded( file.getPath() ) ) around the code in the > loop over all attached artifacts. (I tried this and it seems to work) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MGPG-66) sign goal's "excludes" configuration ignored
[ https://issues.apache.org/jira/browse/MGPG-66?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor updated MGPG-66: --- Attachment: (was: maven-gpg-plugin-1.6-MGPG-66.txt) > sign goal's "excludes" configuration ignored > > > Key: MGPG-66 > URL: https://issues.apache.org/jira/browse/MGPG-66 > Project: Maven GPG Plugin > Issue Type: Bug >Affects Versions: 1.6 >Reporter: Marshall Schor >Priority: Major > Attachments: maven-gpg-plugin-MGPG-66-patch.txt > > > The class GpgSignAttachedMojo computes the excludes, and has a method > isExcluded(name), but that method is never called. As a result, the excludes > are ignored. > A fix is to add if ( ! isExcluded( file.getPath() ) ) around the code in the > loop over all attached artifacts. (I tried this and it seems to work) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MINVOKER-243) invoker:install doesn't copy transitive dependencies anymore (as of 3.1.0)
[
https://issues.apache.org/jira/browse/MINVOKER-243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16643922#comment-16643922
]
Christopher Tubbs commented on MINVOKER-243:
[~rfscholte], yes. In this case, the transitive dependency is a sibling module
in a multi-module project.
Example:
module A: depends on commons-configuration
module B: depends on A and commons-io
module C: maven plugin configured with invoker for ITs, depends on B
{{invoker:install}} in module C should install the jar from module B, and also
the jar from module A (because it is a transitive dependency of B), but not
commons-io or commons-configuration.
Version 3.0.1 works fine, but 3.1.0 fails to install module A, instead only
installing module B.
> invoker:install doesn't copy transitive dependencies anymore (as of 3.1.0)
> --
>
> Key: MINVOKER-243
> URL: https://issues.apache.org/jira/browse/MINVOKER-243
> Project: Maven Invoker Plugin
> Issue Type: Bug
>Affects Versions: 3.1.0
>Reporter: Christopher Tubbs
>Priority: Blocker
>
> Something seems to have broken between 3.0.1 and 3.1.0, as the install goal
> no longer copies transitive dependencies to the localRepositoryPath as it did
> in version 3.0.1.
> This is very problematic, because if the artifacts are not in the
> localRepositoryPath, the invoked project will try to download them from a
> remote repository, which isn't possible for SNAPSHOT versions (such as those
> in a sibling module in a multi-module project). This can make it difficult to
> even build a multi-module project, unless the invoked task is skipped and the
> sibling module can be published to a remote snapshot repository temporarily,
> and then the build re-executed normally. (Saw this happen in Apache Accumulo
> after upgrading to apache-21.pom)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
RE: EXTERNAL: [jira] [Commented] (MDEPLOY-244) maven deploy plugin 3.0.0-M1 breaks RPM deploys
UNSUBSCRIBE -Original Message- From: Andrew Lillie (JIRA) Sent: Tuesday, October 9, 2018 2:29 PM To: issues@maven.apache.org Subject: EXTERNAL: [jira] [Commented] (MDEPLOY-244) maven deploy plugin 3.0.0-M1 breaks RPM deploys [ https://issues.apache.org/jira/browse/MDEPLOY-244?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16643916#comment-16643916 ] Andrew Lillie commented on MDEPLOY-244: --- [~khmarbaise] We're using Maven 3.5.2, and typically running "mvn clean deploy". > maven deploy plugin 3.0.0-M1 breaks RPM deploys > --- > > Key: MDEPLOY-244 > URL: https://issues.apache.org/jira/browse/MDEPLOY-244 > Project: Maven Deploy Plugin > Issue Type: Bug > Components: deploy:deploy-file >Affects Versions: 3.0.0-M1 >Reporter: William So >Priority: Critical > Attachments: test-maven-deploy.zip > > > After upgrading to maven deploy plugin to 3.0.0-M1, our Maven Builds that > uploads an RPM artifact broke. All other artifacts, like zips, pom, jar, > etc.. was able to upload without problems. But as soon as the build tried > to upload an RPM the upload threw an 401 Error: > > [Continue Pipeline] [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-deploy-plugin:3.0.0-M1:deploy (default-deploy) > on project company-fancyname-atg-apptype-ibm-qa4: ArtifactDeployerException: > Failed to deploy artifacts: Could not transfer artifact > com.sephops.fancyname:company-fancyname-atg-apptype-ibm-qa4:rpm:ProjectName-20181001.061415-35 > from/to company-snapshot-yum::default > (http://artifactory.com/artifactory/company-snapshot-yum-local): Failed to > transfer file: > http://artifactory.com/artifactory/company-snapshot-yum-local/com/sephops/fancyname/company-fancyname-atg-apptype-ibm-qa4/ProjectName-SNAPSHOT/company-fancyname-atg-apptype-ibm-qa4-ProjectName-20181001.061415-35.rpm. > Return code is: 401, ReasonPhrase: Unauthorized. -> [Help 1] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MDEPLOY-244) maven deploy plugin 3.0.0-M1 breaks RPM deploys
[ https://issues.apache.org/jira/browse/MDEPLOY-244?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16643918#comment-16643918 ] Andrew Lillie commented on MDEPLOY-244: --- I don't feel comfortable sharing a real project, and I'm blocking 3.0.0-M1 at our artifact store. But, I'll see if I can find some time to setup an environment and dummy job to test that for you. > maven deploy plugin 3.0.0-M1 breaks RPM deploys > --- > > Key: MDEPLOY-244 > URL: https://issues.apache.org/jira/browse/MDEPLOY-244 > Project: Maven Deploy Plugin > Issue Type: Bug > Components: deploy:deploy-file >Affects Versions: 3.0.0-M1 >Reporter: William So >Priority: Critical > Attachments: test-maven-deploy.zip > > > After upgrading to maven deploy plugin to 3.0.0-M1, our Maven Builds that > uploads an RPM artifact broke. All other artifacts, like zips, pom, jar, > etc.. was able to upload without problems. But as soon as the build tried > to upload an RPM the upload threw an 401 Error: > > [Continue Pipeline] [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-deploy-plugin:3.0.0-M1:deploy (default-deploy) > on project company-fancyname-atg-apptype-ibm-qa4: ArtifactDeployerException: > Failed to deploy artifacts: Could not transfer artifact > com.sephops.fancyname:company-fancyname-atg-apptype-ibm-qa4:rpm:ProjectName-20181001.061415-35 > from/to company-snapshot-yum::default > (http://artifactory.com/artifactory/company-snapshot-yum-local): Failed to > transfer file: > http://artifactory.com/artifactory/company-snapshot-yum-local/com/sephops/fancyname/company-fancyname-atg-apptype-ibm-qa4/ProjectName-SNAPSHOT/company-fancyname-atg-apptype-ibm-qa4-ProjectName-20181001.061415-35.rpm. > Return code is: 401, ReasonPhrase: Unauthorized. -> [Help 1] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MDEPLOY-244) maven deploy plugin 3.0.0-M1 breaks RPM deploys
[ https://issues.apache.org/jira/browse/MDEPLOY-244?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16643916#comment-16643916 ] Andrew Lillie commented on MDEPLOY-244: --- [~khmarbaise] We're using Maven 3.5.2, and typically running "mvn clean deploy". > maven deploy plugin 3.0.0-M1 breaks RPM deploys > --- > > Key: MDEPLOY-244 > URL: https://issues.apache.org/jira/browse/MDEPLOY-244 > Project: Maven Deploy Plugin > Issue Type: Bug > Components: deploy:deploy-file >Affects Versions: 3.0.0-M1 >Reporter: William So >Priority: Critical > Attachments: test-maven-deploy.zip > > > After upgrading to maven deploy plugin to 3.0.0-M1, our Maven Builds that > uploads an RPM artifact broke. All other artifacts, like zips, pom, jar, > etc.. was able to upload without problems. But as soon as the build tried > to upload an RPM the upload threw an 401 Error: > > [Continue Pipeline] [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-deploy-plugin:3.0.0-M1:deploy (default-deploy) > on project company-fancyname-atg-apptype-ibm-qa4: ArtifactDeployerException: > Failed to deploy artifacts: Could not transfer artifact > com.sephops.fancyname:company-fancyname-atg-apptype-ibm-qa4:rpm:ProjectName-20181001.061415-35 > from/to company-snapshot-yum::default > (http://artifactory.com/artifactory/company-snapshot-yum-local): Failed to > transfer file: > http://artifactory.com/artifactory/company-snapshot-yum-local/com/sephops/fancyname/company-fancyname-atg-apptype-ibm-qa4/ProjectName-SNAPSHOT/company-fancyname-atg-apptype-ibm-qa4-ProjectName-20181001.061415-35.rpm. > Return code is: 401, ReasonPhrase: Unauthorized. -> [Help 1] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MDEPLOY-244) maven deploy plugin 3.0.0-M1 breaks RPM deploys
[
https://issues.apache.org/jira/browse/MDEPLOY-244?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16643902#comment-16643902
]
Karl Heinz Marbaise commented on MDEPLOY-244:
-
[~alillie] Can you please check to use the most recent version of
rpm-maven-plugin ...would it possible to run your deploy via {{mvn clean deploy
-X >mvn.log}} and send me the log file or if possible attach it to this ticket?
> maven deploy plugin 3.0.0-M1 breaks RPM deploys
> ---
>
> Key: MDEPLOY-244
> URL: https://issues.apache.org/jira/browse/MDEPLOY-244
> Project: Maven Deploy Plugin
> Issue Type: Bug
> Components: deploy:deploy-file
>Affects Versions: 3.0.0-M1
>Reporter: William So
>Priority: Critical
> Attachments: test-maven-deploy.zip
>
>
> After upgrading to maven deploy plugin to 3.0.0-M1, our Maven Builds that
> uploads an RPM artifact broke. All other artifacts, like zips, pom, jar,
> etc.. was able to upload without problems. But as soon as the build tried
> to upload an RPM the upload threw an 401 Error:
>
> [Continue Pipeline] [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-deploy-plugin:3.0.0-M1:deploy (default-deploy)
> on project company-fancyname-atg-apptype-ibm-qa4: ArtifactDeployerException:
> Failed to deploy artifacts: Could not transfer artifact
> com.sephops.fancyname:company-fancyname-atg-apptype-ibm-qa4:rpm:ProjectName-20181001.061415-35
> from/to company-snapshot-yum::default
> (http://artifactory.com/artifactory/company-snapshot-yum-local): Failed to
> transfer file:
> http://artifactory.com/artifactory/company-snapshot-yum-local/com/sephops/fancyname/company-fancyname-atg-apptype-ibm-qa4/ProjectName-SNAPSHOT/company-fancyname-atg-apptype-ibm-qa4-ProjectName-20181001.061415-35.rpm.
> Return code is: 401, ReasonPhrase: Unauthorized. -> [Help 1]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MDEPLOY-244) maven deploy plugin 3.0.0-M1 breaks RPM deploys
[
https://issues.apache.org/jira/browse/MDEPLOY-244?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16643829#comment-16643829
]
Karl Heinz Marbaise commented on MDEPLOY-244:
-
[~william.so], [~alillie] can you tell me how you called Maven just by {{mvn
deploy}} ? BTW: Can add which Maven version you have used?
[~peterlynch] Many thanks for your check..
> maven deploy plugin 3.0.0-M1 breaks RPM deploys
> ---
>
> Key: MDEPLOY-244
> URL: https://issues.apache.org/jira/browse/MDEPLOY-244
> Project: Maven Deploy Plugin
> Issue Type: Bug
> Components: deploy:deploy-file
>Affects Versions: 3.0.0-M1
>Reporter: William So
>Priority: Critical
> Attachments: test-maven-deploy.zip
>
>
> After upgrading to maven deploy plugin to 3.0.0-M1, our Maven Builds that
> uploads an RPM artifact broke. All other artifacts, like zips, pom, jar,
> etc.. was able to upload without problems. But as soon as the build tried
> to upload an RPM the upload threw an 401 Error:
>
> [Continue Pipeline] [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-deploy-plugin:3.0.0-M1:deploy (default-deploy)
> on project company-fancyname-atg-apptype-ibm-qa4: ArtifactDeployerException:
> Failed to deploy artifacts: Could not transfer artifact
> com.sephops.fancyname:company-fancyname-atg-apptype-ibm-qa4:rpm:ProjectName-20181001.061415-35
> from/to company-snapshot-yum::default
> (http://artifactory.com/artifactory/company-snapshot-yum-local): Failed to
> transfer file:
> http://artifactory.com/artifactory/company-snapshot-yum-local/com/sephops/fancyname/company-fancyname-atg-apptype-ibm-qa4/ProjectName-SNAPSHOT/company-fancyname-atg-apptype-ibm-qa4-ProjectName-20181001.061415-35.rpm.
> Return code is: 401, ReasonPhrase: Unauthorized. -> [Help 1]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MDEPLOY-244) maven deploy plugin 3.0.0-M1 breaks RPM deploys
[ https://issues.apache.org/jira/browse/MDEPLOY-244?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16643750#comment-16643750 ] Peter lynch commented on MDEPLOY-244: - [~khmarbaise] I've done a spot check. One was while deploying an artifact with file extension "dar". One was while deploying an artifact with file extension "swf". One was while deploying an artifact with file extension "jar", named like _module-3.500.348.jar_ Another was while deploying an Maven archetype artifact with file extension "jar" , named like _module-archetype-2.4.440.jar_ > maven deploy plugin 3.0.0-M1 breaks RPM deploys > --- > > Key: MDEPLOY-244 > URL: https://issues.apache.org/jira/browse/MDEPLOY-244 > Project: Maven Deploy Plugin > Issue Type: Bug > Components: deploy:deploy-file >Affects Versions: 3.0.0-M1 >Reporter: William So >Priority: Critical > Attachments: test-maven-deploy.zip > > > After upgrading to maven deploy plugin to 3.0.0-M1, our Maven Builds that > uploads an RPM artifact broke. All other artifacts, like zips, pom, jar, > etc.. was able to upload without problems. But as soon as the build tried > to upload an RPM the upload threw an 401 Error: > > [Continue Pipeline] [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-deploy-plugin:3.0.0-M1:deploy (default-deploy) > on project company-fancyname-atg-apptype-ibm-qa4: ArtifactDeployerException: > Failed to deploy artifacts: Could not transfer artifact > com.sephops.fancyname:company-fancyname-atg-apptype-ibm-qa4:rpm:ProjectName-20181001.061415-35 > from/to company-snapshot-yum::default > (http://artifactory.com/artifactory/company-snapshot-yum-local): Failed to > transfer file: > http://artifactory.com/artifactory/company-snapshot-yum-local/com/sephops/fancyname/company-fancyname-atg-apptype-ibm-qa4/ProjectName-SNAPSHOT/company-fancyname-atg-apptype-ibm-qa4-ProjectName-20181001.061415-35.rpm. > Return code is: 401, ReasonPhrase: Unauthorized. -> [Help 1] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (MDEPLOY-244) maven deploy plugin 3.0.0-M1 breaks RPM deploys
[ https://issues.apache.org/jira/browse/MDEPLOY-244?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16643743#comment-16643743 ] Karl Heinz Marbaise edited comment on MDEPLOY-244 at 10/9/18 5:07 PM: -- [~alillie] That narrows things down. Thanks for your feedback. was (Author: khmarbaise): [~alillie] That narrows thing down. Thanks for your feedback. > maven deploy plugin 3.0.0-M1 breaks RPM deploys > --- > > Key: MDEPLOY-244 > URL: https://issues.apache.org/jira/browse/MDEPLOY-244 > Project: Maven Deploy Plugin > Issue Type: Bug > Components: deploy:deploy-file >Affects Versions: 3.0.0-M1 >Reporter: William So >Priority: Critical > Attachments: test-maven-deploy.zip > > > After upgrading to maven deploy plugin to 3.0.0-M1, our Maven Builds that > uploads an RPM artifact broke. All other artifacts, like zips, pom, jar, > etc.. was able to upload without problems. But as soon as the build tried > to upload an RPM the upload threw an 401 Error: > > [Continue Pipeline] [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-deploy-plugin:3.0.0-M1:deploy (default-deploy) > on project company-fancyname-atg-apptype-ibm-qa4: ArtifactDeployerException: > Failed to deploy artifacts: Could not transfer artifact > com.sephops.fancyname:company-fancyname-atg-apptype-ibm-qa4:rpm:ProjectName-20181001.061415-35 > from/to company-snapshot-yum::default > (http://artifactory.com/artifactory/company-snapshot-yum-local): Failed to > transfer file: > http://artifactory.com/artifactory/company-snapshot-yum-local/com/sephops/fancyname/company-fancyname-atg-apptype-ibm-qa4/ProjectName-SNAPSHOT/company-fancyname-atg-apptype-ibm-qa4-ProjectName-20181001.061415-35.rpm. > Return code is: 401, ReasonPhrase: Unauthorized. -> [Help 1] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MDEPLOY-244) maven deploy plugin 3.0.0-M1 breaks RPM deploys
[ https://issues.apache.org/jira/browse/MDEPLOY-244?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16643743#comment-16643743 ] Karl Heinz Marbaise commented on MDEPLOY-244: - [~alillie] That narrows thing down. Thanks for your feedback. > maven deploy plugin 3.0.0-M1 breaks RPM deploys > --- > > Key: MDEPLOY-244 > URL: https://issues.apache.org/jira/browse/MDEPLOY-244 > Project: Maven Deploy Plugin > Issue Type: Bug > Components: deploy:deploy-file >Affects Versions: 3.0.0-M1 >Reporter: William So >Priority: Critical > Attachments: test-maven-deploy.zip > > > After upgrading to maven deploy plugin to 3.0.0-M1, our Maven Builds that > uploads an RPM artifact broke. All other artifacts, like zips, pom, jar, > etc.. was able to upload without problems. But as soon as the build tried > to upload an RPM the upload threw an 401 Error: > > [Continue Pipeline] [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-deploy-plugin:3.0.0-M1:deploy (default-deploy) > on project company-fancyname-atg-apptype-ibm-qa4: ArtifactDeployerException: > Failed to deploy artifacts: Could not transfer artifact > com.sephops.fancyname:company-fancyname-atg-apptype-ibm-qa4:rpm:ProjectName-20181001.061415-35 > from/to company-snapshot-yum::default > (http://artifactory.com/artifactory/company-snapshot-yum-local): Failed to > transfer file: > http://artifactory.com/artifactory/company-snapshot-yum-local/com/sephops/fancyname/company-fancyname-atg-apptype-ibm-qa4/ProjectName-SNAPSHOT/company-fancyname-atg-apptype-ibm-qa4-ProjectName-20181001.061415-35.rpm. > Return code is: 401, ReasonPhrase: Unauthorized. -> [Help 1] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (MINSTALL-154) Remove link on index page to checksum example page
Karl Heinz Marbaise created MINSTALL-154: Summary: Remove link on index page to checksum example page Key: MINSTALL-154 URL: https://issues.apache.org/jira/browse/MINSTALL-154 Project: Maven Install Plugin Issue Type: Bug Affects Versions: 3.0.0-M1 Reporter: Karl Heinz Marbaise Assignee: Karl Heinz Marbaise Fix For: 3.0.0 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MINSTALL-148) Document change about createChecksums
[ https://issues.apache.org/jira/browse/MINSTALL-148?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16643715#comment-16643715 ] Karl Heinz Marbaise commented on MINSTALL-148: -- Please open a new JIRA ticket...apart from that on start page it is mentioned: https://maven.apache.org/plugins/maven-install-plugin/ > Document change about createChecksums > - > > Key: MINSTALL-148 > URL: https://issues.apache.org/jira/browse/MINSTALL-148 > Project: Maven Install Plugin > Issue Type: Task >Affects Versions: 3.0.0-M1 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Blocker > Fix For: 3.0.0-M1 > > > Document change about createChecksums and remove documentation about create > checksums from plugin. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MINSTALL-148) Document change about createChecksums
[ https://issues.apache.org/jira/browse/MINSTALL-148?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16643701#comment-16643701 ] ASF GitHub Bot commented on MINSTALL-148: - s50600822 opened a new pull request #4: [MINSTALL-148] - Document change about createChecksums URL: https://github.com/apache/maven-install-plugin/pull/4 Document the removal of checksum in install plugin. I was looking for checksum generation because my problem with checksum Policy failure, seeing https://maven.apache.org/plugins/maven-install-plugin/examples/installing-checksums.html confused me more. I think it's better to leave a note here and point people to the right direction if they are looking for checksum generation is better: https://user-images.githubusercontent.com/5586453/46683549-39863180-cc3c-11e8-9185-007ec8df664a.png";> This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Document change about createChecksums > - > > Key: MINSTALL-148 > URL: https://issues.apache.org/jira/browse/MINSTALL-148 > Project: Maven Install Plugin > Issue Type: Task >Affects Versions: 3.0.0-M1 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Blocker > Fix For: 3.0.0-M1 > > > Document change about createChecksums and remove documentation about create > checksums from plugin. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] s50600822 opened a new pull request #4: [MINSTALL-148] - Document change about createChecksums
s50600822 opened a new pull request #4: [MINSTALL-148] - Document change about createChecksums URL: https://github.com/apache/maven-install-plugin/pull/4 Document the removal of checksum in install plugin. I was looking for checksum generation because my problem with checksum Policy failure, seeing https://maven.apache.org/plugins/maven-install-plugin/examples/installing-checksums.html confused me more. I think it's better to leave a note here and point people to the right direction if they are looking for checksum generation is better: https://user-images.githubusercontent.com/5586453/46683549-39863180-cc3c-11e8-9185-007ec8df664a.png";> This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Commented] (MDEPLOY-244) maven deploy plugin 3.0.0-M1 breaks RPM deploys
[ https://issues.apache.org/jira/browse/MDEPLOY-244?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16643700#comment-16643700 ] Andrew Lillie commented on MDEPLOY-244: --- [~khmarbaise] I cannot speak for Peter's experience, but for us, 3.0.0-M1 deploys worked for just about every artifact type _except_ RPMs. Assembly files, jars, wars, etc all deployed without issue. > maven deploy plugin 3.0.0-M1 breaks RPM deploys > --- > > Key: MDEPLOY-244 > URL: https://issues.apache.org/jira/browse/MDEPLOY-244 > Project: Maven Deploy Plugin > Issue Type: Bug > Components: deploy:deploy-file >Affects Versions: 3.0.0-M1 >Reporter: William So >Priority: Critical > Attachments: test-maven-deploy.zip > > > After upgrading to maven deploy plugin to 3.0.0-M1, our Maven Builds that > uploads an RPM artifact broke. All other artifacts, like zips, pom, jar, > etc.. was able to upload without problems. But as soon as the build tried > to upload an RPM the upload threw an 401 Error: > > [Continue Pipeline] [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-deploy-plugin:3.0.0-M1:deploy (default-deploy) > on project company-fancyname-atg-apptype-ibm-qa4: ArtifactDeployerException: > Failed to deploy artifacts: Could not transfer artifact > com.sephops.fancyname:company-fancyname-atg-apptype-ibm-qa4:rpm:ProjectName-20181001.061415-35 > from/to company-snapshot-yum::default > (http://artifactory.com/artifactory/company-snapshot-yum-local): Failed to > transfer file: > http://artifactory.com/artifactory/company-snapshot-yum-local/com/sephops/fancyname/company-fancyname-atg-apptype-ibm-qa4/ProjectName-SNAPSHOT/company-fancyname-atg-apptype-ibm-qa4-ProjectName-20181001.061415-35.rpm. > Return code is: 401, ReasonPhrase: Unauthorized. -> [Help 1] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MDEPLOY-244) maven deploy plugin 3.0.0-M1 breaks RPM deploys
[ https://issues.apache.org/jira/browse/MDEPLOY-244?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16643611#comment-16643611 ] Karl Heinz Marbaise commented on MDEPLOY-244: - [~peterlynch] Can you get more detailed information of them..if this is limited to non default artifacts like RPM or is this more general? > maven deploy plugin 3.0.0-M1 breaks RPM deploys > --- > > Key: MDEPLOY-244 > URL: https://issues.apache.org/jira/browse/MDEPLOY-244 > Project: Maven Deploy Plugin > Issue Type: Bug > Components: deploy:deploy-file >Affects Versions: 3.0.0-M1 >Reporter: William So >Priority: Critical > Attachments: test-maven-deploy.zip > > > After upgrading to maven deploy plugin to 3.0.0-M1, our Maven Builds that > uploads an RPM artifact broke. All other artifacts, like zips, pom, jar, > etc.. was able to upload without problems. But as soon as the build tried > to upload an RPM the upload threw an 401 Error: > > [Continue Pipeline] [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-deploy-plugin:3.0.0-M1:deploy (default-deploy) > on project company-fancyname-atg-apptype-ibm-qa4: ArtifactDeployerException: > Failed to deploy artifacts: Could not transfer artifact > com.sephops.fancyname:company-fancyname-atg-apptype-ibm-qa4:rpm:ProjectName-20181001.061415-35 > from/to company-snapshot-yum::default > (http://artifactory.com/artifactory/company-snapshot-yum-local): Failed to > transfer file: > http://artifactory.com/artifactory/company-snapshot-yum-local/com/sephops/fancyname/company-fancyname-atg-apptype-ibm-qa4/ProjectName-SNAPSHOT/company-fancyname-atg-apptype-ibm-qa4-ProjectName-20181001.061415-35.rpm. > Return code is: 401, ReasonPhrase: Unauthorized. -> [Help 1] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (MSHARED-763) Include a dependency change detection.
Liwae Lamaa created MSHARED-763: --- Summary: Include a dependency change detection. Key: MSHARED-763 URL: https://issues.apache.org/jira/browse/MSHARED-763 Project: Maven Shared Components Issue Type: Improvement Components: maven-shared-incremental Reporter: Liwae Lamaa Currently, maven incremental compilation does not detect dependency change. Sample scenario: * Project A depends on Project B. * Project B is recompiled. * Project A should detect this change and recompile. (which is not the case currently) * If B recompilation includes changing an interface, we expect A to recompile and fail accordingly. A fix was already performed on *maven-compiler-plugin*, but it was never merged. https://issues.apache.org/jira/browse/MCOMPILER-278 After recent discussion with [~rfscholte], he decided that the fix should rather be in *maven-shared-incremental.* I have performed the implementation for the fix in maven-shared-incremental, and I will be forking the project for that. PS: The change include minor change in the *maven-compiler-plugin* for it to take effect. How should this be approached? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (SUREFIRE-1546) JUnit 5 runner does not honor JUnit 5 display names
[ https://issues.apache.org/jira/browse/SUREFIRE-1546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16643570#comment-16643570 ] Olga Krutova commented on SUREFIRE-1546: Could you please indicate approximate date of the [3.0.0-M1|https://issues.apache.org/jira/issues/?jql=project+%3D+SUREFIRE+AND+fixVersion+%3D+3.0.0-M1] release. > JUnit 5 runner does not honor JUnit 5 display names > --- > > Key: SUREFIRE-1546 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1546 > Project: Maven Surefire > Issue Type: Bug > Components: JUnit 5.x support >Affects Versions: 2.22.0 >Reporter: Romain Manni-Bucau >Assignee: Christian Stein >Priority: Major > Labels: junit5 > Fix For: 3.0.0-M1 > > > JUnit 5 runner should respect the test @DisplayName instead of displaying the > classname if any is defined. Seems last release doesn't support that feature > of JUnit 5 making the console output and reports not the expected ones. > > Origin: https://github.com/junit-team/junit5/issues/990 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MDEPLOY-244) maven deploy plugin 3.0.0-M1 breaks RPM deploys
[ https://issues.apache.org/jira/browse/MDEPLOY-244?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16643455#comment-16643455 ] Peter lynch commented on MDEPLOY-244: - Sonatype has reports from several customers that the 3.0.0-M1 version of the plugin is causing authentication errors as described in this ticket. When those customers downgraded to a previous version of the plugin, the problems were resolved. Sonatype has published an article: https://support.sonatype.com/hc/en-us/articles/360010223594 > maven deploy plugin 3.0.0-M1 breaks RPM deploys > --- > > Key: MDEPLOY-244 > URL: https://issues.apache.org/jira/browse/MDEPLOY-244 > Project: Maven Deploy Plugin > Issue Type: Bug > Components: deploy:deploy-file >Affects Versions: 3.0.0-M1 >Reporter: William So >Priority: Critical > Attachments: test-maven-deploy.zip > > > After upgrading to maven deploy plugin to 3.0.0-M1, our Maven Builds that > uploads an RPM artifact broke. All other artifacts, like zips, pom, jar, > etc.. was able to upload without problems. But as soon as the build tried > to upload an RPM the upload threw an 401 Error: > > [Continue Pipeline] [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-deploy-plugin:3.0.0-M1:deploy (default-deploy) > on project company-fancyname-atg-apptype-ibm-qa4: ArtifactDeployerException: > Failed to deploy artifacts: Could not transfer artifact > com.sephops.fancyname:company-fancyname-atg-apptype-ibm-qa4:rpm:ProjectName-20181001.061415-35 > from/to company-snapshot-yum::default > (http://artifactory.com/artifactory/company-snapshot-yum-local): Failed to > transfer file: > http://artifactory.com/artifactory/company-snapshot-yum-local/com/sephops/fancyname/company-fancyname-atg-apptype-ibm-qa4/ProjectName-SNAPSHOT/company-fancyname-atg-apptype-ibm-qa4-ProjectName-20181001.061415-35.rpm. > Return code is: 401, ReasonPhrase: Unauthorized. -> [Help 1] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (MPLUGIN-340) upgrade Ant version to 1.9.13
[ https://issues.apache.org/jira/browse/MPLUGIN-340?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy (*$^¨%`£) reassigned MPLUGIN-340: -- Assignee: Olivier Lamy (*$^¨%`£) > upgrade Ant version to 1.9.13 > - > > Key: MPLUGIN-340 > URL: https://issues.apache.org/jira/browse/MPLUGIN-340 > Project: Maven Plugin Tools > Issue Type: Dependency upgrade > Components: maven-plugin-tools-ant >Affects Versions: 3.5.2 >Reporter: Hervé Boutemy >Assignee: Olivier Lamy (*$^¨%`£) >Priority: Major > Fix For: 3.6.0 > > > to benefit from > https://github.com/apache/ant/commit/857095da5153fd18504b46f276d84f1e76a66970 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MPLUGIN-340) upgrade Ant version to 1.9.13
[ https://issues.apache.org/jira/browse/MPLUGIN-340?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy (*$^¨%`£) updated MPLUGIN-340: --- Summary: upgrade Ant version to 1.9.13 (was: upgrade Ant version to 1.9.12) > upgrade Ant version to 1.9.13 > - > > Key: MPLUGIN-340 > URL: https://issues.apache.org/jira/browse/MPLUGIN-340 > Project: Maven Plugin Tools > Issue Type: Dependency upgrade > Components: maven-plugin-tools-ant >Affects Versions: 3.5.2 >Reporter: Hervé Boutemy >Priority: Major > Fix For: 3.6.0 > > > to benefit from > https://github.com/apache/ant/commit/857095da5153fd18504b46f276d84f1e76a66970 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MPLUGIN-337) Try to derive JDK requirements also from release parameter
[
https://issues.apache.org/jira/browse/MPLUGIN-337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated MPLUGIN-337:
Summary: Try to derive JDK requirements also from release parameter (was:
Try to derive JDK requirements also from target parameter)
> Try to derive JDK requirements also from release parameter
> --
>
> Key: MPLUGIN-337
> URL: https://issues.apache.org/jira/browse/MPLUGIN-337
> Project: Maven Plugin Tools
> Issue Type: Bug
> Components: Plugin Plugin
>Affects Versions: 3.5.1
>Reporter: Konrad Windszus
>Priority: Major
>
> Currently the JDK requirements are extracted
> (https://github.com/apache/maven-plugin-tools/blob/1087f55e8cdfd8c1fec605a7cb9004efaee4e592/maven-plugin-plugin/src/main/java/org/apache/maven/plugin/plugin/PluginReport.java#L759)
> from either
> # the explicitly set requirement (via plugin configuration parameter)
> # or by evaluating the maven-compiler-plugin's {{target}} parameter
> With Java 9 it is pretty common to use {{release}} instead
> (https://maven.apache.org/plugins/maven-compiler-plugin/compile-mojo.html#release).
> Therefore this parameter should be evaluated as well.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MNG-6438) Continuous Delivery friendly versions do not work on root pom's parent
[
https://issues.apache.org/jira/browse/MNG-6438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16643075#comment-16643075
]
Konrad Windszus commented on MNG-6438:
--
I found a different workaround, but please document this limitation of CI
friendly versions on https://maven.apache.org/maven-ci-friendly.html.
> Continuous Delivery friendly versions do not work on root pom's parent
> --
>
> Key: MNG-6438
> URL: https://issues.apache.org/jira/browse/MNG-6438
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.5.3
> Environment: Apache Maven 3.5.3
> (3383c37e1f9e9b3bc3df5050c29c8aff9f295297; 2018-02-24T20:49:05+01:00)
> Maven home: /usr/local/Cellar/maven/3.5.3/libexec
> Java version: 1.8.0_162, vendor: Oracle Corporation
> Java home:
> /Library/Java/JavaVirtualMachines/jdk1.8.0_162.jdk/Contents/Home/jre
> Default locale: en_DE, platform encoding: UTF-8
> OS name: "mac os x", version: "10.13.5", arch: "x86_64", family: "mac"
>Reporter: Konrad Windszus
>Priority: Major
>
> If I use either {{${revision}}},{{${sha1}}}, or {{${changelist}}} in the root
> pom's parent version it simply does not work, even when the project is
> invoked via
> {{mvn package -Drevision=1.0}} and the according parent is available in
> version {{1.0}} in my Maven repo.
> Instead I get the following error
> {code}
> mvn package -Dsha1=1.0
> [INFO] Scanning for projects...
> Downloading from central:
> https://repo.maven.apache.org/maven2/some/test/myparent/$%7Bsha1%7D/myparent-$%7Bsha1%7D.pom
> [ERROR] [ERROR] Some problems were encountered while processing the POMs:
> [FATAL] Non-resolvable parent POM for some.test:root:[unknown-version]: Could
> not find artifact some.test:myparent:pom:${sha1} in central
> (https://repo.maven.apache.org/maven2) and 'parent.relativePath' points at
> wrong local POM @ line 11, column 13
> @
> [ERROR] The build could not read 1 project -> [Help 1]
> [ERROR]
> [ERROR] The project some.test:root:[unknown-version]
> (/Users/konradwindszus/Downloads/pom.xml) has 1 error
> [ERROR] Non-resolvable parent POM for some.test:root:[unknown-version]:
> Could not find artifact some.test:myparent:pom:${sha1} in central
> (https://repo.maven.apache.org/maven2) and 'parent.relativePath' points at
> wrong local POM @ line 11, column 13 -> [Help 2]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please
> read the following articles:
> [ERROR] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/ProjectBuildingException
> [ERROR] [Help 2]
> http://cwiki.apache.org/confluence/display/MAVEN/UnresolvableModelException
> {code}
> The following minimum pom can be used for testing
> {code}
>
> xmlns="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
>
> some.test
> myparent
>
> ${sha1}
>
> root
>
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MENFORCER-142) Specify enforcer rule in command line without modifying any pom
[ https://issues.apache.org/jira/browse/MENFORCER-142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16643047#comment-16643047 ] ASF GitHub Bot commented on MENFORCER-142: -- aleguerrini commented on issue #36: [MENFORCER-142] documentation - add example for checking rules via cli URL: https://github.com/apache/maven-enforcer/pull/36#issuecomment-428125245 Hi. When this feature could be release on public mvn repo ? Thanks. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Specify enforcer rule in command line without modifying any pom > --- > > Key: MENFORCER-142 > URL: https://issues.apache.org/jira/browse/MENFORCER-142 > Project: Maven Enforcer Plugin > Issue Type: Improvement > Components: Plugin >Reporter: Arnaud Bourrée >Assignee: Karl Heinz Marbaise >Priority: Major > Fix For: 3.0.0 > > > Hello, > How could we specify enforcer:enforce rules from command line? > I want to run command line like following without updating any pom.xml: > mvn enforcer:enforce -Drules=com.acme.UseAcmeParentPom > The goal of this enforcer:enforce rule is to check that Acme's > developers write pom.xml which inherit from acme's parent pom.xml > And because they may not inherit from acme's parent pom.xml, I cannot > specify enforcer rule in. > Regards, > Arnaud. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MENFORCER-142) Specify enforcer rule in command line without modifying any pom
[ https://issues.apache.org/jira/browse/MENFORCER-142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16643048#comment-16643048 ] ASF GitHub Bot commented on MENFORCER-142: -- aleguerrini edited a comment on issue #36: [MENFORCER-142] documentation - add example for checking rules via cli URL: https://github.com/apache/maven-enforcer/pull/36#issuecomment-428125245 Hi. When this feature could be released on the public mvn repo ? Thanks. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Specify enforcer rule in command line without modifying any pom > --- > > Key: MENFORCER-142 > URL: https://issues.apache.org/jira/browse/MENFORCER-142 > Project: Maven Enforcer Plugin > Issue Type: Improvement > Components: Plugin >Reporter: Arnaud Bourrée >Assignee: Karl Heinz Marbaise >Priority: Major > Fix For: 3.0.0 > > > Hello, > How could we specify enforcer:enforce rules from command line? > I want to run command line like following without updating any pom.xml: > mvn enforcer:enforce -Drules=com.acme.UseAcmeParentPom > The goal of this enforcer:enforce rule is to check that Acme's > developers write pom.xml which inherit from acme's parent pom.xml > And because they may not inherit from acme's parent pom.xml, I cannot > specify enforcer rule in. > Regards, > Arnaud. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] aleguerrini commented on issue #36: [MENFORCER-142] documentation - add example for checking rules via cli
aleguerrini commented on issue #36: [MENFORCER-142] documentation - add example for checking rules via cli URL: https://github.com/apache/maven-enforcer/pull/36#issuecomment-428125245 Hi. When this feature could be release on public mvn repo ? Thanks. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] aleguerrini edited a comment on issue #36: [MENFORCER-142] documentation - add example for checking rules via cli
aleguerrini edited a comment on issue #36: [MENFORCER-142] documentation - add example for checking rules via cli URL: https://github.com/apache/maven-enforcer/pull/36#issuecomment-428125245 Hi. When this feature could be released on the public mvn repo ? Thanks. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
