[jira] [Created] (MPLUGINTESTING-53) default-value on mojo parameter of type collection or array effectively make parameter read-only
Konrad Windszus created MPLUGINTESTING-53:
-
Summary: default-value on mojo parameter of type collection or
array effectively make parameter read-only
Key: MPLUGINTESTING-53
URL: https://issues.apache.org/jira/browse/MPLUGINTESTING-53
Project: Maven Plugin Testing
Issue Type: Bug
Components: plugin-testing-harness
Affects Versions: 3.3.0
Reporter: Konrad Windszus
The tests leveraging {{maven-plugin-testing-harness}} are suffering from the
problem described in https://issues.apache.org/jira/browse/MNG-5440. That
should be fixed by upgrading the sisu plexus dependency to at least 0.3.2.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (MNG-6267) Support resolving "~" in values given to CLI Option "-s"
Konrad Windszus created MNG-6267:
Summary: Support resolving "~" in values given to CLI Option "-s"
Key: MNG-6267
URL: https://issues.apache.org/jira/browse/MNG-6267
Project: Maven
Issue Type: Improvement
Reporter: Konrad Windszus
Currently relative filenames given in CLI option "-s" are assumed to be
relative to the base directory. It would be nice to also support referencing
files below the user's home directory by leveraging the placeholder "~". This
would be especially useful with {{mvn/maven.config}} (MNG-5767).
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (MNG-6267) Support resolving "~" in values given to CLI Option "-s"
[
https://issues.apache.org/jira/browse/MNG-6267?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated MNG-6267:
-
Affects Version/s: 3.5.0
Component/s: Command Line
> Support resolving "~" in values given to CLI Option "-s"
>
>
> Key: MNG-6267
> URL: https://issues.apache.org/jira/browse/MNG-6267
> Project: Maven
> Issue Type: Improvement
> Components: Command Line
>Affects Versions: 3.5.0
>Reporter: Konrad Windszus
>
> Currently relative filenames given in CLI option "-s" are assumed to be
> relative to the base directory. It would be nice to also support referencing
> files below the user's home directory by leveraging the placeholder "~". This
> would be especially useful with {{mvn/maven.config}} (MNG-5767).
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MNG-6267) Support resolving "~" in values given to CLI Option "-s"
[
https://issues.apache.org/jira/browse/MNG-6267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16112327#comment-16112327
]
Konrad Windszus commented on MNG-6267:
--
Ok, I see your point and agree. Feel free to close as won't fix.
> Support resolving "~" in values given to CLI Option "-s"
>
>
> Key: MNG-6267
> URL: https://issues.apache.org/jira/browse/MNG-6267
> Project: Maven
> Issue Type: Improvement
> Components: Command Line
>Affects Versions: 3.5.0
>Reporter: Konrad Windszus
>
> Currently relative filenames given in CLI option "-s" are assumed to be
> relative to the base directory. It would be nice to also support referencing
> files below the user's home directory by leveraging the placeholder "~". This
> would be especially useful with {{mvn/maven.config}} (MNG-5767).
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (SCM-845) Maven Release Plugin releases SNAPSHOT instead of STABLE version (jgit)
[ https://issues.apache.org/jira/browse/SCM-845?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15989839#comment-15989839 ] Konrad Windszus edited comment on SCM-845 at 10/4/17 4:49 PM: -- Actually the patch for SCM-807 also fixes this issue here for me. was (Author: kwin): Could also be related to SCM-807. > Maven Release Plugin releases SNAPSHOT instead of STABLE version (jgit) > --- > > Key: SCM-845 > URL: https://issues.apache.org/jira/browse/SCM-845 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-provider-jgit >Affects Versions: 1.9.5 >Reporter: Archimedes Trajano > > I just tried to do a release with the exact scenario as SCM-740 and had the > same result. The SCM-740 provided a fix for gitexe which I verified works > when I switched to that provider, but jgit has the same issue -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (SCM-852) maven-scm-plugin:check-local-modification should optionally check for unpushed commits
Konrad Windszus created SCM-852:
---
Summary: maven-scm-plugin:check-local-modification should
optionally check for unpushed commits
Key: SCM-852
URL: https://issues.apache.org/jira/browse/SCM-852
Project: Maven SCM
Issue Type: Bug
Components: maven-plugin
Affects Versions: 1.9.5
Reporter: Konrad Windszus
Currently the goal {{check-local-modification}} only checks for local changes.
But with distributed SCM systems it is very often also desirable if all local
commits have been pushed to the origin as well. It would be good to optionally
check for unpushed commits or not yet fetched commits with that goal.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (SCM-852) maven-scm-plugin:check-local-modification should optionally check for unpushed commits
[
https://issues.apache.org/jira/browse/SCM-852?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated SCM-852:
Description: Currently the goal {{check-local-modification}} only checks
for local changes. But with distributed SCM systems it is very often also
desirable to enforce that all local commits have been pushed to the origin as
well. It would be good to optionally check for unpushed commits or not yet
fetched commits with that goal. (was: Currently the goal
{{check-local-modification}} only checks for local changes. But with
distributed SCM systems it is very often also desirable if all local commits
have been pushed to the origin as well. It would be good to optionally check
for unpushed commits or not yet fetched commits with that goal.)
> maven-scm-plugin:check-local-modification should optionally check for
> unpushed commits
> --
>
> Key: SCM-852
> URL: https://issues.apache.org/jira/browse/SCM-852
> Project: Maven SCM
> Issue Type: Bug
> Components: maven-plugin
>Affects Versions: 1.9.5
>Reporter: Konrad Windszus
>
> Currently the goal {{check-local-modification}} only checks for local
> changes. But with distributed SCM systems it is very often also desirable to
> enforce that all local commits have been pushed to the origin as well. It
> would be good to optionally check for unpushed commits or not yet fetched
> commits with that goal.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (MNG-6303) maven.config should allow to resolve environment variables
Konrad Windszus created MNG-6303:
Summary: maven.config should allow to resolve environment variables
Key: MNG-6303
URL: https://issues.apache.org/jira/browse/MNG-6303
Project: Maven
Issue Type: Bug
Components: Bootstrap & Build
Affects Versions: 3.5.0
Reporter: Konrad Windszus
With the mechanism of having project-specific maven options being specified in
{{.mvn/maven.config}} and {{.mvn/jvm.config}} (MNG-6267) it is often handy to
share those settings among multiple developers (i.e. via maintaining it via the
SCM). Unfortunately the mechanism does not support resolving environment
variables, which makes it hard to deal with user-specific directories or
settings. Please support resolving environment variables through a special
pattern like {{$ENV_NAME}}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (MNG-6303) .mvn/jvm.config should allow to resolve environment variables
[
https://issues.apache.org/jira/browse/MNG-6303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated MNG-6303:
-
Summary: .mvn/jvm.config should allow to resolve environment variables
(was: maven.config should allow to resolve environment variables)
> .mvn/jvm.config should allow to resolve environment variables
> -
>
> Key: MNG-6303
> URL: https://issues.apache.org/jira/browse/MNG-6303
> Project: Maven
> Issue Type: Bug
> Components: Bootstrap & Build
>Affects Versions: 3.5.0
>Reporter: Konrad Windszus
>
> With the mechanism of having project-specific maven options being specified
> in {{.mvn/maven.config}} and {{.mvn/jvm.config}} (MNG-6267) it is often handy
> to share those settings among multiple developers (i.e. via maintaining it
> via the SCM). Unfortunately the mechanism does not support resolving
> environment variables, which makes it hard to deal with user-specific
> directories or settings. Please support resolving environment variables
> through a special pattern like {{$ENV_NAME}}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MNG-6303) .mvn/jvm.config should allow to resolve environment variables
[
https://issues.apache.org/jira/browse/MNG-6303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16240516#comment-16240516
]
Konrad Windszus commented on MNG-6303:
--
A potential fix could be to replace
https://github.com/apache/maven/blob/master/apache-maven/src/bin/mvn#L170 by
{code}
cat "$1" | echo | tr -s '\n' ' '
{code}
That would allow basically every bourne shell feature to be used within at
least the {{.mvn/jvm.config}}.
> .mvn/jvm.config should allow to resolve environment variables
> -
>
> Key: MNG-6303
> URL: https://issues.apache.org/jira/browse/MNG-6303
> Project: Maven
> Issue Type: Bug
> Components: Bootstrap & Build
>Affects Versions: 3.5.0
>Reporter: Konrad Windszus
>
> With the mechanism of having project-specific maven options being specified
> in {{.mvn/maven.config}} and {{.mvn/jvm.config}} (MNG-6267) it is often handy
> to share those settings among multiple developers (i.e. via maintaining it
> via the SCM). Unfortunately the mechanism does not support resolving
> environment variables, which makes it hard to deal with user-specific
> directories or settings. Please support resolving environment variables
> through a special pattern like {{$ENV_NAME}}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (MNG-6303) .mvn/jvm.config should allow to resolve environment variables
[
https://issues.apache.org/jira/browse/MNG-6303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16240516#comment-16240516
]
Konrad Windszus edited comment on MNG-6303 at 11/7/17 9:31 AM:
---
A potential fix could be to replace
https://github.com/apache/maven/blob/master/apache-maven/src/bin/mvn#L170 by
{code}
cat "$1" | echo | tr -s '\n' ' '
{code}
That would allow basically every bourne shell feature to be used within at
least the {{.mvn/jvm.config}}. Of course an according fix need to be
implemented for Windows.
was (Author: kwin):
A potential fix could be to replace
https://github.com/apache/maven/blob/master/apache-maven/src/bin/mvn#L170 by
{code}
cat "$1" | echo | tr -s '\n' ' '
{code}
That would allow basically every bourne shell feature to be used within at
least the {{.mvn/jvm.config}}.
> .mvn/jvm.config should allow to resolve environment variables
> -
>
> Key: MNG-6303
> URL: https://issues.apache.org/jira/browse/MNG-6303
> Project: Maven
> Issue Type: Bug
> Components: Bootstrap & Build
>Affects Versions: 3.5.0
>Reporter: Konrad Windszus
>
> With the mechanism of having project-specific maven options being specified
> in {{.mvn/maven.config}} and {{.mvn/jvm.config}} (MNG-6267) it is often handy
> to share those settings among multiple developers (i.e. via maintaining it
> via the SCM). Unfortunately the mechanism does not support resolving
> environment variables, which makes it hard to deal with user-specific
> directories or settings. Please support resolving environment variables
> through a special pattern like {{$ENV_NAME}}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (MENFORCER-288) RequireJavaVersion: Support new Java 9 versioning schema even for older Java versions
[
https://issues.apache.org/jira/browse/MENFORCER-288?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated MENFORCER-288:
--
Description:
Although with MENFORCER-274 it is now possible to specify
{code}
9
{code}
it is still not possible to refer to older java versions without the leadering
{{1}}.
So e.g. this one does not work
{code}
6
{code}
This would be very handy as with JDK 9 you specify e.g. release only without
the preceeding {{1}} (compare with
https://docs.oracle.com/javase/9/tools/javac.htm#GUID-AEEC9F07-CB49-4E96-8BC7-BCC2C7F725C9__GUID-D343F6B4-3FDD-43A8-AD24-43DD70214471).
As it is very common to reuse the same Maven property value for enforcing the
minimum java version as well as for specifying the release of the maven
compiler plugin it would be nice, if both support the same version range.
To still be backwards compatible I would suggest that in case of 6,7,8 given as
a value, the {{1.}} is implicitly prepended by the {{maven-enforcer-plugin}}.
was:
Although with MENFORCER-247 it is now possible to specify
{code}
9
{code}
it is still not possible to refer to older java versions without the leadering
{{1}}.
So e.g. this one does not work
{code}
6
{code}
This would be very handy as with JDK 9 you specify e.g. release only without
the preceeding {{1}} (compare with
https://docs.oracle.com/javase/9/tools/javac.htm#GUID-AEEC9F07-CB49-4E96-8BC7-BCC2C7F725C9__GUID-D343F6B4-3FDD-43A8-AD24-43DD70214471).
As it is very common to reuse the same Maven property value for enforcing the
minimum java version as well as for specifying the release of the maven
compiler plugin it would be nice, if both support the same version range.
To still be backwards compatible I would suggest that in case of 6,7,8 given as
a value, the {{1.}} is implicitly prepended by the {{maven-enforcer-plugin}}.
> RequireJavaVersion: Support new Java 9 versioning schema even for older Java
> versions
> -
>
> Key: MENFORCER-288
> URL: https://issues.apache.org/jira/browse/MENFORCER-288
> Project: Maven Enforcer Plugin
> Issue Type: Improvement
> Components: Standard Rules
>Affects Versions: 3.0.0-M1
>Reporter: Konrad Windszus
>
> Although with MENFORCER-274 it is now possible to specify
> {code}
>
> 9
>
> {code}
> it is still not possible to refer to older java versions without the
> leadering {{1}}.
> So e.g. this one does not work
> {code}
>
> 6
>
> {code}
> This would be very handy as with JDK 9 you specify e.g. release only without
> the preceeding {{1}} (compare with
> https://docs.oracle.com/javase/9/tools/javac.htm#GUID-AEEC9F07-CB49-4E96-8BC7-BCC2C7F725C9__GUID-D343F6B4-3FDD-43A8-AD24-43DD70214471).
> As it is very common to reuse the same Maven property value for enforcing
> the minimum java version as well as for specifying the release of the maven
> compiler plugin it would be nice, if both support the same version range.
> To still be backwards compatible I would suggest that in case of 6,7,8 given
> as a value, the {{1.}} is implicitly prepended by the
> {{maven-enforcer-plugin}}.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (MENFORCER-288) RequireJavaVersion: Support new Java 9 versioning schema even for older Java versions
Konrad Windszus created MENFORCER-288:
-
Summary: RequireJavaVersion: Support new Java 9 versioning schema
even for older Java versions
Key: MENFORCER-288
URL: https://issues.apache.org/jira/browse/MENFORCER-288
Project: Maven Enforcer Plugin
Issue Type: Improvement
Components: Standard Rules
Affects Versions: 3.0.0-M1
Reporter: Konrad Windszus
Although with MENFORCER-247 it is now possible to specify
{code}
9
{code}
it is still not possible to refer to older java versions without the leadering
{{1}}.
So e.g. this one does not work
{code}
6
{code}
This would be very handy as with JDK 9 you specify e.g. release only without
the preceeding {{1}} (compare with
https://docs.oracle.com/javase/9/tools/javac.htm#GUID-AEEC9F07-CB49-4E96-8BC7-BCC2C7F725C9__GUID-D343F6B4-3FDD-43A8-AD24-43DD70214471).
As it is very common to reuse the same Maven property value for enforcing the
minimum java version as well as for specifying the release of the maven
compiler plugin it would be nice, if both support the same version range.
To still be backwards compatible I would suggest that in case of 6,7,8 given as
a value, the {{1.}} is implicitly prepended by the {{maven-enforcer-plugin}}.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (MENFORCER-288) RequireJavaVersion: Support new Java 9 versioning schema even for older Java versions
[
https://issues.apache.org/jira/browse/MENFORCER-288?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated MENFORCER-288:
--
Description:
Although with MENFORCER-274 it is now possible to specify
{code}
9
{code}
it is still not possible to refer to older java versions without the leadering
{{1}}.
So e.g. this one does not work
{code}
6
{code}
This would be very handy as with JDK 9 you specify e.g. release only without
the preceeding {{1}} (compare with
https://docs.oracle.com/javase/9/tools/javac.htm#GUID-AEEC9F07-CB49-4E96-8BC7-BCC2C7F725C9__GUID-D343F6B4-3FDD-43A8-AD24-43DD70214471).
As it is very common to reuse the same Maven property value for enforcing the
minimum java version with the maven-enforcer-plugin as well as for specifying
the release/source/target of the maven compiler plugin it would be nice, if
both support the same version range.
To still be backwards compatible I would suggest that in case of 6,7,8 given as
a value, the {{1.}} is implicitly prepended by the {{maven-enforcer-plugin}}.
was:
Although with MENFORCER-274 it is now possible to specify
{code}
9
{code}
it is still not possible to refer to older java versions without the leadering
{{1}}.
So e.g. this one does not work
{code}
6
{code}
This would be very handy as with JDK 9 you specify e.g. release only without
the preceeding {{1}} (compare with
https://docs.oracle.com/javase/9/tools/javac.htm#GUID-AEEC9F07-CB49-4E96-8BC7-BCC2C7F725C9__GUID-D343F6B4-3FDD-43A8-AD24-43DD70214471).
As it is very common to reuse the same Maven property value for enforcing the
minimum java version as well as for specifying the release of the maven
compiler plugin it would be nice, if both support the same version range.
To still be backwards compatible I would suggest that in case of 6,7,8 given as
a value, the {{1.}} is implicitly prepended by the {{maven-enforcer-plugin}}.
> RequireJavaVersion: Support new Java 9 versioning schema even for older Java
> versions
> -
>
> Key: MENFORCER-288
> URL: https://issues.apache.org/jira/browse/MENFORCER-288
> Project: Maven Enforcer Plugin
> Issue Type: Improvement
> Components: Standard Rules
>Affects Versions: 3.0.0-M1
>Reporter: Konrad Windszus
>
> Although with MENFORCER-274 it is now possible to specify
> {code}
>
> 9
>
> {code}
> it is still not possible to refer to older java versions without the
> leadering {{1}}.
> So e.g. this one does not work
> {code}
>
> 6
>
> {code}
> This would be very handy as with JDK 9 you specify e.g. release only without
> the preceeding {{1}} (compare with
> https://docs.oracle.com/javase/9/tools/javac.htm#GUID-AEEC9F07-CB49-4E96-8BC7-BCC2C7F725C9__GUID-D343F6B4-3FDD-43A8-AD24-43DD70214471).
> As it is very common to reuse the same Maven property value for enforcing
> the minimum java version with the maven-enforcer-plugin as well as for
> specifying the release/source/target of the maven compiler plugin it would be
> nice, if both support the same version range.
> To still be backwards compatible I would suggest that in case of 6,7,8 given
> as a value, the {{1.}} is implicitly prepended by the
> {{maven-enforcer-plugin}}.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (MENFORCER-288) RequireJavaVersion: Support new Java 9 versioning schema even for older Java versions
[
https://issues.apache.org/jira/browse/MENFORCER-288?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated MENFORCER-288:
--
Description:
Although with MENFORCER-274 it is now possible to specify
{code}
9
{code}
it is still not possible to refer to older java versions without the leadering
{{1}}.
So e.g. this one does not work
{code}
6
{code}
This would be very handy as with JDK 9 you specify e.g. release only without
the preceeding {{1.}} (compare with
https://docs.oracle.com/javase/9/tools/javac.htm#GUID-AEEC9F07-CB49-4E96-8BC7-BCC2C7F725C9__GUID-D343F6B4-3FDD-43A8-AD24-43DD70214471).
As it is very common to reuse the same Maven property value for enforcing the
minimum java version with the maven-enforcer-plugin as well as for specifying
the release/source/target of the {{maven-compiler-plugin}} it would be nice, if
both support the same version range.
To still be backwards compatible I would suggest that in case of 6,7,8 given as
a value, the {{1.}} is implicitly prepended by the {{maven-enforcer-plugin}}.
was:
Although with MENFORCER-274 it is now possible to specify
{code}
9
{code}
it is still not possible to refer to older java versions without the leadering
{{1}}.
So e.g. this one does not work
{code}
6
{code}
This would be very handy as with JDK 9 you specify e.g. release only without
the preceeding {{1}} (compare with
https://docs.oracle.com/javase/9/tools/javac.htm#GUID-AEEC9F07-CB49-4E96-8BC7-BCC2C7F725C9__GUID-D343F6B4-3FDD-43A8-AD24-43DD70214471).
As it is very common to reuse the same Maven property value for enforcing the
minimum java version with the maven-enforcer-plugin as well as for specifying
the release/source/target of the maven compiler plugin it would be nice, if
both support the same version range.
To still be backwards compatible I would suggest that in case of 6,7,8 given as
a value, the {{1.}} is implicitly prepended by the {{maven-enforcer-plugin}}.
> RequireJavaVersion: Support new Java 9 versioning schema even for older Java
> versions
> -
>
> Key: MENFORCER-288
> URL: https://issues.apache.org/jira/browse/MENFORCER-288
> Project: Maven Enforcer Plugin
> Issue Type: Improvement
> Components: Standard Rules
>Affects Versions: 3.0.0-M1
>Reporter: Konrad Windszus
>
> Although with MENFORCER-274 it is now possible to specify
> {code}
>
> 9
>
> {code}
> it is still not possible to refer to older java versions without the
> leadering {{1}}.
> So e.g. this one does not work
> {code}
>
> 6
>
> {code}
> This would be very handy as with JDK 9 you specify e.g. release only without
> the preceeding {{1.}} (compare with
> https://docs.oracle.com/javase/9/tools/javac.htm#GUID-AEEC9F07-CB49-4E96-8BC7-BCC2C7F725C9__GUID-D343F6B4-3FDD-43A8-AD24-43DD70214471).
> As it is very common to reuse the same Maven property value for enforcing
> the minimum java version with the maven-enforcer-plugin as well as for
> specifying the release/source/target of the {{maven-compiler-plugin}} it
> would be nice, if both support the same version range.
> To still be backwards compatible I would suggest that in case of 6,7,8 given
> as a value, the {{1.}} is implicitly prepended by the
> {{maven-enforcer-plugin}}.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (MENFORCER-288) RequireJavaVersion: Support new Java 9 versioning schema even for older Java versions
[
https://issues.apache.org/jira/browse/MENFORCER-288?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated MENFORCER-288:
--
Description:
Although with MENFORCER-274 it is now possible to specify
{code}
9
{code}
it is still not possible to refer to older java versions without the leadering
{{1.}}.
So e.g. this one does not work
{code}
6
{code}
This would be very handy as with JDK 9 you specify e.g. release only without
the preceeding {{1.}} (compare with
https://docs.oracle.com/javase/9/tools/javac.htm#GUID-AEEC9F07-CB49-4E96-8BC7-BCC2C7F725C9__GUID-D343F6B4-3FDD-43A8-AD24-43DD70214471).
As it is very common to reuse the same Maven property value for enforcing the
minimum java version with the {{maven-enforcer-plugin}} as well as for
specifying the release/source/target of the {{maven-compiler-plugin}} it would
be nice, if both support the same version range.
To still be backwards compatible I would suggest that in case of 6,7,8 given as
a value, the {{1.}} is implicitly prepended by the {{maven-enforcer-plugin}}.
was:
Although with MENFORCER-274 it is now possible to specify
{code}
9
{code}
it is still not possible to refer to older java versions without the leadering
{{1}}.
So e.g. this one does not work
{code}
6
{code}
This would be very handy as with JDK 9 you specify e.g. release only without
the preceeding {{1.}} (compare with
https://docs.oracle.com/javase/9/tools/javac.htm#GUID-AEEC9F07-CB49-4E96-8BC7-BCC2C7F725C9__GUID-D343F6B4-3FDD-43A8-AD24-43DD70214471).
As it is very common to reuse the same Maven property value for enforcing the
minimum java version with the maven-enforcer-plugin as well as for specifying
the release/source/target of the {{maven-compiler-plugin}} it would be nice, if
both support the same version range.
To still be backwards compatible I would suggest that in case of 6,7,8 given as
a value, the {{1.}} is implicitly prepended by the {{maven-enforcer-plugin}}.
> RequireJavaVersion: Support new Java 9 versioning schema even for older Java
> versions
> -
>
> Key: MENFORCER-288
> URL: https://issues.apache.org/jira/browse/MENFORCER-288
> Project: Maven Enforcer Plugin
> Issue Type: Improvement
> Components: Standard Rules
>Affects Versions: 3.0.0-M1
>Reporter: Konrad Windszus
>
> Although with MENFORCER-274 it is now possible to specify
> {code}
>
> 9
>
> {code}
> it is still not possible to refer to older java versions without the
> leadering {{1.}}.
> So e.g. this one does not work
> {code}
>
> 6
>
> {code}
> This would be very handy as with JDK 9 you specify e.g. release only without
> the preceeding {{1.}} (compare with
> https://docs.oracle.com/javase/9/tools/javac.htm#GUID-AEEC9F07-CB49-4E96-8BC7-BCC2C7F725C9__GUID-D343F6B4-3FDD-43A8-AD24-43DD70214471).
> As it is very common to reuse the same Maven property value for enforcing
> the minimum java version with the {{maven-enforcer-plugin}} as well as for
> specifying the release/source/target of the {{maven-compiler-plugin}} it
> would be nice, if both support the same version range.
> To still be backwards compatible I would suggest that in case of 6,7,8 given
> as a value, the {{1.}} is implicitly prepended by the
> {{maven-enforcer-plugin}}.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (MNG-6348) Clarify Maven Plugin Configuration Locations and their Order of Precendence
Konrad Windszus created MNG-6348:
Summary: Clarify Maven Plugin Configuration Locations and their
Order of Precendence
Key: MNG-6348
URL: https://issues.apache.org/jira/browse/MNG-6348
Project: Maven
Issue Type: Improvement
Components: Documentation: Guides
Reporter: Konrad Windszus
There are multiple locations in the pom where you can configure build plugins,
namely
# PluginManagement -> Global Configuration
# PluginManagement -> Execution Configuration
# Plugins -> Global Configuration
# Plugins -> Execution Configuration
Those locations should all be listed in
https://maven.apache.org/guides/mini/guide-configuring-plugins.html#Configuring_Build_Plugins
and the order or precedence should be explicitly listed there.
Is the order given above correct at all, meaning that setting {{param1}} in 4.
will overwrite the configuration of {{param1}} in 1., 2. or 3.?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (MJAVADOC-513) Aggregate: make order of classpath entries predictable
Konrad Windszus created MJAVADOC-513:
Summary: Aggregate: make order of classpath entries predictable
Key: MJAVADOC-513
URL: https://issues.apache.org/jira/browse/MJAVADOC-513
Project: Maven Javadoc Plugin
Issue Type: Improvement
Components: javadoc
Affects Versions: 3.0.0
Reporter: Konrad Windszus
The order of the classpath entries being generated in
{{AbstractJavadocMojo.getPathElements()}}
(https://github.com/apache/maven-javadoc-plugin/blob/12dbbde29cf6277ca311cb8afffdf02dbfe0c9b4/src/main/java/org/apache/maven/plugins/javadoc/AbstractJavadocMojo.java#L2601)
is internally relying on a {{HashMap}} for the compile time artifacts. That is
an issue if the classpath is not 100% clean (i.e. the same package is exported
by multiple artifacts) because then the success depends on the order which is
not predicable for regular {{HashMaps}}. Unclean classpaths are unfortunately
pretty common in reality.
To make builds more reliable please use a {{LinkedHashMap}} instead as that
will keep the insertion order.
Also since elements being returned first have a higher precedence the ones
being maintained via {{additionalDependencies}} should be added first (after
the module's target directory but before the compileArtifacts) to allow to
enforce usage of a certain module for dedicated classes.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MNG-6303) .mvn/jvm.config should allow to resolve environment variables
[
https://issues.apache.org/jira/browse/MNG-6303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16871082#comment-16871082
]
Konrad Windszus commented on MNG-6303:
--
[~breun] Thanks for the hint. Since this requirement is broader (i.e. not
limited to a custom settings.xml filename) I think this is the more relevant
issue. Once this is solved, this can be used to achieve the requirement from
MNG-5659 as well.
> .mvn/jvm.config should allow to resolve environment variables
> -
>
> Key: MNG-6303
> URL: https://issues.apache.org/jira/browse/MNG-6303
> Project: Maven
> Issue Type: Bug
> Components: Bootstrap & Build
>Affects Versions: 3.5.0
>Reporter: Konrad Windszus
>Priority: Major
>
> With the mechanism of having project-specific maven options being specified
> in {{.mvn/maven.config}} and {{.mvn/jvm.config}} (MNG-6267) it is often handy
> to share those settings among multiple developers (i.e. via maintaining it
> via the SCM). Unfortunately the mechanism does not support resolving
> environment variables, which makes it hard to deal with user-specific
> directories or settings. Please support resolving environment variables
> through a special pattern like {{$ENV_NAME}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MNG-5659) Project specific settings.xml
[
https://issues.apache.org/jira/browse/MNG-5659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16871085#comment-16871085
]
Konrad Windszus commented on MNG-5659:
--
Once there is environment variable support (tracked in MNG-6303) with an
environment variable containing the path of the {{.mvn}} directory, that
approach can be used to solve this requirement as well.
> Project specific settings.xml
> -
>
> Key: MNG-5659
> URL: https://issues.apache.org/jira/browse/MNG-5659
> Project: Maven
> Issue Type: New Feature
> Components: FDPFC
>Reporter: Joachim Van der Auwera
>Priority: Major
> Fix For: Issues to be reviewed for 4.x
>
> Attachments: mvn.patch
>
>
> It would be useful to have a settings.xml file next to the project pom that
> could contain project specific settings. For example, when switching between
> projects it is sometimes necessary to also change the location of the local
> repository, or use a different set of repositories and/or mirror settings for
> each project.
> If a settings.xml file could be included with a project checkout, then the
> repositories needed for the build could be included (instead of putting them
> in the pom) along with any other project specific settings.
> The tricky part is intelligently handling multi-module projects. For a
> multi-module project I don't want to include a separate settings.xml file for
> each directory. So Maven could recursively check each parent directory until
> it either (1) finds a settings.xml, (2) finds a directory with no pom.xml, or
> (3) finds the root directory.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SCM-883) ScmFileSet DEFAULT_EXCLUDES too restrictive
[ https://issues.apache.org/jira/browse/SCM-883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16926651#comment-16926651 ] Konrad Windszus commented on SCM-883: - Why is changing the default excludes problematic? I guess including .gitignore in the default excludes is never intended! > ScmFileSet DEFAULT_EXCLUDES too restrictive > --- > > Key: SCM-883 > URL: https://issues.apache.org/jira/browse/SCM-883 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-api >Affects Versions: 1.9.5 >Reporter: Fabian Köntopp >Priority: Minor > > We are trying to automate a process in which a default *.gitignore* file > *only* (ignoring the current state of the repository) is added to a > repository at the root level. Because of the DEFAULT_EXCLUDES in the > ScmFileSet-Class this is impossible because .gitignore is listed there and > the default excludes are always added to the final exlude list. > In my opinion the .gitignore file should not be listed there because such > files are part of a git repository. At least it should be possible to > override the excludes completely without the DEFAULT_EXCLUDES always being > added. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Comment Edited] (SCM-883) ScmFileSet DEFAULT_EXCLUDES too restrictive
[ https://issues.apache.org/jira/browse/SCM-883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16926651#comment-16926651 ] Konrad Windszus edited comment on SCM-883 at 9/10/19 1:44 PM: -- Why is changing the default excludes problematic? I guess including .gitignore in the default excludes is never intended! I opened https://github.com/codehaus-plexus/plexus-utils/issues/71 to track that. was (Author: kwin): Why is changing the default excludes problematic? I guess including .gitignore in the default excludes is never intended! > ScmFileSet DEFAULT_EXCLUDES too restrictive > --- > > Key: SCM-883 > URL: https://issues.apache.org/jira/browse/SCM-883 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-api >Affects Versions: 1.9.5 >Reporter: Fabian Köntopp >Priority: Minor > > We are trying to automate a process in which a default *.gitignore* file > *only* (ignoring the current state of the repository) is added to a > repository at the root level. Because of the DEFAULT_EXCLUDES in the > ScmFileSet-Class this is impossible because .gitignore is listed there and > the default excludes are always added to the final exlude list. > In my opinion the .gitignore file should not be listed there because such > files are part of a git repository. At least it should be possible to > override the excludes completely without the DEFAULT_EXCLUDES always being > added. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Created] (MCOMPILER-404) Update default source/target from 1.6 to 1.7
Konrad Windszus created MCOMPILER-404: - Summary: Update default source/target from 1.6 to 1.7 Key: MCOMPILER-404 URL: https://issues.apache.org/jira/browse/MCOMPILER-404 Project: Maven Compiler Plugin Issue Type: Improvement Affects Versions: 3.8.1 Reporter: Konrad Windszus Similar to what was done in MCOMPILER-335 the default should now be 1.7, as that is the oldest version being supported by javac in Java 12 and Java 13 (https://docs.oracle.com/en/java/javase/12/tools/javac.html#GUID-AEEC9F07-CB49-4E96-8BC7-BCC2C7F725C9). Otherwise compiling sources with Maven on Java 12+ will lead to errors in case no explicit source/target/release is set. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MCOMPILER-404) Update default source/target from 1.6 to 1.7
[ https://issues.apache.org/jira/browse/MCOMPILER-404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Windszus updated MCOMPILER-404: -- Description: Similar to what was done in MCOMPILER-335 the default should now be 1.7, as that is the oldest version being supported by javac in Java 12 and Java 13 (https://docs.oracle.com/en/java/javase/12/tools/javac.html#GUID-AEEC9F07-CB49-4E96-8BC7-BCC2C7F725C9__GUID-D343F6B4-3FDD-43A8-AD24-43DD70214471). Otherwise compiling sources with Maven on Java 12+ will lead to errors in case no explicit source/target/release is set. was: Similar to what was done in MCOMPILER-335 the default should now be 1.7, as that is the oldest version being supported by javac in Java 12 and Java 13 (https://docs.oracle.com/en/java/javase/12/tools/javac.html#GUID-AEEC9F07-CB49-4E96-8BC7-BCC2C7F725C9). Otherwise compiling sources with Maven on Java 12+ will lead to errors in case no explicit source/target/release is set. > Update default source/target from 1.6 to 1.7 > > > Key: MCOMPILER-404 > URL: https://issues.apache.org/jira/browse/MCOMPILER-404 > Project: Maven Compiler Plugin > Issue Type: Improvement >Affects Versions: 3.8.1 >Reporter: Konrad Windszus >Priority: Major > > Similar to what was done in MCOMPILER-335 the default should now be 1.7, as > that is the oldest version being supported by javac in Java 12 and Java 13 > (https://docs.oracle.com/en/java/javase/12/tools/javac.html#GUID-AEEC9F07-CB49-4E96-8BC7-BCC2C7F725C9__GUID-D343F6B4-3FDD-43A8-AD24-43DD70214471). > Otherwise compiling sources with Maven on Java 12+ will lead to errors in > case no explicit source/target/release is set. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MCOMPILER-404) Update default source/target from 1.6 to 1.7
[ https://issues.apache.org/jira/browse/MCOMPILER-404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16985889#comment-16985889 ] Konrad Windszus commented on MCOMPILER-404: --- [~michael-o] When do you want to update the default, or do you want to stick with Java 6 forever? > Update default source/target from 1.6 to 1.7 > > > Key: MCOMPILER-404 > URL: https://issues.apache.org/jira/browse/MCOMPILER-404 > Project: Maven Compiler Plugin > Issue Type: Improvement >Affects Versions: 3.8.1 >Reporter: Konrad Windszus >Priority: Major > > Similar to what was done in MCOMPILER-335 the default should now be 1.7, as > that is the oldest version being supported by javac in Java 12 and Java 13 > (https://docs.oracle.com/en/java/javase/12/tools/javac.html#GUID-AEEC9F07-CB49-4E96-8BC7-BCC2C7F725C9__GUID-D343F6B4-3FDD-43A8-AD24-43DD70214471). > Otherwise compiling sources with Maven on Java 12+ will lead to errors in > case no explicit source/target/release is set. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (MCOMPILER-404) Update default source/target from 1.6 to 1.7
[
https://issues.apache.org/jira/browse/MCOMPILER-404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16985889#comment-16985889
]
Konrad Windszus edited comment on MCOMPILER-404 at 12/2/19 8:19 AM:
[~michael-o] When do you want to update the default, or do you want to stick
with Java 6 forever?
Regarding
{quote}this problem will reoccur with every new major release{quote}
This is not true as not every major release is dropping support for
cross-compiling for an old version (i.e. Java 9, 10, 11 all support Java 6 as
lowest version).
was (Author: kwin):
[~michael-o] When do you want to update the default, or do you want to stick
with Java 6 forever?
> Update default source/target from 1.6 to 1.7
>
>
> Key: MCOMPILER-404
> URL: https://issues.apache.org/jira/browse/MCOMPILER-404
> Project: Maven Compiler Plugin
> Issue Type: Improvement
>Affects Versions: 3.8.1
>Reporter: Konrad Windszus
>Priority: Major
>
> Similar to what was done in MCOMPILER-335 the default should now be 1.7, as
> that is the oldest version being supported by javac in Java 12 and Java 13
> (https://docs.oracle.com/en/java/javase/12/tools/javac.html#GUID-AEEC9F07-CB49-4E96-8BC7-BCC2C7F725C9__GUID-D343F6B4-3FDD-43A8-AD24-43DD70214471).
> Otherwise compiling sources with Maven on Java 12+ will lead to errors in
> case no explicit source/target/release is set.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MCOMPILER-404) Update default source/target from 1.6 to 1.7
[
https://issues.apache.org/jira/browse/MCOMPILER-404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16985902#comment-16985902
]
Konrad Windszus commented on MCOMPILER-404:
---
Also compare with [~rfscholte] statement from
https://issues.apache.org/jira/browse/MCOMPILER-335?focusedCommentId=16491554&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16491554
{quote} then go for the lowest version supported by the highest JDK.{quote}
> Update default source/target from 1.6 to 1.7
>
>
> Key: MCOMPILER-404
> URL: https://issues.apache.org/jira/browse/MCOMPILER-404
> Project: Maven Compiler Plugin
> Issue Type: Improvement
>Affects Versions: 3.8.1
>Reporter: Konrad Windszus
>Priority: Major
>
> Similar to what was done in MCOMPILER-335 the default should now be 1.7, as
> that is the oldest version being supported by javac in Java 12 and Java 13
> (https://docs.oracle.com/en/java/javase/12/tools/javac.html#GUID-AEEC9F07-CB49-4E96-8BC7-BCC2C7F725C9__GUID-D343F6B4-3FDD-43A8-AD24-43DD70214471).
> Otherwise compiling sources with Maven on Java 12+ will lead to errors in
> case no explicit source/target/release is set.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (ARCHETYPE-511) DefaultArchetypeManager.getRemoteCatalog() swallows exceptions
Konrad Windszus created ARCHETYPE-511: - Summary: DefaultArchetypeManager.getRemoteCatalog() swallows exceptions Key: ARCHETYPE-511 URL: https://issues.apache.org/jira/browse/ARCHETYPE-511 Project: Maven Archetype Issue Type: Improvement Affects Versions: 2.4 Reporter: Konrad Windszus In case a remote catalog cannot be retrieved for some reason, just an empty catalog is being returned. Instead a proper exception (probably ArchetypeDataSourceException) should be thrown to ease tracing the error in the configuration. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ARCHETYPE-511) DefaultArchetypeManager.getRemoteCatalog() swallows exceptions
[ https://issues.apache.org/jira/browse/ARCHETYPE-511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15611818#comment-15611818 ] Konrad Windszus commented on ARCHETYPE-511: --- There is a PR open for this change at https://github.com/apache/maven-archetype/pull/15/files. > DefaultArchetypeManager.getRemoteCatalog() swallows exceptions > -- > > Key: ARCHETYPE-511 > URL: https://issues.apache.org/jira/browse/ARCHETYPE-511 > Project: Maven Archetype > Issue Type: Improvement >Affects Versions: 2.4 >Reporter: Konrad Windszus > > In case a remote catalog cannot be retrieved for some reason, just an empty > catalog is being returned. Instead a proper exception (probably > ArchetypeDataSourceException) should be thrown to ease tracing the error in > the configuration. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MNG-5666) Divide build in pre-build, build and post-build
[
https://issues.apache.org/jira/browse/MNG-5666?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15636389#comment-15636389
]
Konrad Windszus commented on MNG-5666:
--
This would be very interesting in the context of build pipelines in Jenkins.
> Divide build in pre-build, build and post-build
> ---
>
> Key: MNG-5666
> URL: https://issues.apache.org/jira/browse/MNG-5666
> Project: Maven
> Issue Type: Sub-task
> Components: FDPFC, Plugins and Lifecycle
>Reporter: Robert Scholte
>Assignee: Jason van Zyl
> Fix For: 3.x / Backlog
>
>
> Original proposal
> {quote}
> PROPOSAL 1: PerProject and PerPhase Executions
>
> I've recently introduced the installAtEnd/deployAtEnd as an experimental
> feature which should improve the behavior of Maven without having to wait for
> the implementation in Maven Core, which would have a huge impact.
> The reason is that you only want to install and/or deploy only after all
> modules have been build and verified successfully.
> This feature works for most projects, however there are cases which cannot be
> solved by the plugin solution and require a change in the handling of
> lifecycles in Maven Core.
> Up unto the verify-phase you want to execute all phases per project, whereas
> the install and deploy should be executed per phase.
> Consider a root project with 2 modules, these should be executed like this
>
> root : validate ... verify
> module1: validate ... verify
> module2: validate ... verify
> root : install
> module1: install
> module2: install
> root : deploy
> module1: deploy
> module2: deploy
> {quote}
> After one of the google hangout session we came up with the following idea:
> divide the build in pre-build, build and post-build
> First the {{pre-build}} would do a validate of the whole project.
> The {{build}} runs from {{initialize}} up to {{verify}}
> The {{post-build}} would handle the distribution, being {{install}}/{{deploy}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (MNG-6121) Certificate of https://repo.maven.apache.org/maven2 invalid
Konrad Windszus created MNG-6121: Summary: Certificate of https://repo.maven.apache.org/maven2 invalid Key: MNG-6121 URL: https://issues.apache.org/jira/browse/MNG-6121 Project: Maven Issue Type: Bug Reporter: Konrad Windszus The certificate for https://repo.maven.apache.org/maven2 is invalid, although this URL is being mentioned as official URL in http://maven.apache.org/guides/mini/guide-mirror-settings.html (although still with http prefix). This must have been broken in the more recent past because that definitely used to work. The certificate is only valid for repo1.maven.apache.org. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MNG-6121) Certificate of https://repo.maven.apache.org/maven2 invalid
[ https://issues.apache.org/jira/browse/MNG-6121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15677206#comment-15677206 ] Konrad Windszus commented on MNG-6121: -- Probably more a topic for Sonatype, therefore created https://issues.sonatype.org/browse/MVNCENTRAL-1369. > Certificate of https://repo.maven.apache.org/maven2 invalid > --- > > Key: MNG-6121 > URL: https://issues.apache.org/jira/browse/MNG-6121 > Project: Maven > Issue Type: Bug >Reporter: Konrad Windszus > > The certificate for https://repo.maven.apache.org/maven2 is invalid, although > this URL is being mentioned as official URL in > http://maven.apache.org/guides/mini/guide-mirror-settings.html (although > still with http prefix). > This must have been broken in the more recent past because that definitely > used to work. The certificate is only valid for repo1.maven.apache.org. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MPLUGIN-308) Improve mojo documentation for "plugin:report" on complex parameter types
[
https://issues.apache.org/jira/browse/MPLUGIN-308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15839728#comment-15839728
]
Konrad Windszus commented on MPLUGIN-308:
-
I think this can be closed as invalid, as the nested types do not evaluate any
@Parameter annotations at all
(http://maven.40175.n5.nabble.com/why-the-defaultValue-is-not-being-injected-in-Parameter-inside-a-complex-parameter-bean-td5835732.html).
So the enhancement already tracked in MPLUGIN-9 should actually be enough.
> Improve mojo documentation for "plugin:report" on complex parameter types
> -
>
> Key: MPLUGIN-308
> URL: https://issues.apache.org/jira/browse/MPLUGIN-308
> Project: Maven Plugin Tools
> Issue Type: Improvement
> Components: Plugin Plugin
>Affects Versions: 3.4
>Reporter: Konrad Windszus
>Assignee: Robert Scholte
>
> In case you have a Mojo with a custom complex parameter, i.e. a Parameter of
> type {{MyParam}}, where {{MyParam}} again has some fields annotated with
> {{@Parameter}}, the documentation of {{MyParam}} with its individual pieces
> should be part of the mojo documentation being generated by {{plugin:report}}.
> See also
> http://stackoverflow.com/questions/20696862/inject-parameter-in-different-class-in-maven-plugin.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (MPLUGIN-322) The javadoc for the @Parameter annotation should clearly state that those are only evaluated on fields of a Mojo
Konrad Windszus created MPLUGIN-322:
---
Summary: The javadoc for the @Parameter annotation should clearly
state that those are only evaluated on fields of a Mojo
Key: MPLUGIN-322
URL: https://issues.apache.org/jira/browse/MPLUGIN-322
Project: Maven Plugin Tools
Issue Type: Improvement
Components: maven-plugin-annotations
Affects Versions: 3.5
Reporter: Konrad Windszus
As it is not obvious that {{@Parameter}} annotations must only be used on
fields of a Mojo class (see
http://maven.40175.n5.nabble.com/why-the-defaultValue-is-not-being-injected-in-Parameter-inside-a-complex-parameter-bean-td5835732.html)
this should be explicitly stated. I would propose to change the javadoc in
http://svn.apache.org/viewvc/maven/plugin-tools/trunk/maven-plugin-annotations/src/main/java/org/apache/maven/plugins/annotations/Parameter.java?revision=1757927&view=markup#l29
from
{quote}
Used to configure your Mojo parameters to be injected by
MavenPluginManager.getConfiguredMojo(...).
{quote}
to
{quote}
Used to configure your Mojo parameters to be injected by
MavenPluginManager.getConfiguredMojo(...).
Although nested bean injection is supported by that method, this annotation is
only effective on fields of the Mojo class itself and not on fields of any bean
classes being used as Mojo parameter.
{quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (SCM-841) Support --force-interactive option introduced with SVN 1.8
Konrad Windszus created SCM-841:
---
Summary: Support --force-interactive option introduced with SVN 1.8
Key: SCM-841
URL: https://issues.apache.org/jira/browse/SCM-841
Project: Maven SCM
Issue Type: Improvement
Components: maven-scm-provider-svn
Affects Versions: 1.9.5
Reporter: Konrad Windszus
With SVN 1.8 the additional option {{--force-interactive}} has been introduced
with this commit: http://svn.apache.org/viewvc?view=revision&revision=1424037.
It seems that it always runs by default in non-interactive mode when being
triggered from the maven release plugin, therefore with {{mvn release:prepare}}
you might see the following issue
{code}
[INFO] --- maven-release-plugin:2.5.1:prepare (default-cli) @ xxx ---
[INFO] Resuming release from phase 'scm-commit-release'
[INFO] Checking in modified POMs...
[INFO] Executing: /bin/sh -c cd && svn --non-interactive
commit --file
/var/folders/rm/vlg2h6m16mb0f65djmnb12xrgq/T/maven-scm-1099976641.commit
--targets
/var/folders/rm/vlg2h6m16mb0f65djmnb12xrgq/T/maven-scm-3840927493290123998-targets
[INFO] Working directory:
[INFO]
[INFO] BUILD FAILURE
[INFO]
[INFO] Total time: 3.664 s
[INFO] Finished at: 2017-02-05T10:58:28+00:00
[INFO] Final Memory: 14M/247M
[INFO]
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-release-plugin:2.5.1:prepare (default-cli) on
project xxx: Unable to commit files
[ERROR] Provider message:
[ERROR] The svn command failed.
[ERROR] Command output:
[ERROR] svn: E215004: Authentication failed and interactive prompting is
disabled; see the --force-interactive option
[ERROR] svn: E215004: Commit failed (details follow):
[ERROR] svn: E215004: No more credentials or we tried too many times.
[ERROR] Authentication failed
{code}
Even though SVN was triggered without the option {{--non-interactive}} it still
won't run in interactive mode due to the change in 1.8. Therefore the
{{svn-setttings.xml}} should support to enable the new option
{{--force-interactive}}.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (SCM-841) Support --force-interactive option introduced with SVN 1.8
[
https://issues.apache.org/jira/browse/SCM-841?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated SCM-841:
Description:
With SVN 1.8 the additional option {{--force-interactive}} has been introduced
with this commit: http://svn.apache.org/viewvc?view=revision&revision=1424037.
This option is not documented at
http://svnbook.red-bean.com/en/1.8/svn.ref.svn.html. But the CLI exposes the
following (via {{svn st --help}}
{code}
--non-interactive: do no interactive prompting (default is to prompt
only if standard input is a terminal device)
--force-interactive : do interactive prompting even if standard input
is not a terminal device
{code}
It seems that it always runs by default in non-interactive mode when being
triggered from the maven release plugin, therefore with {{mvn release:prepare}}
you might see the following issue
{code}
[INFO] --- maven-release-plugin:2.5.1:prepare (default-cli) @ xxx ---
[INFO] Resuming release from phase 'scm-commit-release'
[INFO] Checking in modified POMs...
[INFO] Executing: /bin/sh -c cd && svn --non-interactive
commit --file
/var/folders/rm/vlg2h6m16mb0f65djmnb12xrgq/T/maven-scm-1099976641.commit
--targets
/var/folders/rm/vlg2h6m16mb0f65djmnb12xrgq/T/maven-scm-3840927493290123998-targets
[INFO] Working directory:
[INFO]
[INFO] BUILD FAILURE
[INFO]
[INFO] Total time: 3.664 s
[INFO] Finished at: 2017-02-05T10:58:28+00:00
[INFO] Final Memory: 14M/247M
[INFO]
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-release-plugin:2.5.1:prepare (default-cli) on
project xxx: Unable to commit files
[ERROR] Provider message:
[ERROR] The svn command failed.
[ERROR] Command output:
[ERROR] svn: E215004: Authentication failed and interactive prompting is
disabled; see the --force-interactive option
[ERROR] svn: E215004: Commit failed (details follow):
[ERROR] svn: E215004: No more credentials or we tried too many times.
[ERROR] Authentication failed
{code}
Even though SVN was triggered without the option {{--non-interactive}} it still
won't run in interactive mode due to the change in 1.8. Therefore the
{{svn-setttings.xml}} should support to enable the new option
{{--force-interactive}} so that the SVN will interactively ask for the
credentials (instead of being forced to pass that via {{-Dusername and
-Dpassword}} when triggering the mvn goal).
was:
With SVN 1.8 the additional option {{--force-interactive}} has been introduced
with this commit: http://svn.apache.org/viewvc?view=revision&revision=1424037.
It seems that it always runs by default in non-interactive mode when being
triggered from the maven release plugin, therefore with {{mvn release:prepare}}
you might see the following issue
{code}
[INFO] --- maven-release-plugin:2.5.1:prepare (default-cli) @ xxx ---
[INFO] Resuming release from phase 'scm-commit-release'
[INFO] Checking in modified POMs...
[INFO] Executing: /bin/sh -c cd && svn --non-interactive
commit --file
/var/folders/rm/vlg2h6m16mb0f65djmnb12xrgq/T/maven-scm-1099976641.commit
--targets
/var/folders/rm/vlg2h6m16mb0f65djmnb12xrgq/T/maven-scm-3840927493290123998-targets
[INFO] Working directory:
[INFO]
[INFO] BUILD FAILURE
[INFO]
[INFO] Total time: 3.664 s
[INFO] Finished at: 2017-02-05T10:58:28+00:00
[INFO] Final Memory: 14M/247M
[INFO]
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-release-plugin:2.5.1:prepare (default-cli) on
project xxx: Unable to commit files
[ERROR] Provider message:
[ERROR] The svn command failed.
[ERROR] Command output:
[ERROR] svn: E215004: Authentication failed and interactive prompting is
disabled; see the --force-interactive option
[ERROR] svn: E215004: Commit failed (details follow):
[ERROR] svn: E215004: No more credentials or we tried too many times.
[ERROR] Authentication failed
{code}
Even though SVN was triggered without the option {{--non-interactive}} it still
won't run in interactive mode due to the change in 1.8. Therefore the
{{svn-setttings.xml}} should support to enable the new option
{{--force-interactive}}.
> Support --force-interactive option introduced with SVN 1.8
> --
>
> Key: SCM-841
> URL: https://issues.apache.org/jira/browse/SCM-841
> Project: Maven SCM
> Issue Type: Improvement
> Components: maven-scm-provider-svn
>Affects Ver
[jira] [Updated] (SCM-841) Support --force-interactive option introduced with SVN 1.8
[
https://issues.apache.org/jira/browse/SCM-841?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated SCM-841:
Description:
With SVN 1.8 the additional option {{--force-interactive}} has been introduced
with this commit: http://svn.apache.org/viewvc?view=revision&revision=1424037.
This option is not documented at
http://svnbook.red-bean.com/en/1.8/svn.ref.svn.html. But the CLI exposes the
following (via {{svn st --help}}
{code}
--non-interactive: do no interactive prompting (default is to prompt
only if standard input is a terminal device)
--force-interactive : do interactive prompting even if standard input
is not a terminal device
{code}
It seems that it always runs by default in non-interactive mode even with
{{useNonInteractive}} set to false
(https://maven.apache.org/scm/maven-scm-providers/maven-scm-providers-svn/maven-scm-provider-svn-commons/svn-settings.html)
when being triggered from the maven release plugin, therefore with {{mvn
release:prepare}} you might see the following issue
{code}
[INFO] --- maven-release-plugin:2.5.1:prepare (default-cli) @ xxx ---
[INFO] Resuming release from phase 'scm-commit-release'
[INFO] Checking in modified POMs...
[INFO] Executing: /bin/sh -c cd && svn commit --file
/var/folders/rm/vlg2h6m16mb0f65djmnb12xrgq/T/maven-scm-1099976641.commit
--targets
/var/folders/rm/vlg2h6m16mb0f65djmnb12xrgq/T/maven-scm-3840927493290123998-targets
[INFO] Working directory:
[INFO]
[INFO] BUILD FAILURE
[INFO]
[INFO] Total time: 3.664 s
[INFO] Finished at: 2017-02-05T10:58:28+00:00
[INFO] Final Memory: 14M/247M
[INFO]
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-release-plugin:2.5.1:prepare (default-cli) on
project xxx: Unable to commit files
[ERROR] Provider message:
[ERROR] The svn command failed.
[ERROR] Command output:
[ERROR] svn: E215004: Authentication failed and interactive prompting is
disabled; see the --force-interactive option
[ERROR] svn: E215004: Commit failed (details follow):
[ERROR] svn: E215004: No more credentials or we tried too many times.
[ERROR] Authentication failed
{code}
Even though SVN was triggered without the option {{--non-interactive}} it still
won't run in interactive mode due to the change in 1.8. Therefore the
{{svn-setttings.xml}} should support to enable the new option
{{--force-interactive}} so that the SVN will interactively ask for the
credentials (instead of being forced to pass that via {{-Dusername and
-Dpassword}} when triggering the mvn goal).
was:
With SVN 1.8 the additional option {{--force-interactive}} has been introduced
with this commit: http://svn.apache.org/viewvc?view=revision&revision=1424037.
This option is not documented at
http://svnbook.red-bean.com/en/1.8/svn.ref.svn.html. But the CLI exposes the
following (via {{svn st --help}}
{code}
--non-interactive: do no interactive prompting (default is to prompt
only if standard input is a terminal device)
--force-interactive : do interactive prompting even if standard input
is not a terminal device
{code}
It seems that it always runs by default in non-interactive mode when being
triggered from the maven release plugin, therefore with {{mvn release:prepare}}
you might see the following issue
{code}
[INFO] --- maven-release-plugin:2.5.1:prepare (default-cli) @ xxx ---
[INFO] Resuming release from phase 'scm-commit-release'
[INFO] Checking in modified POMs...
[INFO] Executing: /bin/sh -c cd && svn --non-interactive
commit --file
/var/folders/rm/vlg2h6m16mb0f65djmnb12xrgq/T/maven-scm-1099976641.commit
--targets
/var/folders/rm/vlg2h6m16mb0f65djmnb12xrgq/T/maven-scm-3840927493290123998-targets
[INFO] Working directory:
[INFO]
[INFO] BUILD FAILURE
[INFO]
[INFO] Total time: 3.664 s
[INFO] Finished at: 2017-02-05T10:58:28+00:00
[INFO] Final Memory: 14M/247M
[INFO]
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-release-plugin:2.5.1:prepare (default-cli) on
project xxx: Unable to commit files
[ERROR] Provider message:
[ERROR] The svn command failed.
[ERROR] Command output:
[ERROR] svn: E215004: Authentication failed and interactive prompting is
disabled; see the --force-interactive option
[ERROR] svn: E215004: Commit failed (details follow):
[ERROR] svn: E215004: No more credentials or we tried too many times.
[ERROR] Authentication failed
{code}
E
[jira] [Commented] (SCM-841) Support --force-interactive option introduced with SVN 1.8
[
https://issues.apache.org/jira/browse/SCM-841?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15855468#comment-15855468
]
Konrad Windszus commented on SCM-841:
-
No I didn't try it out. But I would propose to change the way how SVN is called
then. When the SVN command is currently not being triggered with an input
stream being properly allocated I would favor to then change that to allow for
a true interactive modes here. Otherwise you can only pass the credentials via
the regular CLI parameters with the known drawbacks (see
https://maven.apache.org/guides/mini/guide-encryption.html#Tips, Prompting for
Passwords).
> Support --force-interactive option introduced with SVN 1.8
> --
>
> Key: SCM-841
> URL: https://issues.apache.org/jira/browse/SCM-841
> Project: Maven SCM
> Issue Type: Improvement
> Components: maven-scm-provider-svn
>Affects Versions: 1.9.5
>Reporter: Konrad Windszus
>
> With SVN 1.8 the additional option {{--force-interactive}} has been
> introduced with this commit:
> http://svn.apache.org/viewvc?view=revision&revision=1424037.
> This option is not documented at
> http://svnbook.red-bean.com/en/1.8/svn.ref.svn.html. But the CLI exposes the
> following (via {{svn st --help}}
> {code}
> --non-interactive: do no interactive prompting (default is to prompt
> only if standard input is a terminal device)
> --force-interactive : do interactive prompting even if standard input
> is not a terminal device
> {code}
> It seems that it always runs by default in non-interactive mode even with
> {{useNonInteractive}} set to false
> (https://maven.apache.org/scm/maven-scm-providers/maven-scm-providers-svn/maven-scm-provider-svn-commons/svn-settings.html)
> when being triggered from the maven release plugin, therefore with {{mvn
> release:prepare}} you might see the following issue
> {code}
> [INFO] --- maven-release-plugin:2.5.1:prepare (default-cli) @ xxx ---
> [INFO] Resuming release from phase 'scm-commit-release'
> [INFO] Checking in modified POMs...
> [INFO] Executing: /bin/sh -c cd && svn commit --file
> /var/folders/rm/vlg2h6m16mb0f65djmnb12xrgq/T/maven-scm-1099976641.commit
> --targets
> /var/folders/rm/vlg2h6m16mb0f65djmnb12xrgq/T/maven-scm-3840927493290123998-targets
> [INFO] Working directory:
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 3.664 s
> [INFO] Finished at: 2017-02-05T10:58:28+00:00
> [INFO] Final Memory: 14M/247M
> [INFO]
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-release-plugin:2.5.1:prepare (default-cli) on
> project xxx: Unable to commit files
> [ERROR] Provider message:
> [ERROR] The svn command failed.
> [ERROR] Command output:
> [ERROR] svn: E215004: Authentication failed and interactive prompting is
> disabled; see the --force-interactive option
> [ERROR] svn: E215004: Commit failed (details follow):
> [ERROR] svn: E215004: No more credentials or we tried too many times.
> [ERROR] Authentication failed
> {code}
> Even though SVN was triggered without the option {{\-\-non-interactive}} it
> still won't run in interactive mode due to the change in 1.8. Therefore the
> {{svn-setttings.xml}} should support to enable the new option
> {{\-\-force-interactive}} so that the SVN will interactively ask for the
> credentials (instead of being forced to pass that via {{-Dusername and
> -Dpassword}} when triggering the mvn goal).
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (MPLUGIN-322) The javadoc for the @Parameter annotation should clearly state that those are only evaluated on fields of a Mojo
[
https://issues.apache.org/jira/browse/MPLUGIN-322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15874136#comment-15874136
]
Konrad Windszus commented on MPLUGIN-322:
-
I expected the fields of the annotation, like {{defaultValue}}, {{required}}
and {{alias}} to be evaluated as well. I admit though that in case transitive
{{@Parameter}} annotations would be supported, this may lead to contradicting
annotations (on the bean and within the bean). Therefore I am not requesting to
change anything about that behaviour but rather just a clarification on the
javadocs.
> The javadoc for the @Parameter annotation should clearly state that those are
> only evaluated on fields of a Mojo
>
>
> Key: MPLUGIN-322
> URL: https://issues.apache.org/jira/browse/MPLUGIN-322
> Project: Maven Plugin Tools
> Issue Type: Documentation
> Components: maven-plugin-annotations
>Affects Versions: 3.5
>Reporter: Konrad Windszus
>
> As it is not obvious that {{@Parameter}} annotations must only be used on
> fields of a Mojo class (see
> http://maven.40175.n5.nabble.com/why-the-defaultValue-is-not-being-injected-in-Parameter-inside-a-complex-parameter-bean-td5835732.html)
> this should be explicitly stated. I would propose to change the javadoc in
> http://svn.apache.org/viewvc/maven/plugin-tools/trunk/maven-plugin-annotations/src/main/java/org/apache/maven/plugins/annotations/Parameter.java?revision=1757927&view=markup#l29
> from
> {quote}
> Used to configure your Mojo parameters to be injected by
> href="/ref/current/maven-core/apidocs/org/apache/maven/plugin/MavenPluginManager.html">
> MavenPluginManager.getConfiguredMojo(...).
> {quote}
> to
> {quote}
> Used to configure your Mojo parameters to be injected by
> href="/ref/current/maven-core/apidocs/org/apache/maven/plugin/MavenPluginManager.html">
> MavenPluginManager.getConfiguredMojo(...).
> Although nested bean injection is supported by that method, this annotation
> is only effective on fields of the Mojo class itself and not on fields of any
> bean classes being used as Mojo parameter.
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (SUREFIRE-1047) Add @{...} property evaluation for the argLine
[
https://issues.apache.org/jira/browse/SUREFIRE-1047?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15922895#comment-15922895
]
Konrad Windszus commented on SUREFIRE-1047:
---
I don't really see the need for this, as for all plugin parameters the
properties are evaluated only directly before the mojo is being called in
{{DefaultMavenPluginManager.getConfiguredMojo(...)}}
(https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/plugin/internal/DefaultMavenPluginManager.java#L594).
> Add @{...} property evaluation for the argLine
> --
>
> Key: SUREFIRE-1047
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1047
> Project: Maven Surefire
> Issue Type: Improvement
> Components: Maven Surefire Plugin
>Affects Versions: 2.16
>Reporter: Henning Schmiedehausen
>Assignee: Andreas Gudian
> Fix For: 2.17
>
>
> Replaces expressions @{property-name} in the argLine with the corresponding
> properties from the model. This allows late evaluation of property values
> when the plugin is executed (as compared to evaluation when the pom is parsed
> as is done with ${property-name} expressions).
> This allows other plugins to modify or set properties with the changes
> getting picked up by surefire.
> Please merge the pull request at
> https://github.com/apache/maven-surefire/pull/30
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (ARCHETYPE-519) archetype:generate with specified remote archetypeCatalog falls back to internal catalog
[
https://issues.apache.org/jira/browse/ARCHETYPE-519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15981244#comment-15981244
]
Konrad Windszus commented on ARCHETYPE-519:
---
What about this now? This has been closed as fixed, but if I understand
correctly the only thing being fixed is that URLs now leads to an IAE instead
of silently falling back to internal. What about the still valid use case of
allowing a user to use a remote catalog without forcing him to meddle around
with the {{settings.xml}}?
Also I am wondering how it is possible to support multiple archetype
repositories (because they all must have the same {{id}} (archetype)).
> archetype:generate with specified remote archetypeCatalog falls back to
> internal catalog
>
>
> Key: ARCHETYPE-519
> URL: https://issues.apache.org/jira/browse/ARCHETYPE-519
> Project: Maven Archetype
> Issue Type: Bug
> Components: Generator
>Affects Versions: 3.0.0
> Environment: Mac OS X 10.11.6, Apache Maven 3.2.3
>Reporter: Philip Mundt
>Assignee: Robert Scholte
> Fix For: 3.0.1
>
>
> We were surprised to find out that our archetype was "suddenly" not working
> anymore. It turns out it was the release of
> {{org.apache.maven.plugins:maven-archetype-plugin:3.0.0}} from 12/Feb/17 that
> was the culprit.
> When running:
> {{mvn org.apache.maven.plugins:maven-archetype-plugin:3.0.0:generate
> -DarchetypeCatalog=}} we end up with the
> plugin falling back to the internal catalog:
> {code}
> [INFO] Scanning for projects...
> [INFO]
> [INFO]
>
> [INFO] Building Maven Stub Project (No POM) 1
> [INFO]
>
> [INFO]
> [INFO] >>> maven-archetype-plugin:3.0.0:generate (default-cli) >
> generate-sources @ standalone-pom >>>
> [INFO]
> [INFO] <<< maven-archetype-plugin:3.0.0:generate (default-cli) <
> generate-sources @ standalone-pom <<<
> [INFO]
> [INFO] --- maven-archetype-plugin:3.0.0:generate (default-cli) @
> standalone-pom ---
> [INFO] Generating project in Interactive mode
> [INFO] No catalog defined. Using internal catalog
> [INFO] No archetype defined. Using maven-archetype-quickstart
> (org.apache.maven.archetypes:maven-archetype-quickstart:1.0)
> Choose archetype:
> 1: internal -> org.apache.maven.archetypes:maven-archetype-archetype (An
> archetype which contains a sample archetype.)
> 2: internal -> org.apache.maven.archetypes:maven-archetype-j2ee-simple (An
> archetype which contains a simplifed sample J2EE application.)
> 3: internal -> org.apache.maven.archetypes:maven-archetype-plugin (An
> archetype which contains a sample Maven plugin.)
> 4: internal -> org.apache.maven.archetypes:maven-archetype-plugin-site (An
> archetype which contains a sample Maven plugin site.
> This archetype can be layered upon an existing Maven plugin project.)
> 5: internal -> org.apache.maven.archetypes:maven-archetype-portlet (An
> archetype which contains a sample JSR-268 Portlet.)
> 6: internal -> org.apache.maven.archetypes:maven-archetype-profiles ()
> 7: internal -> org.apache.maven.archetypes:maven-archetype-quickstart (An
> archetype which contains a sample Maven project.)
> 8: internal -> org.apache.maven.archetypes:maven-archetype-site (An archetype
> which contains a sample Maven site which demonstrates
> some of the supported document types like APT, XDoc, and FML and
> demonstrates how
> to i18n your site. This archetype can be layered upon an existing Maven
> project.)
> 9: internal -> org.apache.maven.archetypes:maven-archetype-site-simple (An
> archetype which contains a sample Maven site.)
> 10: internal -> org.apache.maven.archetypes:maven-archetype-webapp (An
> archetype which contains a sample Maven Webapp project.)
> Choose a number or apply filter (format: [groupId:]artifactId, case sensitive
> contains):
> {code}
> Version 2.4 works as expected (the archetype catalog exists under given URL
> and can be downloaded).
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (SCM-832) maven-scm-provider-jgit should support SSH public key auth
[
https://issues.apache.org/jira/browse/SCM-832?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15988858#comment-15988858
]
Konrad Windszus commented on SCM-832:
-
I am also affected from that. The PR IMHO looks good, but I think it would be
good if the passphrase could not only be entered in the {{settings.xml}} but is
alternatively used the given credentials (that way it would be possible to use
{{mvn release:prepare -Dpassword=}}).
> maven-scm-provider-jgit should support SSH public key auth
> --
>
> Key: SCM-832
> URL: https://issues.apache.org/jira/browse/SCM-832
> Project: Maven SCM
> Issue Type: New Feature
> Components: maven-scm-provider-gitexe, maven-scm-provider-jgit
>Affects Versions: 1.9.4
>Reporter: Martin Kutter
>
> The current mvn-scm-provider-jgit implementation does not support the
> explicit use of public key auth. The underlying implementation implicitly
> uses ~/id_rsa or ~/id_dsa if present (and not protected by a passphrase).
> For most Git repositories (Github, Gitlab, ...), public key authentication is
> mandatory for ssh access.
> This forces users to either use https, or to rely on a unprotected private
> key file.
> maven-scm-provider-jgit should support the privateKey and passphrase
> attributes available in server entries in maven settings.xml for ssh URLs
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (SCM-845) Maven Release Plugin releases SNAPSHOT instead of STABLE version (jgit)
[ https://issues.apache.org/jira/browse/SCM-845?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15989832#comment-15989832 ] Konrad Windszus commented on SCM-845: - I have the same issue and seems indeed occur in case when the released artifact is not in the root of the repository (similar to SCM-740). I fail to see how a fix being applied for SCM-740 could be easily transferred to https://github.com/apache/maven-scm/blob/master/maven-scm-providers/maven-scm-providers-git/maven-scm-provider-jgit/src/main/java/org/apache/maven/scm/provider/git/jgit/command/status/JGitStatusCommand.java. [~struberg] Since you came up with the original fix for SCM-740, could you have a look what needs to be changed in the JGitFlow provider to support that use case as well? > Maven Release Plugin releases SNAPSHOT instead of STABLE version (jgit) > --- > > Key: SCM-845 > URL: https://issues.apache.org/jira/browse/SCM-845 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-provider-jgit >Affects Versions: 1.9.5 >Reporter: Archimedes Trajano > > I just tried to do a release with the exact scenario as SCM-740 and had the > same result. The SCM-740 provided a fix for gitexe which I verified works > when I switched to that provider, but jgit has the same issue -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Comment Edited] (SCM-845) Maven Release Plugin releases SNAPSHOT instead of STABLE version (jgit)
[ https://issues.apache.org/jira/browse/SCM-845?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15989832#comment-15989832 ] Konrad Windszus edited comment on SCM-845 at 4/29/17 10:09 AM: --- I have the same issue and seems indeed occur in case when the released artifact is not in the root of the repository (similar to SCM-740). I fail to see how a fix being applied for SCM-740 could be easily transferred to https://github.com/apache/maven-scm/blob/master/maven-scm-providers/maven-scm-providers-git/maven-scm-provider-jgit/src/main/java/org/apache/maven/scm/provider/git/jgit/command/status/JGitStatusCommand.java. [~struberg] Since you came up with the original fix for SCM-740, could you have a look what needs to be changed in the JGit provider to support that use case as well? was (Author: kwin): I have the same issue and seems indeed occur in case when the released artifact is not in the root of the repository (similar to SCM-740). I fail to see how a fix being applied for SCM-740 could be easily transferred to https://github.com/apache/maven-scm/blob/master/maven-scm-providers/maven-scm-providers-git/maven-scm-provider-jgit/src/main/java/org/apache/maven/scm/provider/git/jgit/command/status/JGitStatusCommand.java. [~struberg] Since you came up with the original fix for SCM-740, could you have a look what needs to be changed in the JGitFlow provider to support that use case as well? > Maven Release Plugin releases SNAPSHOT instead of STABLE version (jgit) > --- > > Key: SCM-845 > URL: https://issues.apache.org/jira/browse/SCM-845 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-provider-jgit >Affects Versions: 1.9.5 >Reporter: Archimedes Trajano > > I just tried to do a release with the exact scenario as SCM-740 and had the > same result. The SCM-740 provided a fix for gitexe which I verified works > when I switched to that provider, but jgit has the same issue -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Comment Edited] (SCM-845) Maven Release Plugin releases SNAPSHOT instead of STABLE version (jgit)
[ https://issues.apache.org/jira/browse/SCM-845?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15989832#comment-15989832 ] Konrad Windszus edited comment on SCM-845 at 4/29/17 10:40 AM: --- I have the same issue and seems indeed occur in case when the released artifact is not in the root of the repository (similar to SCM-740). I fail to see how a fix being applied for SCM-740 could be easily transferred to https://github.com/apache/maven-scm/blob/master/maven-scm-providers/maven-scm-providers-git/maven-scm-provider-jgit/src/main/java/org/apache/maven/scm/provider/git/jgit/command/status/JGitStatusCommand.java. [~struberg] Since you came up with the original fix for SCM-740, could you have a look what needs to be changed in the JGit provider to support that use case as well? Also it would probably be good to extend the TCK to cover this use case, to check that all providers support that properly. was (Author: kwin): I have the same issue and seems indeed occur in case when the released artifact is not in the root of the repository (similar to SCM-740). I fail to see how a fix being applied for SCM-740 could be easily transferred to https://github.com/apache/maven-scm/blob/master/maven-scm-providers/maven-scm-providers-git/maven-scm-provider-jgit/src/main/java/org/apache/maven/scm/provider/git/jgit/command/status/JGitStatusCommand.java. [~struberg] Since you came up with the original fix for SCM-740, could you have a look what needs to be changed in the JGit provider to support that use case as well? > Maven Release Plugin releases SNAPSHOT instead of STABLE version (jgit) > --- > > Key: SCM-845 > URL: https://issues.apache.org/jira/browse/SCM-845 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-provider-jgit >Affects Versions: 1.9.5 >Reporter: Archimedes Trajano > > I just tried to do a release with the exact scenario as SCM-740 and had the > same result. The SCM-740 provided a fix for gitexe which I verified works > when I switched to that provider, but jgit has the same issue -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (SCM-845) Maven Release Plugin releases SNAPSHOT instead of STABLE version (jgit)
[ https://issues.apache.org/jira/browse/SCM-845?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15989839#comment-15989839 ] Konrad Windszus commented on SCM-845: - Could also be related to SCM-807. > Maven Release Plugin releases SNAPSHOT instead of STABLE version (jgit) > --- > > Key: SCM-845 > URL: https://issues.apache.org/jira/browse/SCM-845 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-provider-jgit >Affects Versions: 1.9.5 >Reporter: Archimedes Trajano > > I just tried to do a release with the exact scenario as SCM-740 and had the > same result. The SCM-740 provided a fix for gitexe which I verified works > when I switched to that provider, but jgit has the same issue -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (SCM-807) JGit impl check-in fails unless the Maven project is in the working copy root
[ https://issues.apache.org/jira/browse/SCM-807?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15989854#comment-15989854 ] Konrad Windszus commented on SCM-807: - This patch works for me and fixes the issue described in SCM-845. Does anything speaks against committing it (except that there is no test for it)? > JGit impl check-in fails unless the Maven project is in the working copy root > - > > Key: SCM-807 > URL: https://issues.apache.org/jira/browse/SCM-807 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-provider-gitexe >Affects Versions: 1.9.4 >Reporter: Richard DiCroce > Attachments: scm-807.txt > > > Another problem exposed by maven-release-plugin: the JGit SCM > implementation's check-in fails unless the Maven project is in the working > copy root because it confuses the working copy's location with the Maven > project's location. > The attached patch resolves the issue. Combined with the patch attached to > SCM-806, release:prepare now mostly succeeds with the JGit implementation. > There is still a problem with the POM not being transformed correctly, but > that's a problem in maven-release-plugin. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (MPLUGIN-337) Try to derive JDK requirements also from target parameter
Konrad Windszus created MPLUGIN-337:
---
Summary: Try to derive JDK requirements also from target 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
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-5909) Activating a profile based on the existence of multiple files is not possible
[
https://issues.apache.org/jira/browse/MNG-5909?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16527367#comment-16527367
]
Konrad Windszus commented on MNG-5909:
--
As the PR from above is somehow not showing the changes, the relevant commit id
is:
https://github.com/apache/maven/pull/92/commits/2efe3d2d3b92685d83c2598a7f85c39ebdd59ebc
> Activating a profile based on the existence of multiple files is not possible
> -
>
> Key: MNG-5909
> URL: https://issues.apache.org/jira/browse/MNG-5909
> Project: Maven
> Issue Type: Improvement
> Components: core
>Affects Versions: 3.3.3
>Reporter: Konrad Windszus
>Priority: Major
>
> Currently each type of activation (os, jdk, file, property) can only be used
> once for activating a single profile.
> Therefore it is not possible to activate a profile in case two different
> files are existing, although since Maven 3.2.2 (MNG-4565) it is possible to
> combine multiple activations of different types.
> Multiple {{file}} or {{property}} should therefore be supported to allow to
> express something like:
> Enable {{profileA}} in case both {{fileA}} and {{fileB}} do exists
> For {{jdk}} and {{os}} this is less relevant because all conditions are
> combined with AND.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (MNG-6438) Continuous Delivery friendly versions do not work on root pom's parent
Konrad Windszus created MNG-6438:
Summary: 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
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
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}
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] [Updated] (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:all-tabpanel
]
Konrad Windszus updated MNG-6438:
-
Affects Version/s: 3.5.3
> 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] [Comment Edited] (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=16530062#comment-16530062
]
Konrad Windszus edited comment on MNG-6438 at 7/2/18 3:15 PM:
--
[~khmarbaise] The given pom.xml is enough to reproduce the issue. You don't
need any more sources (like the non-existing parent pom) because the error
happens so early in the Maven build.
was (Author: kwin):
[~khmarbaise] This pom.xml is enough to reproduce the issue. You don't need any
more sources (like the non-existing parent pom) because the error happens so
early in the Maven build.
> 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] (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=16530062#comment-16530062
]
Konrad Windszus commented on MNG-6438:
--
[~khmarbaise] This pom.xml is enough to reproduce the issue. You don't need any
more sources (like the non-existing parent pom) because the error happens so
early in the Maven build.
> 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] (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=16530884#comment-16530884
]
Konrad Windszus commented on MNG-6438:
--
[~khmarbaise] The documentation at
https://maven.apache.org/maven-ci-friendly.html does not explicitly state that
referencing a parent outside the reactor is not possible with those properties.
This would be very useful, e.g. when using your iterator-maven-plugin with goal
{{invoker}} https://github.com/khmarbaise/iterator-maven-plugin. When you
parameterize the parent version like this, releasing is a lot easier.
Is there any technical reason, why parent versions should not work in a similar
fashion?
> 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] (MNG-5394) Document how to do logging in a plugin
[ https://jira.codehaus.org/browse/MNG-5394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=364569#comment-364569 ] Konrad Windszus commented on MNG-5394: -- Can we add the info to that wiki page which SLF4J API version is exposed by which Maven version? Also to me it seems SLF4J is already part of Maven 3.0.5 (it is there in the Mojo classpath at least). > Document how to do logging in a plugin > -- > > Key: MNG-5394 > URL: https://jira.codehaus.org/browse/MNG-5394 > Project: Maven > Issue Type: Task > Components: Logging > Environment: n/a >Reporter: Anders Hammar > > We should document the different logging options in a Maven plugin that exist > and differences/benefits. So the main audience is not Maven users, but plugin > developers and I guess this doc should go in under the Plugin Developer > Center section. > There is currently a "[Maven 3.1.x > logging|http://maven.apache.org/maven-logging.html]"; page, but that one is > for end users and a different story than what this ticket is about. > A few things that the page should cover: > * Plexus logger & SLF4J > * Any compatibility problems using SLF4J with older Maven versions? > * A code example including an example pom depicting dependencies > * How to establish logging separated from Maven's (fork a JVM?) -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] [Created] (ARCHETYPE-491) Allow to run an integration test for a module (instead of a project) archetype
Konrad Windszus created ARCHETYPE-491:
-
Summary: Allow to run an integration test for a module (instead of
a project) archetype
Key: ARCHETYPE-491
URL: https://issues.apache.org/jira/browse/ARCHETYPE-491
Project: Maven Archetype
Issue Type: Improvement
Components: Plugin
Affects Versions: 2.4
Reporter: Konrad Windszus
Archetypes can be either devised as module archetypes (should only be used
below existing Maven projects, then the parent will be automatically set) or as
regular project archetypes (i.e. will run standalone, because they need no
parent or have a parent hardcoded in their pom). Currently only the latter is
properly supported for the goal {{integration-test}}.
To also support the former it would be good to allow the setup of arbitrary
parent structures (from other archetypes) below which the actual IT should be
executed.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (ARCHETYPE-491) Allow to run integration test with another archetype as parent project
[
https://issues.apache.org/jira/browse/ARCHETYPE-491?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated ARCHETYPE-491:
--
Description:
Archetypes can be either used as module archetypes (below existing Maven
projects, then the parent will be automatically set) or as regular project
archetypes (i.e. will run standalone, because they need no parent or have a
parent hardcoded in their pom). Currently only the latter is properly supported
for the goal {{integration-test}}.
To also support the former it would be good to allow the setup of arbitrary
parent structures (from other archetypes) below which the actual IT should be
executed.
was:
Archetypes can be either devised as module archetypes (should only be used
below existing Maven projects, then the parent will be automatically set) or as
regular project archetypes (i.e. will run standalone, because they need no
parent or have a parent hardcoded in their pom). Currently only the latter is
properly supported for the goal {{integration-test}}.
To also support the former it would be good to allow the setup of arbitrary
parent structures (from other archetypes) below which the actual IT should be
executed.
Summary: Allow to run integration test with another archetype as parent
project (was: Allow to run an integration test for a module (instead of a
project) archetype)
> Allow to run integration test with another archetype as parent project
> --
>
> Key: ARCHETYPE-491
> URL: https://issues.apache.org/jira/browse/ARCHETYPE-491
> Project: Maven Archetype
> Issue Type: Improvement
> Components: Plugin
>Affects Versions: 2.4
>Reporter: Konrad Windszus
>
> Archetypes can be either used as module archetypes (below existing Maven
> projects, then the parent will be automatically set) or as regular project
> archetypes (i.e. will run standalone, because they need no parent or have a
> parent hardcoded in their pom). Currently only the latter is properly
> supported for the goal {{integration-test}}.
> To also support the former it would be good to allow the setup of arbitrary
> parent structures (from other archetypes) below which the actual IT should be
> executed.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (MNG-5909) Activating a profile based on the existence of multiple files is not possible
Konrad Windszus created MNG-5909:
Summary: Activating a profile based on the existence of multiple
files is not possible
Key: MNG-5909
URL: https://issues.apache.org/jira/browse/MNG-5909
Project: Maven
Issue Type: Improvement
Components: core
Affects Versions: 3.3.3
Reporter: Konrad Windszus
Currently each type of activation (os, jdk, file, property) can only be used
once for activating a single profile.
Therefore it is not possible to activate a profile in case two different files
are existing, although since Maven 3.2.2 (MNG-4565) it is possible to combine
multiple activations of different types.
Multiple {{file}} or {{property}} should therefore be supported to allow to
express something like:
Enable {{profileA}} in case both {{fileA}} and {{fileB}} do exists
For {{jdk}} and {{os}} this is less relevant because all conditions are
combined with AND.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (MNG-5910) Using both {{exists}} and {{missing}} in the same {{file}} element should lead to an exception
Konrad Windszus created MNG-5910:
Summary: Using both {{exists}} and {{missing}} in the same
{{file}} element should lead to an exception
Key: MNG-5910
URL: https://issues.apache.org/jira/browse/MNG-5910
Project: Maven
Issue Type: Bug
Components: core
Affects Versions: 3.3.3
Reporter: Konrad Windszus
Currently it is not clear from the POM reference
(https://maven.apache.org/pom.html#Activation), that the elements {{exists}}
and {{missing}} below {{file}} are mutually exclusive, because only {{exists}}
is considered if it is there (see also
https://github.com/apache/maven/blob/master/maven-model-builder/src/main/java/org/apache/maven/model/profile/activation/FileProfileActivator.java#L91).
Please make it clearer in the POM reference that not both of them should be
used at the same time and also throw an exception during build time if that is
the case (in the effective POM).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (MSITE-771) FAQ Entry for difference between mvn site and mvn site:site is incorrect
Konrad Windszus created MSITE-771:
-
Summary: FAQ Entry for difference between mvn site and mvn
site:site is incorrect
Key: MSITE-771
URL: https://issues.apache.org/jira/browse/MSITE-771
Project: Maven Site Plugin
Issue Type: Bug
Components: documentation
Affects Versions: 3.5
Reporter: Konrad Windszus
The documentation entry 1 at
https://maven.apache.org/plugins/maven-site-plugin/faq.html is incorrect.
It states
{quote}
mvn site
Calls the site phase of the site lifecycle, which consists in the following
life cycle phases: pre-site, site, post-site and site-deploy. See Lifecycle
Reference
{quote}
Actually {{site}} will only execute the phases {{pre-site}} and {{site}} but
neither {{post-site}} nor {{site-deploy}}. All the four phases are only
executed if you execute {{site-deploy}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (MPLUGIN-297) plugin-info.html should contain a better Usage section
Konrad Windszus created MPLUGIN-297:
---
Summary: plugin-info.html should contain a better Usage section
Key: MPLUGIN-297
URL: https://issues.apache.org/jira/browse/MPLUGIN-297
Project: Maven Plugin Tools
Issue Type: Improvement
Components: Plugin Plugin
Affects Versions: 3.4
Reporter: Konrad Windszus
The usage section in the page "plugin-info.html" being generated by the
{{report}} goal of the {{maven-plugin-plugin}} contains the version information
of the plugin in both sections {{pluginManagement}} as well as {{plugins}}. I
think it is best practice to only give out the version in the
{{pluginManagement}}. Therefore please remove the version from the {{plugins}}
section.
One example for that can be seen in
https://maven.apache.org/plugins/maven-compiler-plugin/plugin-info.html.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MPLUGIN-297) plugin-info.html should contain a better Usage section
[
https://issues.apache.org/jira/browse/MPLUGIN-297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15219602#comment-15219602
]
Konrad Windszus commented on MPLUGIN-297:
-
The fix for this just requires line 600 and 601 being deleted from
https://github.com/apache/maven-plugin-tools/blob/trunk/maven-plugin-plugin/src/main/java/org/apache/maven/plugin/plugin/PluginReport.java#L600.
> plugin-info.html should contain a better Usage section
> --
>
> Key: MPLUGIN-297
> URL: https://issues.apache.org/jira/browse/MPLUGIN-297
> Project: Maven Plugin Tools
> Issue Type: Improvement
> Components: Plugin Plugin
>Affects Versions: 3.4
>Reporter: Konrad Windszus
>
> The usage section in the page "plugin-info.html" being generated by the
> {{report}} goal of the {{maven-plugin-plugin}} contains the version
> information of the plugin in both sections {{pluginManagement}} as well as
> {{plugins}}. I think it is best practice to only give out the version in the
> {{pluginManagement}}. Therefore please remove the version from the
> {{plugins}} section.
> One example for that can be seen in
> https://maven.apache.org/plugins/maven-compiler-plugin/plugin-info.html.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (MSITE-773) The evaluation of the within the settings.xml does not work
Konrad Windszus created MSITE-773:
-
Summary: The evaluation of the within the
settings.xml does not work
Key: MSITE-773
URL: https://issues.apache.org/jira/browse/MSITE-773
Project: Maven Site Plugin
Issue Type: Bug
Components: site:deploy
Affects Versions: 3.5
Reporter: Konrad Windszus
Although the m-s-p evaluates the configuration within the settings.xml it does
not correctly evaluate the {{wagonProvider}} element in the settings.xml
(https://maven.apache.org/guides/mini/guide-wagon-providers.html).
Using it leads to exceptions like this
{code}
Unable to configure Wagon: 'dav': While configuring wagon for 'nexus': Unable
to apply wagon configuration. Cannot find 'wagonProvider' in class
org.apache.maven.wagon.providers.webdav.WebDavWagon
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MSITE-773) The evaluation of the within the settings.xml does not work
[
https://issues.apache.org/jira/browse/MSITE-773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15221442#comment-15221442
]
Konrad Windszus commented on MSITE-773:
---
The according code is at
https://github.com/apache/maven-plugins/blob/trunk/maven-site-plugin/src/main/java/org/apache/maven/plugins/site/deploy/AbstractDeployMojo.java#L675.
> The evaluation of the within the settings.xml does not work
> ---
>
> Key: MSITE-773
> URL: https://issues.apache.org/jira/browse/MSITE-773
> Project: Maven Site Plugin
> Issue Type: Bug
> Components: site:deploy
>Affects Versions: 3.5
>Reporter: Konrad Windszus
>
> Although the m-s-p evaluates the configuration within the settings.xml it
> does not correctly evaluate the {{wagonProvider}} element in the settings.xml
> (https://maven.apache.org/guides/mini/guide-wagon-providers.html).
> Using it leads to exceptions like this
> {code}
> Unable to configure Wagon: 'dav': While configuring wagon for 'nexus': Unable
> to apply wagon configuration. Cannot find 'wagonProvider' in class
> org.apache.maven.wagon.providers.webdav.WebDavWagon
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (MNG-5993) Confusing error message in case of missing/empty artifactId and version in pluginManagement
Konrad Windszus created MNG-5993:
Summary: Confusing error message in case of missing/empty
artifactId and version in pluginManagement
Key: MNG-5993
URL: https://issues.apache.org/jira/browse/MNG-5993
Project: Maven
Issue Type: Improvement
Components: Dependencies
Affects Versions: 3.3.9
Reporter: Konrad Windszus
Executing any goals/phases on this pom.xml leads to a weird error
{code}
http://maven.apache.org/POM/4.0.0";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/maven-4.0.0.xsd";>
4.0.0
com.example.group
testinvalidpom
0.0.1-SNAPSHOT
{code}
The error being emitted is
{code}
[ERROR] Error resolving version for plugin ':null' from the repositories [local
(), nexus ()]: Plugin not found in any plugin
repository -> [Help 1]
{code}
Even with debug you only see something like this
{code}
[ERROR] Error resolving version for plugin ':null' from the repositories [...]:
Plugin not found in any plugin repository -> [Help 1]
org.apache.maven.plugin.version.PluginVersionResolutionException: Error
resolving version for plugin ':null' from the repositories [local
(/Users/konradwindszus/.m2/repository), nexus
(https://repo.int.netcentric.biz/nexus/content/groups/public/)]: Plugin not
found in any plugin repository
at
org.apache.maven.plugin.version.internal.DefaultPluginVersionResolver.selectVersion(DefaultPluginVersionResolver.java:236)
at
org.apache.maven.plugin.version.internal.DefaultPluginVersionResolver.resolveFromRepository(DefaultPluginVersionResolver.java:148)
at
org.apache.maven.plugin.version.internal.DefaultPluginVersionResolver.resolve(DefaultPluginVersionResolver.java:96)
at
org.apache.maven.lifecycle.internal.LifecyclePluginResolver.resolveMissingPluginVersions(LifecyclePluginResolver.java:89)
at
org.apache.maven.lifecycle.internal.DefaultLifecycleExecutionPlanCalculator.calculateExecutionPlan(DefaultLifecycleExecutionPlanCalculator.java:116)
at
org.apache.maven.lifecycle.internal.DefaultLifecycleExecutionPlanCalculator.calculateExecutionPlan(DefaultLifecycleExecutionPlanCalculator.java:135)
at
org.apache.maven.lifecycle.internal.builder.BuilderCommon.resolveBuildPlan(BuilderCommon.java:97)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:109)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
at
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:120)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:347)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:154)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:582)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:214)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:158)
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)
{code}
In this example the error is easy to spot, but for bigger pom.xmls with more
complex hierarchies it is very hard.
Some basic validation should take place that on the merged pom.xml all of
groupId, artifactId and version is available and if that is not the case, the
line number of the pom.xml together with the filename should be given out,
where the according information is missing.
A similar error is emitted in case the groupId element is missing as well or
there is an empty artifactId.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MNG-4099) Password encryption CLI switches should prompt for password if missing
[ https://issues.apache.org/jira/browse/MNG-4099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15224500#comment-15224500 ] Konrad Windszus commented on MNG-4099: -- Can you add a hint on this in http://maven.apache.org/guides/mini/guide-encryption.html? At least in the tips section but preferably also in the How-Tos (with a hint that this is only supported since Maven 3.2.1)? > Password encryption CLI switches should prompt for password if missing > -- > > Key: MNG-4099 > URL: https://issues.apache.org/jira/browse/MNG-4099 > Project: Maven > Issue Type: Improvement > Components: Command Line >Affects Versions: 2.1.0 >Reporter: Mark Hobson >Assignee: Robert Scholte >Priority: Trivial > Fix For: 3.2.1 > > > The -emp and -ep CLI switches should prompt for a password if the user omits > it. This would help to avoid having to escape shell characters in strong > passwords. > Note that the docs mention that these switches prompt for a password when > they do not: > http://maven.apache.org/guides/mini/guide-encryption.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (MNG-4099) Password encryption CLI switches should prompt for password if missing
[ https://issues.apache.org/jira/browse/MNG-4099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15224500#comment-15224500 ] Konrad Windszus edited comment on MNG-4099 at 4/4/16 4:58 PM: -- Can you add stronger hint on this in http://maven.apache.org/guides/mini/guide-encryption.html? Currently it just says: Since Maven 3.2.1 the password is an optional argument. This should be strong recommendation like: Since Maven 3.2.1 the password should no longer be provided as argument to prevent issues with the bash history and the decoding of special characters. At least in the tips section this should be explicitly mention, but preferably also in the How-Tos it should be clarified. was (Author: kwin): Can you add a hint on this in http://maven.apache.org/guides/mini/guide-encryption.html? At least in the tips section but preferably also in the How-Tos (with a hint that this is only supported since Maven 3.2.1)? > Password encryption CLI switches should prompt for password if missing > -- > > Key: MNG-4099 > URL: https://issues.apache.org/jira/browse/MNG-4099 > Project: Maven > Issue Type: Improvement > Components: Command Line >Affects Versions: 2.1.0 >Reporter: Mark Hobson >Assignee: Robert Scholte >Priority: Trivial > Fix For: 3.2.1 > > > The -emp and -ep CLI switches should prompt for a password if the user omits > it. This would help to avoid having to escape shell characters in strong > passwords. > Note that the docs mention that these switches prompt for a password when > they do not: > http://maven.apache.org/guides/mini/guide-encryption.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MNG-4099) Password encryption CLI switches should prompt for password if missing
[
https://issues.apache.org/jira/browse/MNG-4099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15224671#comment-15224671
]
Konrad Windszus commented on MNG-4099:
--
Looks much better, thanks a lot. One minor improvement though would be to link
the additional tip in both How-Tos (where this 3.2.1 feature is mentioned).
So this:
{quote}
Since Maven 3.2.1 the password is an optional argument. If not provided, Maven
will prompt for the password. Earlier versions of Maven will not prompt for a
password, so it must be typed on the command-line in plaintext. See Tips below
for more information.
{quote}
should become
{quote}
Since Maven 3.2.1 the password argument should no longer be used (see Tips
below for more information). Maven will prompt for the password. Earlier
versions of Maven will not prompt for a password, so it must be typed on the
command-line in plaintext.
{quote}
and this
{quote}
Just like --encrypt-master-password the password argument is optional since
Maven 3.2.1.
{quote}
should become
{quote}
Just like --encrypt-master-password the password argument should no longer be
used since Maven 3.2.1 (see Tips below for more information).
{quote}
> Password encryption CLI switches should prompt for password if missing
> --
>
> Key: MNG-4099
> URL: https://issues.apache.org/jira/browse/MNG-4099
> Project: Maven
> Issue Type: Improvement
> Components: Command Line
>Affects Versions: 2.1.0
>Reporter: Mark Hobson
>Assignee: Robert Scholte
>Priority: Trivial
> Fix For: 3.2.1
>
>
> The -emp and -ep CLI switches should prompt for a password if the user omits
> it. This would help to avoid having to escape shell characters in strong
> passwords.
> Note that the docs mention that these switches prompt for a password when
> they do not:
> http://maven.apache.org/guides/mini/guide-encryption.html
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MNG-4099) Password encryption CLI switches should prompt for password if missing
[
https://issues.apache.org/jira/browse/MNG-4099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15224688#comment-15224688
]
Konrad Windszus commented on MNG-4099:
--
Minor improvement for the tips section
Instead of
{quote}
Prompting for Password
In Maven before version 3.2.1 you have to give the password on command line
which means you might need to escape your password etc. and might cause
problems related to the history funcitonality of your command line processor.
Starting with Maven 3.2.1 the password is an optional argument which means if
you omit the password you will be prompted for the password which can prevent
many problems with escaping the password and history issues as well.
So we strongly recomment to use Maven 3.2.1 and above to prevent problems with
escaping special characters and of course security issues related to bash
history or environment issues in relationship with the password.
{quote}
I would rather say
{quote}
Prompting for Password
In Maven before version 3.2.1 you have to give the password on command line as
argument which means you might need to escape your password. In addition
usually the shell stores the full history of commands you have entered,
therefore anyone with access to your computer could restore the password from
the shell`s history.
Starting with Maven 3.2.1 the password is an optional argument which means if
you omit the password you will be prompted for it which prevents all the issues
mentioned above.
Therefore we strongly recommend to use Maven 3.2.1 and above to prevent
problems with escaping special characters and of course security issues related
to bash history or environment issues in relationship with the password.
{quote}
> Password encryption CLI switches should prompt for password if missing
> --
>
> Key: MNG-4099
> URL: https://issues.apache.org/jira/browse/MNG-4099
> Project: Maven
> Issue Type: Improvement
> Components: Command Line
>Affects Versions: 2.1.0
>Reporter: Mark Hobson
>Assignee: Robert Scholte
>Priority: Trivial
> Fix For: 3.2.1
>
>
> The -emp and -ep CLI switches should prompt for a password if the user omits
> it. This would help to avoid having to escape shell characters in strong
> passwords.
> Note that the docs mention that these switches prompt for a password when
> they do not:
> http://maven.apache.org/guides/mini/guide-encryption.html
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MNG-4099) Password encryption CLI switches should prompt for password if missing
[ https://issues.apache.org/jira/browse/MNG-4099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15224867#comment-15224867 ] Konrad Windszus commented on MNG-4099: -- Looks good now. Thanks a lot. > Password encryption CLI switches should prompt for password if missing > -- > > Key: MNG-4099 > URL: https://issues.apache.org/jira/browse/MNG-4099 > Project: Maven > Issue Type: Improvement > Components: Command Line >Affects Versions: 2.1.0 >Reporter: Mark Hobson >Assignee: Robert Scholte >Priority: Trivial > Fix For: 3.2.1 > > > The -emp and -ep CLI switches should prompt for a password if the user omits > it. This would help to avoid having to escape shell characters in strong > passwords. > Note that the docs mention that these switches prompt for a password when > they do not: > http://maven.apache.org/guides/mini/guide-encryption.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MPLUGIN-298) The plugin descriptor generated plugin:descriptor removes some javadoc tags
Konrad Windszus created MPLUGIN-298:
---
Summary: The plugin descriptor generated plugin:descriptor removes
some javadoc tags
Key: MPLUGIN-298
URL: https://issues.apache.org/jira/browse/MPLUGIN-298
Project: Maven Plugin Tools
Issue Type: Bug
Components: Plugin Plugin
Affects Versions: 3.4
Reporter: Konrad Windszus
The description element (1) for both the mojo itself as well as for all
parameters is extracted from the Javadoc (of the class respectively the field).
Some javadoc tags are stripped here and others are just ending up in the plugin
descriptor.
E.g. the see tags are completely ignored which means that this javadoc on the
Mojo class itself
{code}
/**
* some text with {@code code-references}
* @see http://example.com";>some external source
*/
{code}
will be converted to to the following plugin descriptor
{code}
...
some text with {@code code-references}
{code}
The see tags are completely ignored.
Although it is not documented in (1) it seems that all description elements can
deal with (escaped) html tags as well as certain javadoc tags (because those
will be automatically stripped from the output being generated by the
maven-help-plugin or by the Mojo being generated by {{plugin:helpmojo}}) and
automatically considered when the site is being generated from the plugin
descriptor. Can you clarify the reference documentation with which tags are
supported here and also extend the list of javadoc tags which can be put into
those elements
(1) - https://maven.apache.org/ref/3.3.9/maven-plugin-api/plugin.html
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MPLUGIN-298) The plugin descriptor generated plugin:descriptor removes some javadoc tags
[
https://issues.apache.org/jira/browse/MPLUGIN-298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15225852#comment-15225852
]
Konrad Windszus commented on MPLUGIN-298:
-
Another javadoc tag which is not supported is
{code}
{@inheritDoc}
{code}
> The plugin descriptor generated plugin:descriptor removes some javadoc tags
> ---
>
> Key: MPLUGIN-298
> URL: https://issues.apache.org/jira/browse/MPLUGIN-298
> Project: Maven Plugin Tools
> Issue Type: Bug
> Components: Plugin Plugin
>Affects Versions: 3.4
>Reporter: Konrad Windszus
>
> The description element (1) for both the mojo itself as well as for all
> parameters is extracted from the Javadoc (of the class respectively the
> field).
> Some javadoc tags are stripped here and others are just ending up in the
> plugin descriptor.
> E.g. the see tags are completely ignored which means that this javadoc on the
> Mojo class itself
> {code}
> /**
> * some text with {@code code-references}
> * @see http://example.com";>some external source
> */
> {code}
> will be converted to to the following plugin descriptor
> {code}
>
>
> ...
> some text with {@code code-references}
> {code}
> The see tags are completely ignored.
> Although it is not documented in (1) it seems that all description elements
> can deal with (escaped) html tags as well as certain javadoc tags (because
> those will be automatically stripped from the output being generated by the
> maven-help-plugin or by the Mojo being generated by {{plugin:helpmojo}}) and
> automatically considered when the site is being generated from the plugin
> descriptor. Can you clarify the reference documentation with which tags are
> supported here and also extend the list of javadoc tags which can be put into
> those elements
> (1) - https://maven.apache.org/ref/3.3.9/maven-plugin-api/plugin.html
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (MPLUGIN-307) The "alias" field on the annotation "@Parameter" is not considered for goal "plugin:report"
Konrad Windszus created MPLUGIN-307:
---
Summary: The "alias" field on the annotation "@Parameter" is not
considered for goal "plugin:report"
Key: MPLUGIN-307
URL: https://issues.apache.org/jira/browse/MPLUGIN-307
Project: Maven Plugin Tools
Issue Type: Bug
Components: maven-plugin-annotations, maven-plugin-tools-java
Affects Versions: 3.4
Reporter: Konrad Windszus
Although the field "alias"
(https://maven.apache.org/plugin-tools/maven-plugin-annotations/apidocs/org/apache/maven/plugins/annotations/Parameter.html#alias())
is supposed to be the preferred way of setting a property from the pom
(http://maven.apache.org/developers/mojo-api-specification.html#The_Descriptor_and_Annotations)
this is not at all considered for the goal "plugin:report" in the generated
{{goal-mojo.html}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (MPLUGIN-308) Improve mojo documentation for "plugin:report" on complex parameter types
Konrad Windszus created MPLUGIN-308:
---
Summary: Improve mojo documentation for "plugin:report" on complex
parameter types
Key: MPLUGIN-308
URL: https://issues.apache.org/jira/browse/MPLUGIN-308
Project: Maven Plugin Tools
Issue Type: Improvement
Components: Plugin Plugin
Affects Versions: 3.4
Reporter: Konrad Windszus
In case you have a Mojo with a complex parameter, i.e. a Parameter of type
{{MyParam}}, where {{MyParam}} again has some fields annotated with
{{@Parameter}}, the documentation of {{MyParam}} with its individual pieces
should be part of the mojo documentation being generated by {{plugin:report}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MPLUGIN-307) The "alias" field on the annotation "@Parameter" is not considered for goal "plugin:report"
[
https://issues.apache.org/jira/browse/MPLUGIN-307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated MPLUGIN-307:
Description: Although the field "alias"
(https://maven.apache.org/plugin-tools/maven-plugin-annotations/apidocs/org/apache/maven/plugins/annotations/Parameter.html#alias())
is supposed to be the preferred way of setting a config property from the pom
(http://maven.apache.org/developers/mojo-api-specification.html#The_Descriptor_and_Annotations)
this is not at all considered for the goal "plugin:report" in the generated
{{goal-mojo.html}}. (was: Although the field "alias"
(https://maven.apache.org/plugin-tools/maven-plugin-annotations/apidocs/org/apache/maven/plugins/annotations/Parameter.html#alias())
is supposed to be the preferred way of setting a property from the pom
(http://maven.apache.org/developers/mojo-api-specification.html#The_Descriptor_and_Annotations)
this is not at all considered for the goal "plugin:report" in the generated
{{goal-mojo.html}}.)
> The "alias" field on the annotation "@Parameter" is not considered for goal
> "plugin:report"
> ---
>
> Key: MPLUGIN-307
> URL: https://issues.apache.org/jira/browse/MPLUGIN-307
> Project: Maven Plugin Tools
> Issue Type: Bug
> Components: Plugin Plugin
>Affects Versions: 3.4
>Reporter: Konrad Windszus
>
> Although the field "alias"
> (https://maven.apache.org/plugin-tools/maven-plugin-annotations/apidocs/org/apache/maven/plugins/annotations/Parameter.html#alias())
> is supposed to be the preferred way of setting a config property from the
> pom
> (http://maven.apache.org/developers/mojo-api-specification.html#The_Descriptor_and_Annotations)
> this is not at all considered for the goal "plugin:report" in the generated
> {{goal-mojo.html}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MPLUGIN-307) The "alias" field on the annotation "@Parameter" is not considered for goal "plugin:report"
[
https://issues.apache.org/jira/browse/MPLUGIN-307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated MPLUGIN-307:
Component/s: (was: maven-plugin-annotations)
(was: maven-plugin-tools-java)
Plugin Plugin
> The "alias" field on the annotation "@Parameter" is not considered for goal
> "plugin:report"
> ---
>
> Key: MPLUGIN-307
> URL: https://issues.apache.org/jira/browse/MPLUGIN-307
> Project: Maven Plugin Tools
> Issue Type: Bug
> Components: Plugin Plugin
>Affects Versions: 3.4
>Reporter: Konrad Windszus
>
> Although the field "alias"
> (https://maven.apache.org/plugin-tools/maven-plugin-annotations/apidocs/org/apache/maven/plugins/annotations/Parameter.html#alias())
> is supposed to be the preferred way of setting a property from the pom
> (http://maven.apache.org/developers/mojo-api-specification.html#The_Descriptor_and_Annotations)
> this is not at all considered for the goal "plugin:report" in the generated
> {{goal-mojo.html}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MPLUGIN-298) The plugin descriptor generated by plugin:descriptor removes some javadoc tags
[
https://issues.apache.org/jira/browse/MPLUGIN-298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated MPLUGIN-298:
Summary: The plugin descriptor generated by plugin:descriptor removes some
javadoc tags (was: The plugin descriptor generated plugin:descriptor removes
some javadoc tags)
> The plugin descriptor generated by plugin:descriptor removes some javadoc tags
> --
>
> Key: MPLUGIN-298
> URL: https://issues.apache.org/jira/browse/MPLUGIN-298
> Project: Maven Plugin Tools
> Issue Type: Bug
> Components: Plugin Plugin
>Affects Versions: 3.4
>Reporter: Konrad Windszus
>
> The description element (1) for both the mojo itself as well as for all
> parameters is extracted from the Javadoc (of the class respectively the
> field).
> Some javadoc tags are stripped here and others are just ending up in the
> plugin descriptor.
> E.g. the see tags are completely ignored which means that this javadoc on the
> Mojo class itself
> {code}
> /**
> * some text with {@code code-references}
> * @see http://example.com";>some external source
> */
> {code}
> will be converted to to the following plugin descriptor
> {code}
>
>
> ...
> some text with {@code code-references}
> {code}
> The see tags are completely ignored.
> Although it is not documented in (1) it seems that all description elements
> can deal with (escaped) html tags as well as certain javadoc tags (because
> those will be automatically stripped from the output being generated by the
> maven-help-plugin or by the Mojo being generated by {{plugin:helpmojo}}) and
> automatically considered when the site is being generated from the plugin
> descriptor. Can you clarify the reference documentation with which tags are
> supported here and also extend the list of javadoc tags which can be put into
> those elements
> (1) - https://maven.apache.org/ref/3.3.9/maven-plugin-api/plugin.html
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MPLUGIN-308) Improve mojo documentation for "plugin:report" on complex parameter types
[
https://issues.apache.org/jira/browse/MPLUGIN-308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated MPLUGIN-308:
Description:
In case you have a Mojo with a custom complex parameter, i.e. a Parameter of
type {{MyParam}}, where {{MyParam}} again has some fields annotated with
{{@Parameter}}, the documentation of {{MyParam}} with its individual pieces
should be part of the mojo documentation being generated by {{plugin:report}}.
See also
http://stackoverflow.com/questions/20696862/inject-parameter-in-different-class-in-maven-plugin.
was:In case you have a Mojo with a complex parameter, i.e. a Parameter of
type {{MyParam}}, where {{MyParam}} again has some fields annotated with
{{@Parameter}}, the documentation of {{MyParam}} with its individual pieces
should be part of the mojo documentation being generated by {{plugin:report}}.
> Improve mojo documentation for "plugin:report" on complex parameter types
> -
>
> Key: MPLUGIN-308
> URL: https://issues.apache.org/jira/browse/MPLUGIN-308
> Project: Maven Plugin Tools
> Issue Type: Improvement
> Components: Plugin Plugin
>Affects Versions: 3.4
>Reporter: Konrad Windszus
>
> In case you have a Mojo with a custom complex parameter, i.e. a Parameter of
> type {{MyParam}}, where {{MyParam}} again has some fields annotated with
> {{@Parameter}}, the documentation of {{MyParam}} with its individual pieces
> should be part of the mojo documentation being generated by {{plugin:report}}.
> See also
> http://stackoverflow.com/questions/20696862/inject-parameter-in-different-class-in-maven-plugin.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MPLUGIN-307) The "alias" field on the annotation "@Parameter" is not considered for goal "plugin:report"
[
https://issues.apache.org/jira/browse/MPLUGIN-307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15395632#comment-15395632
]
Konrad Windszus commented on MPLUGIN-307:
-
Thanks a lot for the quick fix. Looks good from the code perspective at first
glance (though I haven't tried out the Snapshot yet).
[~gboue] Would you mind setting this JIRA to the right status?
> The "alias" field on the annotation "@Parameter" is not considered for goal
> "plugin:report"
> ---
>
> Key: MPLUGIN-307
> URL: https://issues.apache.org/jira/browse/MPLUGIN-307
> Project: Maven Plugin Tools
> Issue Type: Bug
> Components: Plugin Plugin
>Affects Versions: 3.4
>Reporter: Konrad Windszus
>Assignee: Guillaume Boué
> Fix For: 3.5
>
>
> Although the field "alias"
> (https://maven.apache.org/plugin-tools/maven-plugin-annotations/apidocs/org/apache/maven/plugins/annotations/Parameter.html#alias())
> is supposed to be the preferred way of setting a config property from the
> pom
> (http://maven.apache.org/developers/mojo-api-specification.html#The_Descriptor_and_Annotations)
> this is not at all considered for the goal "plugin:report" in the generated
> {{goal-mojo.html}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (MPLUGIN-311) System Requirements: Minimum Maven version is not correctly extracted from effective pom
Konrad Windszus created MPLUGIN-311:
---
Summary: System Requirements: Minimum Maven version is not
correctly extracted from effective pom
Key: MPLUGIN-311
URL: https://issues.apache.org/jira/browse/MPLUGIN-311
Project: Maven Plugin Tools
Issue Type: Improvement
Components: Plugin Plugin
Affects Versions: 3.4
Reporter: Konrad Windszus
Currently the minimum Maven version only seems to be extracted from the current
{{prerequisites->maven}} element in the current pom.xml. In case this is set in
some parent pom, it falls back to the default of version {{2.0}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MPLUGIN-311) Goal "plugin:report": System Requirements -> Minimum Maven version is not correctly extracted from effective pom
[
https://issues.apache.org/jira/browse/MPLUGIN-311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated MPLUGIN-311:
Summary: Goal "plugin:report": System Requirements -> Minimum Maven version
is not correctly extracted from effective pom (was: System Requirements:
Minimum Maven version is not correctly extracted from effective pom)
> Goal "plugin:report": System Requirements -> Minimum Maven version is not
> correctly extracted from effective pom
>
>
> Key: MPLUGIN-311
> URL: https://issues.apache.org/jira/browse/MPLUGIN-311
> Project: Maven Plugin Tools
> Issue Type: Improvement
> Components: Plugin Plugin
>Affects Versions: 3.4
>Reporter: Konrad Windszus
>
> Currently the minimum Maven version only seems to be extracted from the
> current {{prerequisites->maven}} element in the current pom.xml. In case this
> is set in some parent pom, it falls back to the default of version {{2.0}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MPLUGIN-311) Goal "plugin:report": System Requirements -> Minimum Maven version is not correctly extracted from effective pom
[
https://issues.apache.org/jira/browse/MPLUGIN-311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated MPLUGIN-311:
Description: Currently the minimum Maven version being exposed in
{{plugin-info.html}} through the goal {{report}} only seems to be extracted
from the current {{prerequisites->maven}} element in the current pom.xml. In
case this is set in some parent pom, it falls back to the default of version
{{2.0}}. (was: Currently the minimum Maven version only seems to be extracted
from the current {{prerequisites->maven}} element in the current pom.xml. In
case this is set in some parent pom, it falls back to the default of version
{{2.0}}.)
> Goal "plugin:report": System Requirements -> Minimum Maven version is not
> correctly extracted from effective pom
>
>
> Key: MPLUGIN-311
> URL: https://issues.apache.org/jira/browse/MPLUGIN-311
> Project: Maven Plugin Tools
> Issue Type: Improvement
> Components: Plugin Plugin
>Affects Versions: 3.4
>Reporter: Konrad Windszus
>
> Currently the minimum Maven version being exposed in {{plugin-info.html}}
> through the goal {{report}} only seems to be extracted from the current
> {{prerequisites->maven}} element in the current pom.xml. In case this is set
> in some parent pom, it falls back to the default of version {{2.0}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MPLUGIN-311) Goal "plugin:report": System Requirements -> Minimum Maven version is not correctly extracted from effective pom
[
https://issues.apache.org/jira/browse/MPLUGIN-311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15431073#comment-15431073
]
Konrad Windszus commented on MPLUGIN-311:
-
The issue seems to be in
https://github.com/apache/maven-plugin-tools/blob/trunk/maven-plugin-plugin/src/main/java/org/apache/maven/plugin/plugin/PluginReport.java#L672.
> Goal "plugin:report": System Requirements -> Minimum Maven version is not
> correctly extracted from effective pom
>
>
> Key: MPLUGIN-311
> URL: https://issues.apache.org/jira/browse/MPLUGIN-311
> Project: Maven Plugin Tools
> Issue Type: Improvement
> Components: Plugin Plugin
>Affects Versions: 3.4
>Reporter: Konrad Windszus
>
> Currently the minimum Maven version being exposed in {{plugin-info.html}}
> through the goal {{report}} only seems to be extracted from the current
> {{prerequisites->maven}} element in the current pom.xml. In case this is set
> in some parent pom, it falls back to the default of version {{2.0}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (MPLUGIN-311) Goal "plugin:report": System Requirements -> Minimum Maven version is not correctly extracted from effective pom
[
https://issues.apache.org/jira/browse/MPLUGIN-311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus resolved MPLUGIN-311.
-
Resolution: Invalid
> Goal "plugin:report": System Requirements -> Minimum Maven version is not
> correctly extracted from effective pom
>
>
> Key: MPLUGIN-311
> URL: https://issues.apache.org/jira/browse/MPLUGIN-311
> Project: Maven Plugin Tools
> Issue Type: Improvement
> Components: Plugin Plugin
>Affects Versions: 3.4
>Reporter: Konrad Windszus
>
> Currently the minimum Maven version being exposed in {{plugin-info.html}}
> through the goal {{report}} only seems to be extracted from the current
> {{prerequisites->maven}} element in the current pom.xml. In case this is set
> in some parent pom, it falls back to the default of version {{2.0}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MPLUGIN-311) Goal "plugin:report": System Requirements -> Minimum Maven version is not correctly extracted from effective pom
[
https://issues.apache.org/jira/browse/MPLUGIN-311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15431109#comment-15431109
]
Konrad Windszus commented on MPLUGIN-311:
-
Actually it works as expected because the {{prerequisites}} section is not
supposed to be inherited (https://maven.apache.org/pom.html#Inheritance).
> Goal "plugin:report": System Requirements -> Minimum Maven version is not
> correctly extracted from effective pom
>
>
> Key: MPLUGIN-311
> URL: https://issues.apache.org/jira/browse/MPLUGIN-311
> Project: Maven Plugin Tools
> Issue Type: Improvement
> Components: Plugin Plugin
>Affects Versions: 3.4
>Reporter: Konrad Windszus
>
> Currently the minimum Maven version being exposed in {{plugin-info.html}}
> through the goal {{report}} only seems to be extracted from the current
> {{prerequisites->maven}} element in the current pom.xml. In case this is set
> in some parent pom, it falls back to the default of version {{2.0}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SCM-807) JGit impl check-in fails unless the Maven project is in the working copy root
[ https://issues.apache.org/jira/browse/SCM-807?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16598342#comment-16598342 ] Konrad Windszus commented on SCM-807: - Ping: Could someone look at this maybe. At least for me the fix works fine. > JGit impl check-in fails unless the Maven project is in the working copy root > - > > Key: SCM-807 > URL: https://issues.apache.org/jira/browse/SCM-807 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-provider-gitexe >Affects Versions: 1.9.4 >Reporter: Richard DiCroce >Priority: Major > Attachments: scm-807.txt > > > Another problem exposed by maven-release-plugin: the JGit SCM > implementation's check-in fails unless the Maven project is in the working > copy root because it confuses the working copy's location with the Maven > project's location. > The attached patch resolves the issue. Combined with the patch attached to > SCM-806, release:prepare now mostly succeeds with the JGit implementation. > There is still a problem with the POM not being transformed correctly, but > that's a problem in maven-release-plugin. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (SCM-860) add goal creates creates wrong paths if parent pom is not at root directory
[
https://issues.apache.org/jira/browse/SCM-860?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16598346#comment-16598346
]
Konrad Windszus commented on SCM-860:
-
With JGit this pretty much seems like the issue reported in SCM-807.
Unfortunately the patch has still not been applied after almost 3 years.
> add goal creates creates wrong paths if parent pom is not at root directory
> ---
>
> Key: SCM-860
> URL: https://issues.apache.org/jira/browse/SCM-860
> Project: Maven SCM
> Issue Type: Bug
> Components: maven-scm-provider-jgit
>Affects Versions: 1.9.5
> Environment: Windows, mvn 3.5.2, mvn:scm 1.9.5
>Reporter: Michael Kutschke
>Priority: Major
> Fix For: waiting-for-feedback
>
>
> For reference:
> [https://stackoverflow.com/questions/48689960/maven-scm-plugin-and-relative-paths]
>
> When the pom is not at the root directory, the add goal creates a command
> that includes a relative path from the pom's directory instead of the root
> directory. Either that, or relative paths like /.. are dropped.
> Directory structure of the project:
> * .git
> ** src
> *** parent
> pom.xml
> *** submodule
> pom.xml
> addme.product
> Example pom:
>
> {code:xml}
> http://maven.apache.org/POM/4.0.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/xsd/maven-4.0.0.xsd";>
>
> scm:git:file://../../.git
>
> 4.0.0
> grp
> artif
> 1.0.0
> pom
>
> ../submodule
>
>
>
>
> org.apache.maven.plugins
> maven-release-plugin
> 2.5.3
>
> true
> true
>
>
> org.eclipse.tycho:tycho-versions-plugin:${tycho-version}:update-eclipse-metadata
>
> org.apache.maven.plugins:maven-scm-plugin:1.9.5:add
>
>
>
>
> org.eclipse.tycho:tycho-versions-plugin:${tycho-version}:update-eclipse-metadata
>
> org.apache.maven.plugins:maven-scm-plugin:1.9.5:add
>
>
>
>
>
>org.apache.maven.plugins
>maven-scm-plugin
>1.9.5
>
>
>default-cli
>
> add
> checkin
>
>
>
> **/META-INF/MANIFEST.MF,**/feature.xml,**/*.product
> **/target/**
>Changing the version to reflect the pom versions
> for the release
>${project.basedir}/../..
>
> ${project.basedir}/../..
>
>
>
>
>
>
> {code}
> Leads to output like this:
> [INFO] Executing: cmd.exe /X /C "git add --
> src\parent\src\submodule\addme.product"
> [INFO] Working directory: D:\git\project\src\parent\..\..
> [ERROR] Provider message:
> [ERROR] The git-add command failed.
> [ERROR] Command output:
> [ERROR] fatal: pathspec 'src\parent\src\submodule\addme.product' did not
> match any files
> I think this is the jgit provider, but am unsure how to check that it is not
> the gitexe provider.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MRESOLVER-56) Support SHA256 and SHA512 as hashes
[ https://issues.apache.org/jira/browse/MRESOLVER-56?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Windszus updated MRESOLVER-56: - Summary: Support SHA256 and SHA512 as hashes (was: Support SHA256 and SHA512) > Support SHA256 and SHA512 as hashes > --- > > Key: MRESOLVER-56 > URL: https://issues.apache.org/jira/browse/MRESOLVER-56 > Project: Maven Resolver > Issue Type: Improvement > Components: resolver >Affects Versions: Maven Artifact Resolver 1.1.1 >Reporter: Konrad Windszus >Priority: Major > > As both supported checksums on remote repositories (namely MD5 and SHA1 have > known flaws) it would be nice if the Maven Resolver could also leverage other > hashes like SHA256 and SHA512. > Although those hashes aren't part of the official Maven 2 repository layout > (https://cwiki.apache.org/confluence/display/MAVENOLD/Repository+Layout+-+Final, > couldn't find any newer/other spec) I don't see how an additional .SHA256 > file could introduce backwards compatibility issues with older clients. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (MRESOLVER-56) Support SHA256 and SHA512
Konrad Windszus created MRESOLVER-56: Summary: Support SHA256 and SHA512 Key: MRESOLVER-56 URL: https://issues.apache.org/jira/browse/MRESOLVER-56 Project: Maven Resolver Issue Type: Improvement Components: resolver Affects Versions: Maven Artifact Resolver 1.1.1 Reporter: Konrad Windszus As both supported checksums on remote repositories (namely MD5 and SHA1 have known flaws) it would be nice if the Maven Resolver could also leverage other hashes like SHA256 and SHA512. Although those hashes aren't part of the official Maven 2 repository layout (https://cwiki.apache.org/confluence/display/MAVENOLD/Repository+Layout+-+Final, couldn't find any newer/other spec) I don't see how an additional .SHA256 file could introduce backwards compatibility issues with older clients. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MRESOLVER-56) Support SHA256 and SHA512 as hashes
[ https://issues.apache.org/jira/browse/MRESOLVER-56?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Windszus updated MRESOLVER-56: - Description: As both supported checksums on remote repositories (namely MD5 and SHA1 have known flaws) it would be nice if the Maven Resolver could also leverage other hashes like SHA256 and SHA512. Although those hashes aren't part of the official Maven 2 repository layout (https://cwiki.apache.org/confluence/display/MAVENOLD/Repository+Layout+-+Final, couldn't find any newer/other spec) I don't see how an additional .SHA256 file could introduce backwards compatibility issues with older clients. I think this namely would mean you would also return SHA512 and SHA256 if they exist and are supported by Java. The longer the hash the better it is, therefore the hashes should be checked in the following order # SHA512 # SHA256 # SHA1 # MD5 was: As both supported checksums on remote repositories (namely MD5 and SHA1 have known flaws) it would be nice if the Maven Resolver could also leverage other hashes like SHA256 and SHA512. Although those hashes aren't part of the official Maven 2 repository layout (https://cwiki.apache.org/confluence/display/MAVENOLD/Repository+Layout+-+Final, couldn't find any newer/other spec) I don't see how an additional .SHA256 file could introduce backwards compatibility issues with older clients. > Support SHA256 and SHA512 as hashes > --- > > Key: MRESOLVER-56 > URL: https://issues.apache.org/jira/browse/MRESOLVER-56 > Project: Maven Resolver > Issue Type: Improvement > Components: resolver >Affects Versions: Maven Artifact Resolver 1.1.1 >Reporter: Konrad Windszus >Priority: Major > > As both supported checksums on remote repositories (namely MD5 and SHA1 have > known flaws) it would be nice if the Maven Resolver could also leverage other > hashes like SHA256 and SHA512. > Although those hashes aren't part of the official Maven 2 repository layout > (https://cwiki.apache.org/confluence/display/MAVENOLD/Repository+Layout+-+Final, > couldn't find any newer/other spec) I don't see how an additional .SHA256 > file could introduce backwards compatibility issues with older clients. > I think this namely would mean you would also return SHA512 and SHA256 if > they exist and are supported by Java. The longer the hash the better it is, > therefore the hashes should be checked in the following order > # SHA512 > # SHA256 > # SHA1 > # MD5 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MRESOLVER-56) Support SHA256 and SHA512 as hashes
[ https://issues.apache.org/jira/browse/MRESOLVER-56?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Windszus updated MRESOLVER-56: - Description: As both supported checksums on remote repositories (namely MD5 and SHA1 have known flaws) it would be nice if the Maven Resolver could also leverage other hashes like SHA256 and SHA512. Although those hashes aren't part of the official Maven 2 repository layout (https://cwiki.apache.org/confluence/display/MAVENOLD/Repository+Layout+-+Final, couldn't find any newer/other spec) I don't see how an additional .SHA256 file could introduce backwards compatibility issues with older clients. I think this namely would mean you would also return SHA512 and SHA256 if they exist and leverage if they are supported by the JRE. The longer the hash the better it is, therefore the hashes should be checked in the following order # SHA512 # SHA256 # SHA1 # MD5 This would need to be considered in the API within https://github.com/apache/maven-resolver/blob/0c2373f6c66f20953b1a7e443ea1de8672d1b072/maven-resolver-spi/src/main/java/org/eclipse/aether/spi/connector/layout/RepositoryLayout.java#L165 and https://github.com/apache/maven-resolver/blob/0c2373f6c66f20953b1a7e443ea1de8672d1b072/maven-resolver-spi/src/main/java/org/eclipse/aether/spi/connector/layout/RepositoryLayout.java#L178. was: As both supported checksums on remote repositories (namely MD5 and SHA1 have known flaws) it would be nice if the Maven Resolver could also leverage other hashes like SHA256 and SHA512. Although those hashes aren't part of the official Maven 2 repository layout (https://cwiki.apache.org/confluence/display/MAVENOLD/Repository+Layout+-+Final, couldn't find any newer/other spec) I don't see how an additional .SHA256 file could introduce backwards compatibility issues with older clients. I think this namely would mean you would also return SHA512 and SHA256 if they exist and are supported by Java. The longer the hash the better it is, therefore the hashes should be checked in the following order # SHA512 # SHA256 # SHA1 # MD5 > Support SHA256 and SHA512 as hashes > --- > > Key: MRESOLVER-56 > URL: https://issues.apache.org/jira/browse/MRESOLVER-56 > Project: Maven Resolver > Issue Type: Improvement > Components: resolver >Affects Versions: Maven Artifact Resolver 1.1.1 >Reporter: Konrad Windszus >Priority: Major > > As both supported checksums on remote repositories (namely MD5 and SHA1 have > known flaws) it would be nice if the Maven Resolver could also leverage other > hashes like SHA256 and SHA512. > Although those hashes aren't part of the official Maven 2 repository layout > (https://cwiki.apache.org/confluence/display/MAVENOLD/Repository+Layout+-+Final, > couldn't find any newer/other spec) I don't see how an additional .SHA256 > file could introduce backwards compatibility issues with older clients. > I think this namely would mean you would also return SHA512 and SHA256 if > they exist and leverage if they are supported by the JRE. The longer the hash > the better it is, therefore the hashes should be checked in the following > order > # SHA512 > # SHA256 > # SHA1 > # MD5 > This would need to be considered in the API within > https://github.com/apache/maven-resolver/blob/0c2373f6c66f20953b1a7e443ea1de8672d1b072/maven-resolver-spi/src/main/java/org/eclipse/aether/spi/connector/layout/RepositoryLayout.java#L165 > and > https://github.com/apache/maven-resolver/blob/0c2373f6c66f20953b1a7e443ea1de8672d1b072/maven-resolver-spi/src/main/java/org/eclipse/aether/spi/connector/layout/RepositoryLayout.java#L178. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MRESOLVER-56) Support SHA256 and SHA512 as hashes
[
https://issues.apache.org/jira/browse/MRESOLVER-56?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated MRESOLVER-56:
-
Description:
As both supported checksums on remote repositories (namely MD5 and SHA1) have
known flaws it would be nice if the Maven Resolver could also leverage other
hashes like SHA256 and SHA512.
Although those hashes aren't part of the official Maven 2 repository layout
(https://cwiki.apache.org/confluence/display/MAVENOLD/Repository+Layout+-+Final,
couldn't find any newer/other spec) I don't see how an additional {{.sha256}}
or {{.sha512}} file could introduce backwards compatibility issues with older
clients.
I think this namely would mean you would also return SHA512 and SHA256 if they
exist and leverage if they are supported by the JRE. The longer the hash the
better it is, therefore the hashes should be checked in the following order
# SHA512
# SHA256
# SHA1
# MD5
This would need to be considered in the API within
https://github.com/apache/maven-resolver/blob/0c2373f6c66f20953b1a7e443ea1de8672d1b072/maven-resolver-spi/src/main/java/org/eclipse/aether/spi/connector/layout/RepositoryLayout.java#L165
and
https://github.com/apache/maven-resolver/blob/0c2373f6c66f20953b1a7e443ea1de8672d1b072/maven-resolver-spi/src/main/java/org/eclipse/aether/spi/connector/layout/RepositoryLayout.java#L178.
was:
As both supported checksums on remote repositories (namely MD5 and SHA1 have
known flaws) it would be nice if the Maven Resolver could also leverage other
hashes like SHA256 and SHA512.
Although those hashes aren't part of the official Maven 2 repository layout
(https://cwiki.apache.org/confluence/display/MAVENOLD/Repository+Layout+-+Final,
couldn't find any newer/other spec) I don't see how an additional .SHA256 file
could introduce backwards compatibility issues with older clients.
I think this namely would mean you would also return SHA512 and SHA256 if they
exist and leverage if they are supported by the JRE. The longer the hash the
better it is, therefore the hashes should be checked in the following order
# SHA512
# SHA256
# SHA1
# MD5
This would need to be considered in the API within
https://github.com/apache/maven-resolver/blob/0c2373f6c66f20953b1a7e443ea1de8672d1b072/maven-resolver-spi/src/main/java/org/eclipse/aether/spi/connector/layout/RepositoryLayout.java#L165
and
https://github.com/apache/maven-resolver/blob/0c2373f6c66f20953b1a7e443ea1de8672d1b072/maven-resolver-spi/src/main/java/org/eclipse/aether/spi/connector/layout/RepositoryLayout.java#L178.
> Support SHA256 and SHA512 as hashes
> ---
>
> Key: MRESOLVER-56
> URL: https://issues.apache.org/jira/browse/MRESOLVER-56
> Project: Maven Resolver
> Issue Type: Improvement
> Components: resolver
>Affects Versions: Maven Artifact Resolver 1.1.1
>Reporter: Konrad Windszus
>Priority: Major
>
> As both supported checksums on remote repositories (namely MD5 and SHA1) have
> known flaws it would be nice if the Maven Resolver could also leverage other
> hashes like SHA256 and SHA512.
> Although those hashes aren't part of the official Maven 2 repository layout
> (https://cwiki.apache.org/confluence/display/MAVENOLD/Repository+Layout+-+Final,
> couldn't find any newer/other spec) I don't see how an additional
> {{.sha256}} or {{.sha512}} file could introduce backwards compatibility
> issues with older clients.
> I think this namely would mean you would also return SHA512 and SHA256 if
> they exist and leverage if they are supported by the JRE. The longer the hash
> the better it is, therefore the hashes should be checked in the following
> order
> # SHA512
> # SHA256
> # SHA1
> # MD5
> This would need to be considered in the API within
> https://github.com/apache/maven-resolver/blob/0c2373f6c66f20953b1a7e443ea1de8672d1b072/maven-resolver-spi/src/main/java/org/eclipse/aether/spi/connector/layout/RepositoryLayout.java#L165
> and
> https://github.com/apache/maven-resolver/blob/0c2373f6c66f20953b1a7e443ea1de8672d1b072/maven-resolver-spi/src/main/java/org/eclipse/aether/spi/connector/layout/RepositoryLayout.java#L178.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MRESOLVER-56) Support SHA256 and SHA512 as checksums
[
https://issues.apache.org/jira/browse/MRESOLVER-56?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated MRESOLVER-56:
-
Summary: Support SHA256 and SHA512 as checksums (was: Support SHA256 and
SHA512 as hashes)
> Support SHA256 and SHA512 as checksums
> --
>
> Key: MRESOLVER-56
> URL: https://issues.apache.org/jira/browse/MRESOLVER-56
> Project: Maven Resolver
> Issue Type: Improvement
> Components: resolver
>Affects Versions: Maven Artifact Resolver 1.1.1
>Reporter: Konrad Windszus
>Priority: Major
>
> As both supported checksums on remote repositories (namely MD5 and SHA1) have
> known flaws it would be nice if the Maven Resolver could also leverage other
> hashes like SHA256 and SHA512.
> Although those hashes aren't part of the official Maven 2 repository layout
> (https://cwiki.apache.org/confluence/display/MAVENOLD/Repository+Layout+-+Final,
> couldn't find any newer/other spec) I don't see how an additional
> {{.sha256}} or {{.sha512}} file could introduce backwards compatibility
> issues with older clients.
> I think this namely would mean you would also return SHA512 and SHA256 if
> they exist and leverage if they are supported by the JRE. The longer the hash
> the better it is, therefore the hashes should be checked in the following
> order
> # SHA512
> # SHA256
> # SHA1
> # MD5
> This would need to be considered in the API within
> https://github.com/apache/maven-resolver/blob/0c2373f6c66f20953b1a7e443ea1de8672d1b072/maven-resolver-spi/src/main/java/org/eclipse/aether/spi/connector/layout/RepositoryLayout.java#L165
> and
> https://github.com/apache/maven-resolver/blob/0c2373f6c66f20953b1a7e443ea1de8672d1b072/maven-resolver-spi/src/main/java/org/eclipse/aether/spi/connector/layout/RepositoryLayout.java#L178.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MPOM-205) create SHA-512 checksum for source-release archive(s) in target/checkout/target/ during release
[ https://issues.apache.org/jira/browse/MPOM-205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16602321#comment-16602321 ] Konrad Windszus commented on MPOM-205: -- Do you plan to update https://maven.apache.org/developers/release/maven-project-release-procedure.html#Copy_the_source_release_to_the_Apache_Distribution_Area as well to reflect how the checksums should be handled? Also I wonder how you do distribution to the dist in case the release has not been done by a PMC member. Then some PMC member would need to rebuild. Also checking the repository doesn't allow you to validate the SHA512 checksums. > create SHA-512 checksum for source-release archive(s) in > target/checkout/target/ during release > --- > > Key: MPOM-205 > URL: https://issues.apache.org/jira/browse/MPOM-205 > Project: Maven POMs > Issue Type: New Feature > Components: asf >Affects Versions: ASF-20 >Reporter: Hervé Boutemy >Assignee: Hervé Boutemy >Priority: Major > Fix For: ASF-21 > > > currently, during Apache release, checksums are not created in target/ > directory: checksums are created on the fly during deploy to the Maven > repository (for absolutely every artifact, be it "normal" artifacts or source > release) > while source release archive and its signature are available in target/ (or > target/checkout/target during release with Maven Release Plugin), checksums > are not there: this gives people the bad habit to download everything (not > only checksums) from Apache Nexus repository after deploy to copy to Apache > /dist/ > it would be useful to have the checksums for source release available in > target/ (then in target/checkout/target during release) > this would also prepare having new Apache checksums requirements for Apache > mirroring: http://www.apache.org/dev/release-distribution#sigs-and-sums > sha256 and sha512 are not used for Maven repositories, but they are required > for Apache source release distribution > Notice: .sha256 and .sha512 files are not only not supported for Maven > repositories, but even not supported: they are considered as artifacts, not > checksums, then require md5 and sha1 checksum files and .asc detached > signature... > Then the .sha512 file is not to be deployed to the Maven repository, only > Apache /dist/ -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MRESOLVER-56) Support SHA256 and SHA512 as checksums
[
https://issues.apache.org/jira/browse/MRESOLVER-56?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16616272#comment-16616272
]
Konrad Windszus commented on MRESOLVER-56:
--
I can test a branch. Where is it located?
> Support SHA256 and SHA512 as checksums
> --
>
> Key: MRESOLVER-56
> URL: https://issues.apache.org/jira/browse/MRESOLVER-56
> Project: Maven Resolver
> Issue Type: Improvement
> Components: resolver
>Affects Versions: Maven Artifact Resolver 1.1.1
>Reporter: Konrad Windszus
>Priority: Major
>
> As both supported checksums on remote repositories (namely MD5 and SHA1) have
> known flaws it would be nice if the Maven Resolver could also leverage other
> hashes like SHA256 and SHA512.
> Although those hashes aren't part of the official Maven 2 repository layout
> (https://cwiki.apache.org/confluence/display/MAVENOLD/Repository+Layout+-+Final,
> couldn't find any newer/other spec) I don't see how an additional
> {{.sha256}} or {{.sha512}} file could introduce backwards compatibility
> issues with older clients.
> I think this namely would mean you would also return SHA512 and SHA256 if
> they exist and leverage if they are supported by the JRE. The longer the hash
> the better it is, therefore the hashes should be checked in the following
> order
> # SHA512
> # SHA256
> # SHA1
> # MD5
> This would need to be considered in the API within
> https://github.com/apache/maven-resolver/blob/0c2373f6c66f20953b1a7e443ea1de8672d1b072/maven-resolver-spi/src/main/java/org/eclipse/aether/spi/connector/layout/RepositoryLayout.java#L165
> and
> https://github.com/apache/maven-resolver/blob/0c2373f6c66f20953b1a7e443ea1de8672d1b072/maven-resolver-spi/src/main/java/org/eclipse/aether/spi/connector/layout/RepositoryLayout.java#L178.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MGPG-60) Outdated issue track URL
[ https://issues.apache.org/jira/browse/MGPG-60?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16642879#comment-16642879 ] Konrad Windszus commented on MGPG-60: - This has been fixed in https://github.com/apache/maven-gpg-plugin/commit/dd91b9a958d8b7c849e28b03a485b6abad5e8015 quite some time ago. With the next release it should appear correctly on the site. > Outdated issue track URL > > > Key: MGPG-60 > URL: https://issues.apache.org/jira/browse/MGPG-60 > Project: Maven GPG Plugin > Issue Type: Bug >Reporter: Víctor A. Rodríguez >Priority: Trivial > Labels: documentation > > At https://maven.apache.org/plugins/maven-gpg-plugin/issue-tracking.html the > current issue tracker URL is http://jira.codehaus.org/browse/MGPG, being the > right one https://issues.apache.org/jira/browse/MGPG -- 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] [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] (MRESOLVER-56) Support SHA256 and SHA512 as checksums
[
https://issues.apache.org/jira/browse/MRESOLVER-56?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16676832#comment-16676832
]
Konrad Windszus commented on MRESOLVER-56:
--
The according Nexus changes can be tracked in
https://jira.apache.org/jira/browse/INFRA-14923.
> Support SHA256 and SHA512 as checksums
> --
>
> Key: MRESOLVER-56
> URL: https://issues.apache.org/jira/browse/MRESOLVER-56
> Project: Maven Resolver
> Issue Type: Improvement
> Components: resolver
>Affects Versions: Maven Artifact Resolver 1.1.1
>Reporter: Konrad Windszus
>Priority: Major
>
> As both supported checksums on remote repositories (namely MD5 and SHA1) have
> known flaws it would be nice if the Maven Resolver could also leverage other
> hashes like SHA256 and SHA512.
> Although those hashes aren't part of the official Maven 2 repository layout
> (https://cwiki.apache.org/confluence/display/MAVENOLD/Repository+Layout+-+Final,
> couldn't find any newer/other spec) I don't see how an additional
> {{.sha256}} or {{.sha512}} file could introduce backwards compatibility
> issues with older clients.
> I think this namely would mean you would also return SHA512 and SHA256 if
> they exist and leverage if they are supported by the JRE. The longer the hash
> the better it is, therefore the hashes should be checked in the following
> order
> # SHA512
> # SHA256
> # SHA1
> # MD5
> This would need to be considered in the API within
> https://github.com/apache/maven-resolver/blob/0c2373f6c66f20953b1a7e443ea1de8672d1b072/maven-resolver-spi/src/main/java/org/eclipse/aether/spi/connector/layout/RepositoryLayout.java#L165
> and
> https://github.com/apache/maven-resolver/blob/0c2373f6c66f20953b1a7e443ea1de8672d1b072/maven-resolver-spi/src/main/java/org/eclipse/aether/spi/connector/layout/RepositoryLayout.java#L178.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MJAR-193) Allow other mojos to contribute to the manifest
[ https://issues.apache.org/jira/browse/MJAR-193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16681659#comment-16681659 ] Konrad Windszus commented on MJAR-193: -- [~rfscholte] Where should this new interface live in your opinion? Should it be part of the maven-jar-plugin, maven-archiver (https://github.com/apache/maven-archiver) or plexus-archiver (https://github.com/codehaus-plexus/plexus-archiver)? > Allow other mojos to contribute to the manifest > --- > > Key: MJAR-193 > URL: https://issues.apache.org/jira/browse/MJAR-193 > Project: Maven JAR Plugin > Issue Type: Improvement >Reporter: Carsten Ziegeler >Priority: Major > Fix For: waiting-for-feedback > > > It would be great to have a programmatic way to add entries to the manifest > from other mojos. The most important client of such a way would be the maven > bundle plugin (from the Apache Felix project) that calculates additional > headers for OSGi bundles. Right now, that bundle does not only do the > calculation but generates the jar file as well. > While a workaround would be to let the bundle plugin generate the full > manifest and configure the jar plugin to use it, this is not very elegant. > Passing down a map of manifest entries from one mojo to the jar plugin would > solve this in a much better way. > And I could imagine that other mojos/plugins might benefit for this as well. > This would be a simple but very convenient enhancement to the plugin -- This message was sent by Atlassian JIRA (v7.6.3#76005)
