[jira] [Commented] (MSHADE-251) Add skip parameter to shade goal
[ https://issues.apache.org/jira/browse/MSHADE-251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17231336#comment-17231336 ] Delany commented on MSHADE-251: --- [~rfscholte] again you raise the issue of code smells, but this is a usability issue. I want to add the plugin, get it into source and test it out, and when its ready I'll flip the switch. The real code smell is that Maven doesn't provide a skip config for all plugins by default > Add skip parameter to shade goal > > > Key: MSHADE-251 > URL: https://issues.apache.org/jira/browse/MSHADE-251 > Project: Maven Shade Plugin > Issue Type: New Feature >Reporter: Jonathan Haber >Priority: Minor > > Most Maven plugins have a skip parameter but not the shade plugin. Our > use-case is that we have multiple ways of packaging apps for deployment > (using the shade plugin is one such way). We have these packaging plugins > defined in our shared parent POM and projects can use Maven properties to > control which ones to skip and which to execute. > We've added this feature on our fork (which you can view > [here|https://github.com/HubSpot/maven-plugins/compare/3fb23118d33d842e56a05cc94388d0b40f1bd7e3...811af68429b3728eaef1f8fc42a32bdb2571a8b1]). > It's not much code and having a skip parameter can be a lifesaver when you > need it, so I was hoping this feature could get added. Let me know what you > think. > Thanks, > Jonathan -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (SUREFIRE-1854) Support include/exclude junit test engine
[ https://issues.apache.org/jira/browse/SUREFIRE-1854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17231350#comment-17231350 ] Adam commented on SUREFIRE-1854: Thank yoy [~tibordigana] I am glad to support Surefire plugin :) Do you have some custom description of change process for maven plugins? I think that I can start working on this in next week. > Support include/exclude junit test engine > - > > Key: SUREFIRE-1854 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1854 > Project: Maven Surefire > Issue Type: New Feature > Components: JUnit 5.x support, Maven Surefire Plugin >Affects Versions: 2.22.2 >Reporter: Adam >Priority: Major > > It could be very important for my project to support include/exclude junit > test engine by Maven Surefire Plugin. > Junit Console Launcher have existing support for this: > [https://junit.org/junit5/docs/current/user-guide/#running-tests-console-launcher-options] > Similar solution exists for Gradle: > https://junit.org/junit5/docs/current/user-guide/#running-tests-build-gradle -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (SUREFIRE-1854) Support include/exclude junit test engine
[ https://issues.apache.org/jira/browse/SUREFIRE-1854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17231350#comment-17231350 ] Adam edited comment on SUREFIRE-1854 at 11/13/20, 10:14 AM: Thank yoy [~tibordigana] I am glad to support Surefire plugin :) Do you have some custom description of change process for maven plugins? I think that I can start working on this in next week. And question: should I work on version 2.22.2/3 or for 3.0.0? Currently I need this for version 2.22.2 was (Author: adam11grafik): Thank yoy [~tibordigana] I am glad to support Surefire plugin :) Do you have some custom description of change process for maven plugins? I think that I can start working on this in next week. > Support include/exclude junit test engine > - > > Key: SUREFIRE-1854 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1854 > Project: Maven Surefire > Issue Type: New Feature > Components: JUnit 5.x support, Maven Surefire Plugin >Affects Versions: 2.22.2 >Reporter: Adam >Priority: Major > > It could be very important for my project to support include/exclude junit > test engine by Maven Surefire Plugin. > Junit Console Launcher have existing support for this: > [https://junit.org/junit5/docs/current/user-guide/#running-tests-console-launcher-options] > Similar solution exists for Gradle: > https://junit.org/junit5/docs/current/user-guide/#running-tests-build-gradle -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MJLINK-53) ITs should fail if no jlink binary is available
[
https://issues.apache.org/jira/browse/MJLINK-53?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Marwell updated MJLINK-53:
---
Description:
Currently the ITs will just be skipped if no jlink binary is available:
{code:java}
[INFO] --- maven-invoker-plugin:3.2.1:integration-test (integration-test) @
maven-jlink-plugin ---
107[INFO] Running 2 setup jobs:
108[INFO] Building: setup-jar-module-info/pom.xml
109[INFO] setup-jar-module-info/pom.xml SKIPPED
due to JRE version
110[INFO] Building: setup-jar/pom.xml
111[INFO] setup-jar/pom.xml SKIPPED
due to JRE version
112[INFO] Setup done.
113[INFO] Building: MJLINK-3_improveVerboseOutput/pom.xml
114[INFO] MJLINK-3_improveVerboseOutput/pom.xml SKIPPED
due to JRE version
115[INFO] Building: MJLINK-4_dependencyResolution/pom.xml
116[INFO] MJLINK-4_dependencyResolution/pom.xml SKIPPED
due to JRE version
117[INFO] Building: MJLINK-26/pom.xml
118[INFO] MJLINK-26/pom.xml SKIPPED
due to JRE version
119
{code}
Source:
[https://github.com/bmarwell/maven-jlink-plugin/runs/1343140417?check_suite_focus=true#step:11:1]
However, building this project (maven-mjlink-plugin) with JDK8 should be
supported using jlink via toolchains.
To add a little bit more detail:
https://issues.apache.org/jira/browse/MJLINK-36 is to be implemented via
multi-module jars (e.g. add a folder {{src/main/java9}}). This means that
without a Java8+Toolchain execution, the Java 8 code is never executed.
was:
Currently the ITs will just be skipped if no jlink binary is available:
{code:java}
[INFO] --- maven-invoker-plugin:3.2.1:integration-test (integration-test) @
maven-jlink-plugin ---
107[INFO] Running 2 setup jobs:
108[INFO] Building: setup-jar-module-info/pom.xml
109[INFO] setup-jar-module-info/pom.xml SKIPPED
due to JRE version
110[INFO] Building: setup-jar/pom.xml
111[INFO] setup-jar/pom.xml SKIPPED
due to JRE version
112[INFO] Setup done.
113[INFO] Building: MJLINK-3_improveVerboseOutput/pom.xml
114[INFO] MJLINK-3_improveVerboseOutput/pom.xml SKIPPED
due to JRE version
115[INFO] Building: MJLINK-4_dependencyResolution/pom.xml
116[INFO] MJLINK-4_dependencyResolution/pom.xml SKIPPED
due to JRE version
117[INFO] Building: MJLINK-26/pom.xml
118[INFO] MJLINK-26/pom.xml SKIPPED
due to JRE version
119
{code}
Source:
[https://github.com/bmarwell/maven-jlink-plugin/runs/1343140417?check_suite_focus=true#step:11:1]
However, building this project (maven-mjlink-plugin) with JDK8 should be
supported using jlink via toolchains.
> ITs should fail if no jlink binary is available
> ---
>
> Key: MJLINK-53
> URL: https://issues.apache.org/jira/browse/MJLINK-53
> Project: Maven JLink Plugin
> Issue Type: Improvement
>Reporter: Benjamin Marwell
>Priority: Major
>
> Currently the ITs will just be skipped if no jlink binary is available:
> {code:java}
> [INFO] --- maven-invoker-plugin:3.2.1:integration-test (integration-test) @
> maven-jlink-plugin ---
> 107[INFO] Running 2 setup jobs:
> 108[INFO] Building: setup-jar-module-info/pom.xml
> 109[INFO] setup-jar-module-info/pom.xml
> SKIPPED due to JRE version
> 110[INFO] Building: setup-jar/pom.xml
> 111[INFO] setup-jar/pom.xml
> SKIPPED due to JRE version
> 112[INFO] Setup done.
> 113[INFO] Building: MJLINK-3_improveVerboseOutput/pom.xml
> 114[INFO] MJLINK-3_improveVerboseOutput/pom.xml
> SKIPPED due to JRE version
> 115[INFO] Building: MJLINK-4_dependencyResolution/pom.xml
> 116[INFO] MJLINK-4_dependencyResolution/pom.xml
> SKIPPED due to JRE version
> 117[INFO] Building: MJLINK-26/pom.xml
> 118[INFO] MJLINK-26/pom.xml
> SKIPPED due to JRE version
> 119
> {code}
> Source:
> [https://github.com/bmarwell/maven-jlink-plugin/runs/1343140417?check_suite_focus=true#step:11:1]
>
> However, building this project (maven-mjlink-plugin) with JDK8 should be
> supported using jlink via toolchains.
>
> To add a little bit more detail:
> https://issues.apache.org/jira/browse/MJLINK-36 is to be implemented via
> multi-module jars (e.g. add a folder {{src/main/java9}}). This means that
> without a Java8+Toolchain execution, the Java 8 code is never executed.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MSHADE-251) Add skip parameter to shade goal
[ https://issues.apache.org/jira/browse/MSHADE-251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17231384#comment-17231384 ] Robert Scholte commented on MSHADE-251: --- Any parameter that can be set from commandline AND effects the result of the artifact should be banned. Otherwise we'll get the other discussions: why doesn't my project compile( or even worse .. run) anymore? Oh, because somebody added -Dshade.skip and now the classes aren't relocated. As one of the plugin maintainer I'm not giong to take responsibility for that at a plugin level. You are allowed to do it on a project level by adding profiles to the pom. Having reliable builds is much more important compared to flexibility with skip parameters. Regarding inheritence (specify the plugin in a parent pom, and only let a subset use it) is already possible when pluginManagement, but it could be improved. > Add skip parameter to shade goal > > > Key: MSHADE-251 > URL: https://issues.apache.org/jira/browse/MSHADE-251 > Project: Maven Shade Plugin > Issue Type: New Feature >Reporter: Jonathan Haber >Priority: Minor > > Most Maven plugins have a skip parameter but not the shade plugin. Our > use-case is that we have multiple ways of packaging apps for deployment > (using the shade plugin is one such way). We have these packaging plugins > defined in our shared parent POM and projects can use Maven properties to > control which ones to skip and which to execute. > We've added this feature on our fork (which you can view > [here|https://github.com/HubSpot/maven-plugins/compare/3fb23118d33d842e56a05cc94388d0b40f1bd7e3...811af68429b3728eaef1f8fc42a32bdb2571a8b1]). > It's not much code and having a skip parameter can be a lifesaver when you > need it, so I was hoping this feature could get added. Let me know what you > think. > Thanks, > Jonathan -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (SUREFIRE-1854) Support include/exclude junit test engine
[
https://issues.apache.org/jira/browse/SUREFIRE-1854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17231397#comment-17231397
]
Tibor Digana commented on SUREFIRE-1854:
[~adam11grafik]
It's quite easy, just open a new PR on
[GitHub|http://github.com/apache/maven-surefire] and name the PR and final
commit {{[SUREFIRE-1854] Support include/exclude junit test engine}}.
My recommendation is to start with simple commits and I will guide you there
with review. Finally, the CI should pass on GitHub and the PR should be
squashed and rebased on master.
The name of branch does not matter if it is named master. We develop in master
yet.
The module {{surefire-junit-platform}} has few tests classes and the provider
is tested there. It's important that your build works locally before you start.
So fork the project from GitHub and try to run these commands, you should get
successful build with unit tests:
{{mvn install -nsu -DskipTests}}
{{mvn -nsu -f surefire-providers/surefire-junit-platform/pom.xml test}}
or run the test suite in IDEA which is easier.
The next step would be the ITs but let's leave it on the GH Worflows.
Of course new unit tests must be written for your work with a coverage which
does not go down.
> Support include/exclude junit test engine
> -
>
> Key: SUREFIRE-1854
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1854
> Project: Maven Surefire
> Issue Type: New Feature
> Components: JUnit 5.x support, Maven Surefire Plugin
>Affects Versions: 2.22.2
>Reporter: Adam
>Priority: Major
>
> It could be very important for my project to support include/exclude junit
> test engine by Maven Surefire Plugin.
> Junit Console Launcher have existing support for this:
> [https://junit.org/junit5/docs/current/user-guide/#running-tests-console-launcher-options]
> Similar solution exists for Gradle:
> https://junit.org/junit5/docs/current/user-guide/#running-tests-build-gradle
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (SUREFIRE-1854) Support include/exclude junit test engine
[
https://issues.apache.org/jira/browse/SUREFIRE-1854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17231397#comment-17231397
]
Tibor Digana edited comment on SUREFIRE-1854 at 11/13/20, 11:28 AM:
[~adam11grafik]
It's quite easy, just open a new PR on
[GitHub|http://github.com/apache/maven-surefire] and name the PR and final
commit "{{[SUREFIRE-1854] Support include/exclude junit test engine}}".
My recommendation is to start with simple commits and I will guide you there
with review. Finally, the CI should pass on GitHub and the PR should be
squashed and rebased on master.
The name of branch does not matter if it is named master. We develop in master
yet.
The module {{surefire-junit-platform}} has few tests classes and the provider
is tested there. It's important that your build works locally before you start.
So fork the project from GitHub and try to run these commands, you should get
successful build with unit tests:
{{mvn install -nsu -DskipTests}}
{{mvn -nsu -f surefire-providers/surefire-junit-platform/pom.xml test}}
or run the test suite in IDEA which is easier.
The next step would be the ITs but let's leave it on the GH Worflows.
Of course new unit tests must be written for your work with a coverage which
does not go down.
was (Author: tibor17):
[~adam11grafik]
It's quite easy, just open a new PR on
[GitHub|http://github.com/apache/maven-surefire] and name the PR and final
commit {{[SUREFIRE-1854] Support include/exclude junit test engine}}.
My recommendation is to start with simple commits and I will guide you there
with review. Finally, the CI should pass on GitHub and the PR should be
squashed and rebased on master.
The name of branch does not matter if it is named master. We develop in master
yet.
The module {{surefire-junit-platform}} has few tests classes and the provider
is tested there. It's important that your build works locally before you start.
So fork the project from GitHub and try to run these commands, you should get
successful build with unit tests:
{{mvn install -nsu -DskipTests}}
{{mvn -nsu -f surefire-providers/surefire-junit-platform/pom.xml test}}
or run the test suite in IDEA which is easier.
The next step would be the ITs but let's leave it on the GH Worflows.
Of course new unit tests must be written for your work with a coverage which
does not go down.
> Support include/exclude junit test engine
> -
>
> Key: SUREFIRE-1854
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1854
> Project: Maven Surefire
> Issue Type: New Feature
> Components: JUnit 5.x support, Maven Surefire Plugin
>Affects Versions: 2.22.2
>Reporter: Adam
>Priority: Major
>
> It could be very important for my project to support include/exclude junit
> test engine by Maven Surefire Plugin.
> Junit Console Launcher have existing support for this:
> [https://junit.org/junit5/docs/current/user-guide/#running-tests-console-launcher-options]
> Similar solution exists for Gradle:
> https://junit.org/junit5/docs/current/user-guide/#running-tests-build-gradle
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (SUREFIRE-1854) Support include/exclude junit test engine
[ https://issues.apache.org/jira/browse/SUREFIRE-1854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17231416#comment-17231416 ] Adam commented on SUREFIRE-1854: Ok, thank you. I will start working on this next week :) > Support include/exclude junit test engine > - > > Key: SUREFIRE-1854 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1854 > Project: Maven Surefire > Issue Type: New Feature > Components: JUnit 5.x support, Maven Surefire Plugin >Affects Versions: 2.22.2 >Reporter: Adam >Priority: Major > > It could be very important for my project to support include/exclude junit > test engine by Maven Surefire Plugin. > Junit Console Launcher have existing support for this: > [https://junit.org/junit5/docs/current/user-guide/#running-tests-console-launcher-options] > Similar solution exists for Gradle: > https://junit.org/junit5/docs/current/user-guide/#running-tests-build-gradle -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MSHADE-251) Add skip parameter to shade goal
[
https://issues.apache.org/jira/browse/MSHADE-251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17231423#comment-17231423
]
Delany commented on MSHADE-251:
---
I don't know what world you're living in where people randomly add parameters
to command lines, my colleagues all have keyboard-phobia, they'd do anything to
use a shorter build command.
Imagine if we were making desk lamps without on/off switches. People must pull
it out of the wall? Ridiculous.
And as for profiles, thats exactly what I've done. Hundreds of profiles for
switching plugins and off. But of course I can't just turn on a profile by
default, because that would turn off the other profile that was turned off by
default, hence
{{}}
{{ }}
{{ !muaeixubuayol}}
{{ }}
{{ }}
And that's when I didn't just bind the plugin to a non-existent phase! Which
makes three ways that plugins are being toggled.
> Add skip parameter to shade goal
>
>
> Key: MSHADE-251
> URL: https://issues.apache.org/jira/browse/MSHADE-251
> Project: Maven Shade Plugin
> Issue Type: New Feature
>Reporter: Jonathan Haber
>Priority: Minor
>
> Most Maven plugins have a skip parameter but not the shade plugin. Our
> use-case is that we have multiple ways of packaging apps for deployment
> (using the shade plugin is one such way). We have these packaging plugins
> defined in our shared parent POM and projects can use Maven properties to
> control which ones to skip and which to execute.
> We've added this feature on our fork (which you can view
> [here|https://github.com/HubSpot/maven-plugins/compare/3fb23118d33d842e56a05cc94388d0b40f1bd7e3...811af68429b3728eaef1f8fc42a32bdb2571a8b1]).
> It's not much code and having a skip parameter can be a lifesaver when you
> need it, so I was hoping this feature could get added. Let me know what you
> think.
> Thanks,
> Jonathan
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (MSHADE-251) Add skip parameter to shade goal
[
https://issues.apache.org/jira/browse/MSHADE-251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17231423#comment-17231423
]
Delany edited comment on MSHADE-251 at 11/13/20, 12:30 PM:
---
I don't know what world you're living in where people randomly add parameters
to command lines, my colleagues all have keyboard-phobia, they'd do anything to
use a shorter build command.
Imagine if we were making desk lamps without on/off switches. People must pull
it out of the wall? Ridiculous.
And as for profiles, thats exactly what I've done. Hundreds of profiles for
switching plugins and off. But of course I can't just turn on a profile by
default, because that would turn off the other profiles that were turned on by
default, hence
{{}}
{{ }}
{{ !muaeixubuayol}}
{{ }}
And that's when I didn't just bind the plugin to a non-existent phase! Which
makes three ways that plugins are being toggled.
was (Author: delany):
I don't know what world you're living in where people randomly add parameters
to command lines, my colleagues all have keyboard-phobia, they'd do anything to
use a shorter build command.
Imagine if we were making desk lamps without on/off switches. People must pull
it out of the wall? Ridiculous.
And as for profiles, thats exactly what I've done. Hundreds of profiles for
switching plugins and off. But of course I can't just turn on a profile by
default, because that would turn off the other profile that was turned off by
default, hence
{{}}
{{ }}
{{ !muaeixubuayol}}
{{ }}
And that's when I didn't just bind the plugin to a non-existent phase! Which
makes three ways that plugins are being toggled.
> Add skip parameter to shade goal
>
>
> Key: MSHADE-251
> URL: https://issues.apache.org/jira/browse/MSHADE-251
> Project: Maven Shade Plugin
> Issue Type: New Feature
>Reporter: Jonathan Haber
>Priority: Minor
>
> Most Maven plugins have a skip parameter but not the shade plugin. Our
> use-case is that we have multiple ways of packaging apps for deployment
> (using the shade plugin is one such way). We have these packaging plugins
> defined in our shared parent POM and projects can use Maven properties to
> control which ones to skip and which to execute.
> We've added this feature on our fork (which you can view
> [here|https://github.com/HubSpot/maven-plugins/compare/3fb23118d33d842e56a05cc94388d0b40f1bd7e3...811af68429b3728eaef1f8fc42a32bdb2571a8b1]).
> It's not much code and having a skip parameter can be a lifesaver when you
> need it, so I was hoping this feature could get added. Let me know what you
> think.
> Thanks,
> Jonathan
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (MSHADE-251) Add skip parameter to shade goal
[
https://issues.apache.org/jira/browse/MSHADE-251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17231423#comment-17231423
]
Delany edited comment on MSHADE-251 at 11/13/20, 12:29 PM:
---
I don't know what world you're living in where people randomly add parameters
to command lines, my colleagues all have keyboard-phobia, they'd do anything to
use a shorter build command.
Imagine if we were making desk lamps without on/off switches. People must pull
it out of the wall? Ridiculous.
And as for profiles, thats exactly what I've done. Hundreds of profiles for
switching plugins and off. But of course I can't just turn on a profile by
default, because that would turn off the other profile that was turned off by
default, hence
{{}}
{{ }}
{{ !muaeixubuayol}}
{{ }}
And that's when I didn't just bind the plugin to a non-existent phase! Which
makes three ways that plugins are being toggled.
was (Author: delany):
I don't know what world you're living in where people randomly add parameters
to command lines, my colleagues all have keyboard-phobia, they'd do anything to
use a shorter build command.
Imagine if we were making desk lamps without on/off switches. People must pull
it out of the wall? Ridiculous.
And as for profiles, thats exactly what I've done. Hundreds of profiles for
switching plugins and off. But of course I can't just turn on a profile by
default, because that would turn off the other profile that was turned off by
default, hence
{{}}
{{ }}
{{ !muaeixubuayol}}
{{ }}
{{ }}
And that's when I didn't just bind the plugin to a non-existent phase! Which
makes three ways that plugins are being toggled.
> Add skip parameter to shade goal
>
>
> Key: MSHADE-251
> URL: https://issues.apache.org/jira/browse/MSHADE-251
> Project: Maven Shade Plugin
> Issue Type: New Feature
>Reporter: Jonathan Haber
>Priority: Minor
>
> Most Maven plugins have a skip parameter but not the shade plugin. Our
> use-case is that we have multiple ways of packaging apps for deployment
> (using the shade plugin is one such way). We have these packaging plugins
> defined in our shared parent POM and projects can use Maven properties to
> control which ones to skip and which to execute.
> We've added this feature on our fork (which you can view
> [here|https://github.com/HubSpot/maven-plugins/compare/3fb23118d33d842e56a05cc94388d0b40f1bd7e3...811af68429b3728eaef1f8fc42a32bdb2571a8b1]).
> It's not much code and having a skip parameter can be a lifesaver when you
> need it, so I was hoping this feature could get added. Let me know what you
> think.
> Thanks,
> Jonathan
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (MSHADE-251) Add skip parameter to shade goal
[
https://issues.apache.org/jira/browse/MSHADE-251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17231423#comment-17231423
]
Delany edited comment on MSHADE-251 at 11/13/20, 12:30 PM:
---
I don't know what world you're living in where people randomly add parameters
to command lines, my colleagues all have keyboard-phobia, they'd do anything to
use a shorter build command.
Imagine if we were making desk lamps without on/off switches. People must pull
it out of the wall? Ridiculous.
And as for profiles, thats exactly what I've done. Hundreds of profiles for
switching plugins and off. But of course I can't just turn on a profile by
default, because that would turn off the other profiles that were turned on by
default, hence they all have
{{}}
{{ }}
{{ !muaeixubuayol}}
{{ }}
And that's when I didn't just bind the plugin to a non-existent phase! Which
makes three ways that plugins are being toggled.
was (Author: delany):
I don't know what world you're living in where people randomly add parameters
to command lines, my colleagues all have keyboard-phobia, they'd do anything to
use a shorter build command.
Imagine if we were making desk lamps without on/off switches. People must pull
it out of the wall? Ridiculous.
And as for profiles, thats exactly what I've done. Hundreds of profiles for
switching plugins and off. But of course I can't just turn on a profile by
default, because that would turn off the other profiles that were turned on by
default, hence
{{}}
{{ }}
{{ !muaeixubuayol}}
{{ }}
And that's when I didn't just bind the plugin to a non-existent phase! Which
makes three ways that plugins are being toggled.
> Add skip parameter to shade goal
>
>
> Key: MSHADE-251
> URL: https://issues.apache.org/jira/browse/MSHADE-251
> Project: Maven Shade Plugin
> Issue Type: New Feature
>Reporter: Jonathan Haber
>Priority: Minor
>
> Most Maven plugins have a skip parameter but not the shade plugin. Our
> use-case is that we have multiple ways of packaging apps for deployment
> (using the shade plugin is one such way). We have these packaging plugins
> defined in our shared parent POM and projects can use Maven properties to
> control which ones to skip and which to execute.
> We've added this feature on our fork (which you can view
> [here|https://github.com/HubSpot/maven-plugins/compare/3fb23118d33d842e56a05cc94388d0b40f1bd7e3...811af68429b3728eaef1f8fc42a32bdb2571a8b1]).
> It's not much code and having a skip parameter can be a lifesaver when you
> need it, so I was hoping this feature could get added. Let me know what you
> think.
> Thanks,
> Jonathan
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (MNG-6114) Elements from the global settings should be ordered before elements from the user settings
[ https://issues.apache.org/jira/browse/MNG-6114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MNG-6114: Summary: Elements from the global settings should be ordered before elements from the user settings (was: Elements from the global settings should be ordered before elements from the user settings.) > Elements from the global settings should be ordered before elements from the > user settings > -- > > Key: MNG-6114 > URL: https://issues.apache.org/jira/browse/MNG-6114 > Project: Maven > Issue Type: Bug >Reporter: Christian Schulte >Priority: Major > Fix For: 3.7.x-candidate > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (MEAR-289) skinnyWars issue with finalName for Jar module
Stefan Schmidt created MEAR-289:
---
Summary: skinnyWars issue with finalName for Jar module
Key: MEAR-289
URL: https://issues.apache.org/jira/browse/MEAR-289
Project: Maven Ear Plugin
Issue Type: Bug
Affects Versions: 3.1.0
Reporter: Stefan Schmidt
Attachments: maven-ear-example.zip
When a finalName is given for a Jar module in a War it is not found by filename
@\{artifactId}@-@\{version}@.@\{extension}@ for deletion in maven-ear-plugin.
Example as attached:
* module-jar
* module-jar2 (with finalName)
* module-war (has jar and jar2 as dependency)
* module-ear (has jar as dependency)
#> ./mvnw clean install
The module-ear-0-SNAPSHOT.ear contains the
com.example-module-war-0-SNAPSHOT.war. In this war both jar's are in folder
WEB-INF/lib module-jar-0-SNAPSHOT.jar and module-jar2-0-SNAPSHOT.jar.
On debugging maven-ear-plugin 3.1.0 it is checking only the finalName.jar and
the name com.example-module-jar-0-SNAPSHOT.jar.
Debugging -> EarMojo.java line 816 to 838
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6114) Elements from the global settings should be ordered before elements from the user settings
[ https://issues.apache.org/jira/browse/MNG-6114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17231603#comment-17231603 ] Michael Osipov commented on MNG-6114: - I have ran Core ITs with this enabled and it triggers a bug in Maven. Will create shortly. > Elements from the global settings should be ordered before elements from the > user settings > -- > > Key: MNG-6114 > URL: https://issues.apache.org/jira/browse/MNG-6114 > Project: Maven > Issue Type: Bug >Reporter: Christian Schulte >Priority: Major > Fix For: 3.7.x-candidate > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [maven-jlink-plugin] elharo commented on pull request #15: (no-issue) remove unused junit 4.
elharo commented on pull request #15: URL: https://github.com/apache/maven-jlink-plugin/pull/15#issuecomment-726859821 Strong no on this one. JUnit 4 is what the entire project uses. It's much better supported by tooling. JUnit 5 seems to be a completely new thing that has not achieved broad adoption. For example, I just noticed Eclipse doesn't support this. We should stick to JUnit 4 for now, and any choice to upgrade should be discussed across the community, not just within one PR in one repo. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Created] (MNG-7018) Maven does not traverse all repos when downloading extensions from .mvn/extensions.xml
Michael Osipov created MNG-7018:
---
Summary: Maven does not traverse all repos when downloading
extensions from .mvn/extensions.xml
Key: MNG-7018
URL: https://issues.apache.org/jira/browse/MNG-7018
Project: Maven
Issue Type: Bug
Components: Artifacts and Repositories, Dependencies
Affects Versions: 3.6.3
Reporter: Michael Osipov
Attachments: MNG-6114-settings.xml, MNG-6114.log, master-settings.xml,
master.log
Check out Maven from {{MNG-6114}}. Run Core ITs, see MNG-5771 fail. (Compare
uploaded log files and settings). MNG-6114 orders all settings elements from
global to local. I.e., repos from global settings come first. Here is the bug:
One expects Maven to traverse all available repos to download artifacts, but
Maven stops here with the first one. W/o MNG-6114 it works accidently because
Central override was servered by a mirror.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6114) Elements from the global settings should be ordered before elements from the user settings
[ https://issues.apache.org/jira/browse/MNG-6114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17231609#comment-17231609 ] Michael Osipov commented on MNG-6114: - [~rfscholte], [~khmarbaise], WDYT? This is one ugly. > Elements from the global settings should be ordered before elements from the > user settings > -- > > Key: MNG-6114 > URL: https://issues.apache.org/jira/browse/MNG-6114 > Project: Maven > Issue Type: Bug >Reporter: Christian Schulte >Priority: Major > Fix For: 3.7.x-candidate > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [maven-jlink-plugin] bmarwell commented on pull request #15: (no-issue) remove unused junit 4.
bmarwell commented on pull request #15: URL: https://github.com/apache/maven-jlink-plugin/pull/15#issuecomment-726862778 > JUnit 5 seems to be a completely new thing Exists since 2016. I wouldn’t call it bleeding edge. > that has not achieved broad adoption It will as soon as junit4 will run out of support. This plugin is a new project and has no legacy which needs conversion. > I just noticed Eclipse doesn't support this. While I cannot believe this is true, I have not tried it myself. But there is a "we support it" article from 2017: https://www.eclipse.org/community/eclipse_newsletter/2017/october/article5.php Anyway, this is not a good argument (just a good point): shiro’s reasteasy won't run in IntelliJ, maven’s multirelease-setup will not run in any IDE either. The truth must always be the command line tool. > any choice to upgrade should be discussed across the community This is a very valid argument. I will happily put it on the mailing list! Thanks for reminding us! This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-jlink-plugin] pzygielo commented on pull request #15: (no-issue) remove unused junit 4.
pzygielo commented on pull request #15: URL: https://github.com/apache/maven-jlink-plugin/pull/15#issuecomment-726864140 > For example, I just noticed Eclipse doesn't support this. It seems to be very well supported:  This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-jlink-plugin] khmarbaise commented on pull request #15: (no-issue) remove unused junit 4.
khmarbaise commented on pull request #15: URL: https://github.com/apache/maven-jlink-plugin/pull/15#issuecomment-726867244 > > JUnit 5 seems to be a completely new thing > > Exists since 2016. I wouldn’t call it bleeding edge. Yeah...I moved all my projects to JUnit Jupiter etc. > > > that has not achieved broad adoption > > It will as soon as junit4 will run out of support. This plugin is a new project and has no legacy which needs conversion. JUnit Jupiter has much better things to offer which JUnit 4 has not... Extension point etc. etc... https://junit.org/junit5/docs/current/user-guide/ (Strongly recommend to take a deep look into it... > > > I just noticed Eclipse doesn't support this. > Can you tell which Eclipse version? This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Reopened] (MNG-6112) Central repository in the 4.0.0 super POM should declare update policy 'never'.
[ https://issues.apache.org/jira/browse/MNG-6112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov reopened MNG-6112: - I am reopening this because our approach is inconsistent: https://github.com/apache/maven/blob/master/maven-model-builder/src/main/resources/org/apache/maven/model/pom-4.0.0.xml#L38-L51 Why is the policy for plugins set to never, but for regular artifacts. What makes a plugin JAR different from a dependency JAR? > Central repository in the 4.0.0 super POM should declare update policy > 'never'. > --- > > Key: MNG-6112 > URL: https://issues.apache.org/jira/browse/MNG-6112 > Project: Maven > Issue Type: Bug >Affects Versions: 3.5.0-beta-1 >Reporter: Christian Schulte >Assignee: Robert Scholte >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (MNG-6112) Central repository in the 4.0.0 super POM should declare update policy 'never'.
[ https://issues.apache.org/jira/browse/MNG-6112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17231619#comment-17231619 ] Michael Osipov edited comment on MNG-6112 at 11/13/20, 4:44 PM: I am reopening this because our approach is inconsistent: https://github.com/apache/maven/blob/master/maven-model-builder/src/main/resources/org/apache/maven/model/pom-4.0.0.xml#L38-L51 Why is the policy for plugins set to never, but for regular artifacts. What makes a plugin JAR different from a dependency JAR? I'd expect full consistency here. was (Author: michael-o): I am reopening this because our approach is inconsistent: https://github.com/apache/maven/blob/master/maven-model-builder/src/main/resources/org/apache/maven/model/pom-4.0.0.xml#L38-L51 Why is the policy for plugins set to never, but for regular artifacts. What makes a plugin JAR different from a dependency JAR? > Central repository in the 4.0.0 super POM should declare update policy > 'never'. > --- > > Key: MNG-6112 > URL: https://issues.apache.org/jira/browse/MNG-6112 > Project: Maven > Issue Type: Bug >Affects Versions: 3.5.0-beta-1 >Reporter: Christian Schulte >Assignee: Robert Scholte >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Reopened] (MNG-6074) Maven should produce an error if no model version has been set in a POM file used to build an effective model.
[
https://issues.apache.org/jira/browse/MNG-6074?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov reopened MNG-6074:
-
[~rfscholte], I consider this being a problem if not fixed when we want to
evolve the model to post {{4.0.0}}.
> Maven should produce an error if no model version has been set in a POM file
> used to build an effective model.
> --
>
> Key: MNG-6074
> URL: https://issues.apache.org/jira/browse/MNG-6074
> Project: Maven
> Issue Type: Improvement
>Reporter: Christian Schulte
>Priority: Critical
>
> Maven currently only validates the model version to equal {{4.0.0}} when set.
> The XML element is optional. Starting with Maven 3.4.0 a warning message
> should be printed whenever no model version has been set so that it becomes
> possible to use that version to decide about Maven behaviour. For example: In
> Maven 3.5 we could add support for a new model version {{4.1.0}} which may be
> used to decide about how Maven 3.5 should behave. Behaviour for model version
> {{4.0.0}} will be the same as in Maven 3.4. Behaviour for model version
> {{4.1.0}} could be different. For this the model version needs to be set.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6326) Build continues when core extensions aren't found
[ https://issues.apache.org/jira/browse/MNG-6326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17231623#comment-17231623 ] Michael Osipov commented on MNG-6326: - I agree with [~benjamin.brum...@pinteam.eu]. From a user's POV, but cases should fail consistently. > Build continues when core extensions aren't found > - > > Key: MNG-6326 > URL: https://issues.apache.org/jira/browse/MNG-6326 > Project: Maven > Issue Type: Bug > Components: Bootstrap & Build >Affects Versions: 3.5.2 >Reporter: Matt Biggs >Priority: Critical > > If you define a core extension in *.mvn/extensions.xml* which then can't be > retrieved/found the build issues a warning and then continues leading to > unexpected behaviour depending on the functionality provided by the > extension. > If the extension is defined in the pom and not found the build fails. I would > have expected it to fail when not found in the external extensions.xml file > too as it's quite easy to miss the fact it failed to retrieve it. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MNG-6113) Rename the 'Central Repository' to 'Maven Central Repository' in the 4.0.0 super POM.
[ https://issues.apache.org/jira/browse/MNG-6113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MNG-6113: Fix Version/s: 3.7.0-candidate > Rename the 'Central Repository' to 'Maven Central Repository' in the 4.0.0 > super POM. > - > > Key: MNG-6113 > URL: https://issues.apache.org/jira/browse/MNG-6113 > Project: Maven > Issue Type: Wish >Reporter: Christian Schulte >Priority: Trivial > Fix For: 3.7.0-candidate > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Reopened] (MNG-6113) Rename the 'Central Repository' to 'Maven Central Repository' in the 4.0.0 super POM.
[ https://issues.apache.org/jira/browse/MNG-6113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov reopened MNG-6113: - This makes sense from documentation's POV. > Rename the 'Central Repository' to 'Maven Central Repository' in the 4.0.0 > super POM. > - > > Key: MNG-6113 > URL: https://issues.apache.org/jira/browse/MNG-6113 > Project: Maven > Issue Type: Wish >Reporter: Christian Schulte >Priority: Trivial > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [maven] michael-o opened a new pull request #392: [MNG-6113] Rename the 'Central Repository' to 'Maven Central Reposito…
michael-o opened a new pull request #392: URL: https://github.com/apache/maven/pull/392 …ry' in the 4.0.0 super POM Following this checklist to help us incorporate your contribution quickly and easily: - [ ] Make sure there is a [JIRA issue](https://issues.apache.org/jira/browse/MNG) filed for the change (usually before you start working on it). Trivial changes like typos do not require a JIRA issue. Your pull request should address just this issue, without pulling in other changes. - [ ] Each commit in the pull request should have a meaningful subject line and body. - [ ] Format the pull request title like `[MNG-XXX] - Fixes bug in ApproximateQuantiles`, where you replace `MNG-XXX` with the appropriate JIRA issue. Best practice is to use the JIRA issue title in the pull request title and in the first line of the commit message. - [ ] Write a pull request description that is detailed enough to understand what the pull request does, how, and why. - [ ] Run `mvn clean verify` to make sure basic checks pass. A more thorough check will be performed on your pull request automatically. - [ ] You have run the [Core IT][core-its] successfully. If your pull request is about ~20 lines of code you don't need to sign an [Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) if you are unsure please ask on the developers list. To make clear that you license your contribution under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) you have to acknowledge this by using the following check-box. - [ ] I hereby declare this contribution to be licenced under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) - [ ] In any other case, please file an [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf). [core-its]: https://maven.apache.org/core-its/core-it-suite/ This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Assigned] (MNG-6113) Rename the 'Central Repository' to 'Maven Central Repository' in the 4.0.0 super POM.
[ https://issues.apache.org/jira/browse/MNG-6113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov reassigned MNG-6113: --- Assignee: Michael Osipov > Rename the 'Central Repository' to 'Maven Central Repository' in the 4.0.0 > super POM. > - > > Key: MNG-6113 > URL: https://issues.apache.org/jira/browse/MNG-6113 > Project: Maven > Issue Type: Wish >Reporter: Christian Schulte >Assignee: Michael Osipov >Priority: Trivial > Fix For: 3.7.0-candidate > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [maven] rfscholte commented on pull request #392: [MNG-6113] Rename the 'Central Repository' to 'Maven Central Reposito…
rfscholte commented on pull request #392: URL: https://github.com/apache/maven/pull/392#issuecomment-726874851 @hboutemy has a strong opinion about this. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MNG-6074) Maven should produce an error if no model version has been set in a POM file used to build an effective model.
[
https://issues.apache.org/jira/browse/MNG-6074?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17231631#comment-17231631
]
Robert Scholte commented on MNG-6074:
-
It is already there, right?
https://github.com/apache/maven/blob/master/maven-model-builder/src/main/java/org/apache/maven/model/validation/DefaultModelValidator.java#L133-L139
> Maven should produce an error if no model version has been set in a POM file
> used to build an effective model.
> --
>
> Key: MNG-6074
> URL: https://issues.apache.org/jira/browse/MNG-6074
> Project: Maven
> Issue Type: Improvement
>Reporter: Christian Schulte
>Priority: Critical
>
> Maven currently only validates the model version to equal {{4.0.0}} when set.
> The XML element is optional. Starting with Maven 3.4.0 a warning message
> should be printed whenever no model version has been set so that it becomes
> possible to use that version to decide about Maven behaviour. For example: In
> Maven 3.5 we could add support for a new model version {{4.1.0}} which may be
> used to decide about how Maven 3.5 should behave. Behaviour for model version
> {{4.0.0}} will be the same as in Maven 3.4. Behaviour for model version
> {{4.1.0}} could be different. For this the model version needs to be set.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Issue Comment Deleted] (MNG-6074) Maven should produce an error if no model version has been set in a POM file used to build an effective model.
[
https://issues.apache.org/jira/browse/MNG-6074?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated MNG-6074:
Comment: was deleted
(was: UNSTABLE: Integrated in maven-3.x #1352 (See
[https://builds.apache.org/job/maven-3.x/1352/])
[MNG-6074] Maven should produce an error if no model version has been (schulte:
rev 744b98e8cf9f2fbe4f73b07927a2c697e8cc6fc2)
*
maven-model-builder/src/main/java/org/apache/maven/model/validation/DefaultModelValidator.java
)
> Maven should produce an error if no model version has been set in a POM file
> used to build an effective model.
> --
>
> Key: MNG-6074
> URL: https://issues.apache.org/jira/browse/MNG-6074
> Project: Maven
> Issue Type: Improvement
>Reporter: Christian Schulte
>Priority: Critical
>
> Maven currently only validates the model version to equal {{4.0.0}} when set.
> The XML element is optional. Starting with Maven 3.4.0 a warning message
> should be printed whenever no model version has been set so that it becomes
> possible to use that version to decide about Maven behaviour. For example: In
> Maven 3.5 we could add support for a new model version {{4.1.0}} which may be
> used to decide about how Maven 3.5 should behave. Behaviour for model version
> {{4.0.0}} will be the same as in Maven 3.4. Behaviour for model version
> {{4.1.0}} could be different. For this the model version needs to be set.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Issue Comment Deleted] (MNG-6074) Maven should produce an error if no model version has been set in a POM file used to build an effective model.
[
https://issues.apache.org/jira/browse/MNG-6074?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated MNG-6074:
Comment: was deleted
(was: SUCCESS: Integrated in maven-3.x #1347 (See
[https://builds.apache.org/job/maven-3.x/1347/])
[MNG-6074] Maven should print a warning if no model version has been set
(schulte: rev 45a04204f720c9ed9c70c825fdb7834adb83852c)
*
maven-model-builder/src/main/java/org/apache/maven/model/validation/DefaultModelValidator.java
)
> Maven should produce an error if no model version has been set in a POM file
> used to build an effective model.
> --
>
> Key: MNG-6074
> URL: https://issues.apache.org/jira/browse/MNG-6074
> Project: Maven
> Issue Type: Improvement
>Reporter: Christian Schulte
>Priority: Critical
>
> Maven currently only validates the model version to equal {{4.0.0}} when set.
> The XML element is optional. Starting with Maven 3.4.0 a warning message
> should be printed whenever no model version has been set so that it becomes
> possible to use that version to decide about Maven behaviour. For example: In
> Maven 3.5 we could add support for a new model version {{4.1.0}} which may be
> used to decide about how Maven 3.5 should behave. Behaviour for model version
> {{4.0.0}} will be the same as in Maven 3.4. Behaviour for model version
> {{4.1.0}} could be different. For this the model version needs to be set.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Issue Comment Deleted] (MNG-6074) Maven should produce an error if no model version has been set in a POM file used to build an effective model.
[
https://issues.apache.org/jira/browse/MNG-6074?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated MNG-6074:
Comment: was deleted
(was: SUCCESS: Integrated in maven-3.x #1348 (See
[https://builds.apache.org/job/maven-3.x/1348/])
[MNG-6074] Maven should print a warning if no model version has been set
(schulte: rev 0246aed0c2b29522a323d45bbf455251e8bb049e)
*
maven-model-builder/src/main/java/org/apache/maven/model/validation/DefaultModelValidator.java
)
> Maven should produce an error if no model version has been set in a POM file
> used to build an effective model.
> --
>
> Key: MNG-6074
> URL: https://issues.apache.org/jira/browse/MNG-6074
> Project: Maven
> Issue Type: Improvement
>Reporter: Christian Schulte
>Priority: Critical
>
> Maven currently only validates the model version to equal {{4.0.0}} when set.
> The XML element is optional. Starting with Maven 3.4.0 a warning message
> should be printed whenever no model version has been set so that it becomes
> possible to use that version to decide about Maven behaviour. For example: In
> Maven 3.5 we could add support for a new model version {{4.1.0}} which may be
> used to decide about how Maven 3.5 should behave. Behaviour for model version
> {{4.0.0}} will be the same as in Maven 3.4. Behaviour for model version
> {{4.1.0}} could be different. For this the model version needs to be set.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [maven] michael-o commented on pull request #392: [MNG-6113] Rename the 'Central Repository' to 'Maven Central Reposito…
michael-o commented on pull request #392: URL: https://github.com/apache/maven/pull/392#issuecomment-726877887 I'd love to here it. I would expect that we use a canonical name which carries your name: Maven. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Issue Comment Deleted] (MNG-6114) Elements from the global settings should be ordered before elements from the user settings
[ https://issues.apache.org/jira/browse/MNG-6114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte updated MNG-6114: Comment: was deleted (was: SUCCESS: Integrated in Jenkins build maven-3.x #1411 (See [https://builds.apache.org/job/maven-3.x/1411/]) [MNG-6114] Profiles from the global settings should be ordered before (schulte: rev c145eb5b219b89c306f9e4fa777e517ea87d8f27) * (edit) maven-settings-builder/src/main/java/org/apache/maven/settings/merge/MavenSettingsMerger.java ) > Elements from the global settings should be ordered before elements from the > user settings > -- > > Key: MNG-6114 > URL: https://issues.apache.org/jira/browse/MNG-6114 > Project: Maven > Issue Type: Bug >Reporter: Christian Schulte >Priority: Major > Fix For: 3.7.x-candidate > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Issue Comment Deleted] (MNG-6114) Elements from the global settings should be ordered before elements from the user settings
[ https://issues.apache.org/jira/browse/MNG-6114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte updated MNG-6114: Comment: was deleted (was: SUCCESS: Integrated in Jenkins build maven-3.x Jigsaw #10 (See [https://builds.apache.org/job/maven-3.x%20Jigsaw/10/]) [MNG-6114] Profiles from the global settings should be ordered before (schulte: rev c145eb5b219b89c306f9e4fa777e517ea87d8f27) * (edit) maven-settings-builder/src/main/java/org/apache/maven/settings/merge/MavenSettingsMerger.java ) > Elements from the global settings should be ordered before elements from the > user settings > -- > > Key: MNG-6114 > URL: https://issues.apache.org/jira/browse/MNG-6114 > Project: Maven > Issue Type: Bug >Reporter: Christian Schulte >Priority: Major > Fix For: 3.7.x-candidate > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6114) Elements from the global settings should be ordered before elements from the user settings
[ https://issues.apache.org/jira/browse/MNG-6114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17231635#comment-17231635 ] Robert Scholte commented on MNG-6114: - You're saying that right now global settings is winning from user settings when using the same id? > Elements from the global settings should be ordered before elements from the > user settings > -- > > Key: MNG-6114 > URL: https://issues.apache.org/jira/browse/MNG-6114 > Project: Maven > Issue Type: Bug >Reporter: Christian Schulte >Priority: Major > Fix For: 3.7.x-candidate > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6074) Maven should produce an error if no model version has been set in a POM file used to build an effective model.
[
https://issues.apache.org/jira/browse/MNG-6074?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17231638#comment-17231638
]
Michael Osipov commented on MNG-6074:
-
You are right, that's rally confusing. It has been delivered MNG-5993 with
3.5.0. Should I reassign this to be fixed in 3.5.0, this it effectively has
been fixed in that version?
> Maven should produce an error if no model version has been set in a POM file
> used to build an effective model.
> --
>
> Key: MNG-6074
> URL: https://issues.apache.org/jira/browse/MNG-6074
> Project: Maven
> Issue Type: Improvement
>Reporter: Christian Schulte
>Priority: Critical
>
> Maven currently only validates the model version to equal {{4.0.0}} when set.
> The XML element is optional. Starting with Maven 3.4.0 a warning message
> should be printed whenever no model version has been set so that it becomes
> possible to use that version to decide about Maven behaviour. For example: In
> Maven 3.5 we could add support for a new model version {{4.1.0}} which may be
> used to decide about how Maven 3.5 should behave. Behaviour for model version
> {{4.0.0}} will be the same as in Maven 3.4. Behaviour for model version
> {{4.1.0}} could be different. For this the model version needs to be set.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6114) Elements from the global settings should be ordered before elements from the user settings
[ https://issues.apache.org/jira/browse/MNG-6114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17231639#comment-17231639 ] Michael Osipov commented on MNG-6114: - Not directly, it is winning simply because it is the first on the list now which makes logically sense. See also MNG-5984. > Elements from the global settings should be ordered before elements from the > user settings > -- > > Key: MNG-6114 > URL: https://issues.apache.org/jira/browse/MNG-6114 > Project: Maven > Issue Type: Bug >Reporter: Christian Schulte >Priority: Major > Fix For: 3.7.x-candidate > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (MNG-6074) Maven should produce an error if no model version has been set in a POM file used to build an effective model.
[
https://issues.apache.org/jira/browse/MNG-6074?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17231638#comment-17231638
]
Michael Osipov edited comment on MNG-6074 at 11/13/20, 5:11 PM:
You are right, that's really confusing. It has been delivered MNG-5993 with
3.5.0. Should I reassign this to be fixed in 3.5.0, this it effectively has
been fixed in that version?
was (Author: michael-o):
You are right, that's rally confusing. It has been delivered MNG-5993 with
3.5.0. Should I reassign this to be fixed in 3.5.0, this it effectively has
been fixed in that version?
> Maven should produce an error if no model version has been set in a POM file
> used to build an effective model.
> --
>
> Key: MNG-6074
> URL: https://issues.apache.org/jira/browse/MNG-6074
> Project: Maven
> Issue Type: Improvement
>Reporter: Christian Schulte
>Priority: Critical
>
> Maven currently only validates the model version to equal {{4.0.0}} when set.
> The XML element is optional. Starting with Maven 3.4.0 a warning message
> should be printed whenever no model version has been set so that it becomes
> possible to use that version to decide about Maven behaviour. For example: In
> Maven 3.5 we could add support for a new model version {{4.1.0}} which may be
> used to decide about how Maven 3.5 should behave. Behaviour for model version
> {{4.0.0}} will be the same as in Maven 3.4. Behaviour for model version
> {{4.1.0}} could be different. For this the model version needs to be set.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [maven-jlink-plugin] khmarbaise commented on pull request #13: remove unused JUnit 5
khmarbaise commented on pull request #13: URL: https://github.com/apache/maven-jlink-plugin/pull/13#issuecomment-726884459 -1 Move to JUnit Jupiter aka JUnit 5... This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MNG-6074) Maven should produce an error if no model version has been set in a POM file used to build an effective model.
[
https://issues.apache.org/jira/browse/MNG-6074?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17231672#comment-17231672
]
Robert Scholte commented on MNG-6074:
-
yes, just set fix version to 3.5.0
> Maven should produce an error if no model version has been set in a POM file
> used to build an effective model.
> --
>
> Key: MNG-6074
> URL: https://issues.apache.org/jira/browse/MNG-6074
> Project: Maven
> Issue Type: Improvement
>Reporter: Christian Schulte
>Priority: Critical
>
> Maven currently only validates the model version to equal {{4.0.0}} when set.
> The XML element is optional. Starting with Maven 3.4.0 a warning message
> should be printed whenever no model version has been set so that it becomes
> possible to use that version to decide about Maven behaviour. For example: In
> Maven 3.5 we could add support for a new model version {{4.1.0}} which may be
> used to decide about how Maven 3.5 should behave. Behaviour for model version
> {{4.0.0}} will be the same as in Maven 3.4. Behaviour for model version
> {{4.1.0}} could be different. For this the model version needs to be set.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [maven-jlink-plugin] sormuras commented on pull request #14: [MJLINK-41] add support for --add-options argument (JDK14+).
sormuras commented on pull request #14: URL: https://github.com/apache/maven-jlink-plugin/pull/14#issuecomment-726891603 As this PR introduces a feature for Java 14+, can you please also extend the java axis with `, 15`? https://github.com/apache/maven-jlink-plugin/blob/5e2b1272727400d81eb64a3de50557f343097319/.github/workflows/maven.yml#L28 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-jlink-plugin] sormuras edited a comment on pull request #14: [MJLINK-41] add support for --add-options argument (JDK14+).
sormuras edited a comment on pull request #14: URL: https://github.com/apache/maven-jlink-plugin/pull/14#issuecomment-726891603 As this PR introduces a feature for Java 14+, can you please also extend the java axis with `, 15`? https://github.com/apache/maven-jlink-plugin/blob/5e2b1272727400d81eb64a3de50557f343097319/.github/workflows/maven.yml#L28 At the moment, your new IT is skipped: ``` cli-options/add-options/pom.xml .. SKIPPED due to JRE version ``` This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MNG-6114) Elements from the global settings should be ordered before elements from the user settings
[ https://issues.apache.org/jira/browse/MNG-6114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17231677#comment-17231677 ] Robert Scholte commented on MNG-6114: - Please update the description, I'm missing the bigger picture. > Elements from the global settings should be ordered before elements from the > user settings > -- > > Key: MNG-6114 > URL: https://issues.apache.org/jira/browse/MNG-6114 > Project: Maven > Issue Type: Bug >Reporter: Christian Schulte >Priority: Major > Fix For: 3.7.x-candidate > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (MNG-6074) Maven should produce an error if no model version has been set in a POM file used to build an effective model.
[
https://issues.apache.org/jira/browse/MNG-6074?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed MNG-6074.
---
Fix Version/s: 3.5.0
Assignee: Karl Heinz Marbaise
Resolution: Fixed
For some strange reason fixed by MNG-5993.
> Maven should produce an error if no model version has been set in a POM file
> used to build an effective model.
> --
>
> Key: MNG-6074
> URL: https://issues.apache.org/jira/browse/MNG-6074
> Project: Maven
> Issue Type: Improvement
>Reporter: Christian Schulte
>Assignee: Karl Heinz Marbaise
>Priority: Critical
> Fix For: 3.5.0
>
>
> Maven currently only validates the model version to equal {{4.0.0}} when set.
> The XML element is optional. Starting with Maven 3.4.0 a warning message
> should be printed whenever no model version has been set so that it becomes
> possible to use that version to decide about Maven behaviour. For example: In
> Maven 3.5 we could add support for a new model version {{4.1.0}} which may be
> used to decide about how Maven 3.5 should behave. Behaviour for model version
> {{4.0.0}} will be the same as in Maven 3.4. Behaviour for model version
> {{4.1.0}} could be different. For this the model version needs to be set.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (MNG-6114) Elements from the global settings should be ordered before elements from the user settings
[ https://issues.apache.org/jira/browse/MNG-6114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MNG-6114: Description: From a logical point of view, in a stacked design. First we have elements from global settings, physically followed user settings if they don't override global settings. Now, it is the opposite which is not logical. > Elements from the global settings should be ordered before elements from the > user settings > -- > > Key: MNG-6114 > URL: https://issues.apache.org/jira/browse/MNG-6114 > Project: Maven > Issue Type: Bug >Reporter: Christian Schulte >Priority: Major > Fix For: 3.7.x-candidate > > > From a logical point of view, in a stacked design. First we have elements > from global settings, physically followed user settings if they don't > override global settings. Now, it is the opposite which is not logical. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MNG-6114) Elements from the global settings should be ordered before elements from the user settings
[ https://issues.apache.org/jira/browse/MNG-6114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MNG-6114: Description: From a logical point of view, in a stacked design we first have elements from global settings, physically followed user settings if they don't override global settings. Now, it is the opposite which is not logical. (was: From a logical point of view, in a stacked design. First we have elements from global settings, physically followed user settings if they don't override global settings. Now, it is the opposite which is not logical.) > Elements from the global settings should be ordered before elements from the > user settings > -- > > Key: MNG-6114 > URL: https://issues.apache.org/jira/browse/MNG-6114 > Project: Maven > Issue Type: Bug >Reporter: Christian Schulte >Priority: Major > Fix For: 3.7.x-candidate > > > From a logical point of view, in a stacked design we first have elements from > global settings, physically followed user settings if they don't override > global settings. Now, it is the opposite which is not logical. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Reopened] (MNG-6073) Addition of a core extension point to the model builder supporting model finalization.
[ https://issues.apache.org/jira/browse/MNG-6073?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov reopened MNG-6073: - Need to evaluate before closing... > Addition of a core extension point to the model builder supporting model > finalization. > -- > > Key: MNG-6073 > URL: https://issues.apache.org/jira/browse/MNG-6073 > Project: Maven > Issue Type: New Feature >Reporter: Christian Schulte >Priority: Trivial > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6114) Elements from the global settings should be ordered before elements from the user settings
[ https://issues.apache.org/jira/browse/MNG-6114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17231698#comment-17231698 ] Robert Scholte commented on MNG-6114: - Just to confirm I understand: global has repos A and B, user has B and C Current order is A (global) B (user) C(user)? Whereas you expect B(user) C(user) A(global)? > Elements from the global settings should be ordered before elements from the > user settings > -- > > Key: MNG-6114 > URL: https://issues.apache.org/jira/browse/MNG-6114 > Project: Maven > Issue Type: Bug >Reporter: Christian Schulte >Priority: Major > Fix For: 3.7.x-candidate > > > From a logical point of view, in a stacked design we first have elements from > global settings, physically followed user settings if they don't override > global settings. Now, it is the opposite which is not logical. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Reopened] (MNG-6075) Increase the model validation level to the next minor level version.
[ https://issues.apache.org/jira/browse/MNG-6075?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov reopened MNG-6075: - [~rfscholte], maybe a good point for 4.0.0? > Increase the model validation level to the next minor level version. > > > Key: MNG-6075 > URL: https://issues.apache.org/jira/browse/MNG-6075 > Project: Maven > Issue Type: Task >Reporter: Christian Schulte >Priority: Critical > > Maven 3 has warned about various model related issues clearly stating that > not reacting to those warnings may break with a future Maven version. > Starting with Maven 3.4, the model validation level has been increased to the > next minor version so that such warnings will become errors as of 3.4. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6114) Elements from the global settings should be ordered before elements from the user settings
[ https://issues.apache.org/jira/browse/MNG-6114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17231706#comment-17231706 ] Michael Osipov commented on MNG-6114: - The exact opposite is the case: Current order is B (user) C (user) A (global). Whereas you expect A (global) B (user) C (user). > Elements from the global settings should be ordered before elements from the > user settings > -- > > Key: MNG-6114 > URL: https://issues.apache.org/jira/browse/MNG-6114 > Project: Maven > Issue Type: Bug >Reporter: Christian Schulte >Priority: Major > Fix For: 3.7.x-candidate > > > From a logical point of view, in a stacked design we first have elements from > global settings, physically followed user settings if they don't override > global settings. Now, it is the opposite which is not logical. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (MNG-6114) Elements from the global settings should be ordered before elements from the user settings
[ https://issues.apache.org/jira/browse/MNG-6114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17231706#comment-17231706 ] Michael Osipov edited comment on MNG-6114 at 11/13/20, 6:03 PM: The exact opposite is the case: Current order is B (user) C (user) A (global). Whereas you expect A (global) B (user) C (user). See also my explanation in MNG-7018 as well as the settings files there. was (Author: michael-o): The exact opposite is the case: Current order is B (user) C (user) A (global). Whereas you expect A (global) B (user) C (user). > Elements from the global settings should be ordered before elements from the > user settings > -- > > Key: MNG-6114 > URL: https://issues.apache.org/jira/browse/MNG-6114 > Project: Maven > Issue Type: Bug >Reporter: Christian Schulte >Priority: Major > Fix For: 3.7.x-candidate > > > From a logical point of view, in a stacked design we first have elements from > global settings, physically followed user settings if they don't override > global settings. Now, it is the opposite which is not logical. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6114) Elements from the global settings should be ordered before elements from the user settings
[ https://issues.apache.org/jira/browse/MNG-6114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17231711#comment-17231711 ] Michael Osipov commented on MNG-6114: - But this change applies to all elements in the settings file if you look at the changeset closely. > Elements from the global settings should be ordered before elements from the > user settings > -- > > Key: MNG-6114 > URL: https://issues.apache.org/jira/browse/MNG-6114 > Project: Maven > Issue Type: Bug >Reporter: Christian Schulte >Priority: Major > Fix For: 3.7.x-candidate > > > From a logical point of view, in a stacked design we first have elements from > global settings, physically followed user settings if they don't override > global settings. Now, it is the opposite which is not logical. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Issue Comment Deleted] (MNG-6075) Increase the model validation level to the next minor level version.
[ https://issues.apache.org/jira/browse/MNG-6075?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte updated MNG-6075: Comment: was deleted (was: Build unstable in Jenkins: Maven TLP (wip) » maven » pre-reset-master #3 See https://builds.apache.org/job/maven-wip/job/maven/job/pre-reset-master/3/) > Increase the model validation level to the next minor level version. > > > Key: MNG-6075 > URL: https://issues.apache.org/jira/browse/MNG-6075 > Project: Maven > Issue Type: Task >Reporter: Christian Schulte >Priority: Critical > > Maven 3 has warned about various model related issues clearly stating that > not reacting to those warnings may break with a future Maven version. > Starting with Maven 3.4, the model validation level has been increased to the > next minor version so that such warnings will become errors as of 3.4. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Issue Comment Deleted] (MNG-6075) Increase the model validation level to the next minor level version.
[ https://issues.apache.org/jira/browse/MNG-6075?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte updated MNG-6075: Comment: was deleted (was: UNSTABLE: Integrated in maven-3.x #1350 (See [https://builds.apache.org/job/maven-3.x/1350/]) [MNG-6075] Increase the model validation level to the next minor level (schulte: rev 3681fd8489cd59d0c5bc49ef38725b655d524301) * maven-model-builder/src/main/java/org/apache/maven/model/building/ModelBuildingRequest.java ) > Increase the model validation level to the next minor level version. > > > Key: MNG-6075 > URL: https://issues.apache.org/jira/browse/MNG-6075 > Project: Maven > Issue Type: Task >Reporter: Christian Schulte >Priority: Critical > > Maven 3 has warned about various model related issues clearly stating that > not reacting to those warnings may break with a future Maven version. > Starting with Maven 3.4, the model validation level has been increased to the > next minor version so that such warnings will become errors as of 3.4. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Issue Comment Deleted] (MNG-6075) Increase the model validation level to the next minor level version.
[ https://issues.apache.org/jira/browse/MNG-6075?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte updated MNG-6075: Comment: was deleted (was: SUCCESS: Integrated in Jenkins build maven-3.x #1365 (See [https://builds.apache.org/job/maven-3.x/1365/]) [MNG-6075] Increase the model validation level to the next minor level (schulte: rev 1c633fa9062cf56f90d8f534508cbdcabfe4e82c) * (edit) maven-model-builder/src/main/java/org/apache/maven/model/building/DefaultModelBuilder.java ) > Increase the model validation level to the next minor level version. > > > Key: MNG-6075 > URL: https://issues.apache.org/jira/browse/MNG-6075 > Project: Maven > Issue Type: Task >Reporter: Christian Schulte >Priority: Critical > > Maven 3 has warned about various model related issues clearly stating that > not reacting to those warnings may break with a future Maven version. > Starting with Maven 3.4, the model validation level has been increased to the > next minor version so that such warnings will become errors as of 3.4. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Issue Comment Deleted] (MNG-6075) Increase the model validation level to the next minor level version.
[ https://issues.apache.org/jira/browse/MNG-6075?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte updated MNG-6075: Comment: was deleted (was: SUCCESS: Integrated in maven-3.x #1353 (See [https://builds.apache.org/job/maven-3.x/1353/]) [MNG-6075] Increase the model validation level to the next minor level (schulte: rev 0fbad04c5ff63c87b6d80873cb8b45b6c9b79781) * maven-model-builder/src/main/java/org/apache/maven/model/building/DefaultModelBuilder.java [MNG-6075] Increase the model validation level to the next minor level (schulte: rev 615390d7cfddb328704cf64f0a942a0f40d5c9df) * maven-model-builder/src/test/java/org/apache/maven/model/validation/DefaultModelValidatorTest.java * maven-core/src/test/java/org/apache/maven/project/AbstractMavenProjectTestCase.java [MNG-6075] Increase the model validation level to the next minor level (schulte: rev a5e87a42376cc6ecd086bb3dd79ff713ace3d6de) * maven-model-builder/src/main/java/org/apache/maven/model/building/DefaultModelBuilder.java ) > Increase the model validation level to the next minor level version. > > > Key: MNG-6075 > URL: https://issues.apache.org/jira/browse/MNG-6075 > Project: Maven > Issue Type: Task >Reporter: Christian Schulte >Priority: Critical > > Maven 3 has warned about various model related issues clearly stating that > not reacting to those warnings may break with a future Maven version. > Starting with Maven 3.4, the model validation level has been increased to the > next minor version so that such warnings will become errors as of 3.4. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6075) Increase the model validation level to the next minor level version.
[ https://issues.apache.org/jira/browse/MNG-6075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17231720#comment-17231720 ] Robert Scholte commented on MNG-6075: - Sure > Increase the model validation level to the next minor level version. > > > Key: MNG-6075 > URL: https://issues.apache.org/jira/browse/MNG-6075 > Project: Maven > Issue Type: Task >Reporter: Christian Schulte >Priority: Critical > > Maven 3 has warned about various model related issues clearly stating that > not reacting to those warnings may break with a future Maven version. > Starting with Maven 3.4, the model validation level has been increased to the > next minor version so that such warnings will become errors as of 3.4. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6075) Increase the model validation level to the next minor level version.
[ https://issues.apache.org/jira/browse/MNG-6075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17231722#comment-17231722 ] Michael Osipov commented on MNG-6075: - Set a candiate when 3.7.0 will be renamed to 4.0.0. > Increase the model validation level to the next minor level version. > > > Key: MNG-6075 > URL: https://issues.apache.org/jira/browse/MNG-6075 > Project: Maven > Issue Type: Task >Reporter: Christian Schulte >Priority: Critical > Fix For: 3.7.0-candidate > > > Maven 3 has warned about various model related issues clearly stating that > not reacting to those warnings may break with a future Maven version. > Starting with Maven 3.4, the model validation level has been increased to the > next minor version so that such warnings will become errors as of 3.4. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MNG-6075) Increase the model validation level to the next minor level version.
[ https://issues.apache.org/jira/browse/MNG-6075?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MNG-6075: Fix Version/s: 3.7.0-candidate > Increase the model validation level to the next minor level version. > > > Key: MNG-6075 > URL: https://issues.apache.org/jira/browse/MNG-6075 > Project: Maven > Issue Type: Task >Reporter: Christian Schulte >Priority: Critical > Fix For: 3.7.0-candidate > > > Maven 3 has warned about various model related issues clearly stating that > not reacting to those warnings may break with a future Maven version. > Starting with Maven 3.4, the model validation level has been increased to the > next minor version so that such warnings will become errors as of 3.4. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6114) Elements from the global settings should be ordered before elements from the user settings
[ https://issues.apache.org/jira/browse/MNG-6114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17231724#comment-17231724 ] Robert Scholte commented on MNG-6114: - A (global) B (user) C(user) was indeed my first expectation: first load global, user should override and expand. If that's not the case it makes sense to fix this in 4.0.0 > Elements from the global settings should be ordered before elements from the > user settings > -- > > Key: MNG-6114 > URL: https://issues.apache.org/jira/browse/MNG-6114 > Project: Maven > Issue Type: Bug >Reporter: Christian Schulte >Priority: Major > Fix For: 3.7.x-candidate > > > From a logical point of view, in a stacked design we first have elements from > global settings, physically followed user settings if they don't override > global settings. Now, it is the opposite which is not logical. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6114) Elements from the global settings should be ordered before elements from the user settings
[ https://issues.apache.org/jira/browse/MNG-6114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17231733#comment-17231733 ] Michael Osipov commented on MNG-6114: - OK, you have the same expectation. This is currently not met by the settings merger. > Elements from the global settings should be ordered before elements from the > user settings > -- > > Key: MNG-6114 > URL: https://issues.apache.org/jira/browse/MNG-6114 > Project: Maven > Issue Type: Bug >Reporter: Christian Schulte >Priority: Major > Fix For: 3.7.x-candidate > > > From a logical point of view, in a stacked design we first have elements from > global settings, physically followed user settings if they don't override > global settings. Now, it is the opposite which is not logical. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (MNG-6114) Elements from the global settings should be ordered before elements from the user settings
[ https://issues.apache.org/jira/browse/MNG-6114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17231733#comment-17231733 ] Michael Osipov edited comment on MNG-6114 at 11/13/20, 6:22 PM: OK, you have the same expectation. This is currently not met by the settings merger. I am currently thinking how MNG-7018 can be fixed. Christian Schulte worked out a patch which needs to be cherry-picked and properly merged. was (Author: michael-o): OK, you have the same expectation. This is currently not met by the settings merger. > Elements from the global settings should be ordered before elements from the > user settings > -- > > Key: MNG-6114 > URL: https://issues.apache.org/jira/browse/MNG-6114 > Project: Maven > Issue Type: Bug >Reporter: Christian Schulte >Priority: Major > Fix For: 3.7.x-candidate > > > From a logical point of view, in a stacked design we first have elements from > global settings, physically followed user settings if they don't override > global settings. Now, it is the opposite which is not logical. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MNG-6114) Elements from the global settings should be ordered before elements from the user settings
[ https://issues.apache.org/jira/browse/MNG-6114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MNG-6114: Fix Version/s: (was: 3.7.x-candidate) 4.0.x-candidate > Elements from the global settings should be ordered before elements from the > user settings > -- > > Key: MNG-6114 > URL: https://issues.apache.org/jira/browse/MNG-6114 > Project: Maven > Issue Type: Bug >Reporter: Christian Schulte >Priority: Major > Fix For: 4.0.x-candidate > > > From a logical point of view, in a stacked design we first have elements from > global settings, physically followed user settings if they don't override > global settings. Now, it is the opposite which is not logical. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6012) Missing profile is only notified at the end of a run
[ https://issues.apache.org/jira/browse/MNG-6012?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17231742#comment-17231742 ] Michael Osipov commented on MNG-6012: - [~khmarbaise], can we split this up in actually two tickets? Implementing the first point first? > Missing profile is only notified at the end of a run > > > Key: MNG-6012 > URL: https://issues.apache.org/jira/browse/MNG-6012 > Project: Maven > Issue Type: New Feature >Affects Versions: 3.3.9 >Reporter: Sebb >Priority: Major > Fix For: 3.7.0-candidate, needing-scrub-3.4.0-fallout > > > A missing profile is only notified at the end of a run. > Since this may mean that the run is useless, it would be helpful if: > 1) It was also noted near the start, so the user could cancel the run. > It's still helpful at the end, as it saves scrolling back to see if there was > a problem. > 2) There were an option to fail a run if a profile is not found. This option > should be settable in a POM and in settings.xml -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (MNG-7019) Notify at start when profile has need not been found
Michael Osipov created MNG-7019: --- Summary: Notify at start when profile has need not been found Key: MNG-7019 URL: https://issues.apache.org/jira/browse/MNG-7019 Project: Maven Issue Type: Sub-task Components: Profiles Affects Versions: 3.6.3 Reporter: Michael Osipov Assignee: Michael Osipov Fix For: 3.7.0-candidate This will implement the first task on the list. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MNG-7019) Notify also at start when profile is missing
[ https://issues.apache.org/jira/browse/MNG-7019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MNG-7019: Summary: Notify also at start when profile is missing (was: Notify at start when profile has need not been found) > Notify also at start when profile is missing > > > Key: MNG-7019 > URL: https://issues.apache.org/jira/browse/MNG-7019 > Project: Maven > Issue Type: Sub-task > Components: Profiles >Affects Versions: 3.6.3 >Reporter: Michael Osipov >Assignee: Michael Osipov >Priority: Major > Fix For: 3.7.0-candidate > > > This will implement the first task on the list. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [maven] michael-o opened a new pull request #393: [MNG-7019] Notify also at start when profile is missing
michael-o opened a new pull request #393: URL: https://github.com/apache/maven/pull/393 @rfscholte Here it is, prerequisite for release profile removal. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven] rfscholte commented on pull request #393: [MNG-7019] Notify also at start when profile is missing
rfscholte commented on pull request #393: URL: https://github.com/apache/maven/pull/393#issuecomment-726991312 This is only one the warning part. It should also break the build, because what we've already seen due a bug in maven-release-plugin is that if the release-profile is not activated (and you are not aware of it) you'll end up with an incomplete release. Sebb also suggested to suppress that check, but I see that as optimization. https://issues.apache.org/jira/browse/MNG-6511 suffers the same issue. I suggested to introduce a ? prefix to mark it as optional. e.g. `-P ?apache-release` will active this profile, but won't break it when it is missing, whereas `-P apache-release` should break the build. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven] michael-o commented on pull request #393: [MNG-7019] Notify also at start when profile is missing
michael-o commented on pull request #393: URL: https://github.com/apache/maven/pull/393#issuecomment-726995047 Correct, this PR is for the warning only. No other functionality intentionally. I agree with breaking the build and the options `?` prefix, but it must be handled in separate tickets. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MNG-6829) Remove commons-lang3 dependency
[
https://issues.apache.org/jira/browse/MNG-6829?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17231787#comment-17231787
]
Michael Osipov commented on MNG-6829:
-
Agree with [~elharo], I have also said that I would deprecate in P-U and M-S-U
which is available in C-L.
> Remove commons-lang3 dependency
> ---
>
> Key: MNG-6829
> URL: https://issues.apache.org/jira/browse/MNG-6829
> Project: Maven
> Issue Type: Sub-task
> Components: Bootstrap & Build
>Affects Versions: 3.7.0
>Reporter: Karl Heinz Marbaise
>Assignee: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 3.7.0
>
>
> Currently we use {{commons-lang3}} for the following classes
> * {{StringUtils}} can be replaced by usage of either {{plexus-utils}} or
> {{maven-shared-utils}} or as I tested with self implementation
> * {{SystemUtils}} is only used in some tests which can simply replaced by
> using JUnit Jupiter with all the support it has.
> * {{Validate}} is a precondition class which checks for parameters etc. can
> be implemented very easily (done already to see how it works). Later this
> could be made part of {{maven-shared-utils}}.
> * Currently the {{StringUtils.substringAfterLast( resourceName, "/" )}} is
> used in {{ConsoleMavenTransferListener}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (MNG-6829) Remove commons-lang3 dependency
[
https://issues.apache.org/jira/browse/MNG-6829?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MNG-6829:
Affects Version/s: (was: 3.7.0)
3.6.3
> Remove commons-lang3 dependency
> ---
>
> Key: MNG-6829
> URL: https://issues.apache.org/jira/browse/MNG-6829
> Project: Maven
> Issue Type: Sub-task
> Components: Bootstrap & Build
>Affects Versions: 3.6.3
>Reporter: Karl Heinz Marbaise
>Assignee: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 3.7.0
>
>
> Currently we use {{commons-lang3}} for the following classes
> * {{StringUtils}} can be replaced by usage of either {{plexus-utils}} or
> {{maven-shared-utils}} or as I tested with self implementation
> * {{SystemUtils}} is only used in some tests which can simply replaced by
> using JUnit Jupiter with all the support it has.
> * {{Validate}} is a precondition class which checks for parameters etc. can
> be implemented very easily (done already to see how it works). Later this
> could be made part of {{maven-shared-utils}}.
> * Currently the {{StringUtils.substringAfterLast( resourceName, "/" )}} is
> used in {{ConsoleMavenTransferListener}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (MNG-6829) Remove commons-lang3 dependency
[
https://issues.apache.org/jira/browse/MNG-6829?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MNG-6829:
Fix Version/s: (was: 3.7.0)
3.7.0-candidate
> Remove commons-lang3 dependency
> ---
>
> Key: MNG-6829
> URL: https://issues.apache.org/jira/browse/MNG-6829
> Project: Maven
> Issue Type: Sub-task
> Components: Bootstrap & Build
>Affects Versions: 3.6.3
>Reporter: Karl Heinz Marbaise
>Assignee: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 3.7.0-candidate
>
>
> Currently we use {{commons-lang3}} for the following classes
> * {{StringUtils}} can be replaced by usage of either {{plexus-utils}} or
> {{maven-shared-utils}} or as I tested with self implementation
> * {{SystemUtils}} is only used in some tests which can simply replaced by
> using JUnit Jupiter with all the support it has.
> * {{Validate}} is a precondition class which checks for parameters etc. can
> be implemented very easily (done already to see how it works). Later this
> could be made part of {{maven-shared-utils}}.
> * Currently the {{StringUtils.substringAfterLast( resourceName, "/" )}} is
> used in {{ConsoleMavenTransferListener}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (MNG-6825) Cleaning Up dependencies plexus-utils/maven-shared-utils/commons-lang3/commons-io
[
https://issues.apache.org/jira/browse/MNG-6825?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MNG-6825:
Fix Version/s: (was: 3.7.0)
3.7.0-candidate
> Cleaning Up dependencies
> plexus-utils/maven-shared-utils/commons-lang3/commons-io
> -
>
> Key: MNG-6825
> URL: https://issues.apache.org/jira/browse/MNG-6825
> Project: Maven
> Issue Type: Improvement
> Components: Bootstrap & Build
>Affects Versions: 3.6.3
>Reporter: Karl Heinz Marbaise
>Assignee: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 3.7.0-candidate
>
>
> Experiment to see if we can get rid of commons-lang3 dependency.
> * Identified code duplication between:
> ** {{org.apache.commons.lang3.StringUtils}} from {{commons-lang3}} (501879
> Bytes commons-lang3-3.8.1.jar)
> ** {{org.codehaus.plexus.util.StringUtil}} from {{plexus-utils}} (261801
> Bytes plexus-utils-3.2.1.jar)
> ** {{org.apache.maven.shared.utils}} from {{maven-shared-utils}} (166562
> Bytes maven-shared-utils-3.2.1.jar)
> ** We should replace the self implemented with
> {{org.codehaus.plexus.util.StringUtil}}. or with {{maven-shared-utils}}
> * {{commons-io}} usage by {{maven-shared-utils}} (208700 Bytes
> commons-io-2.5.jar)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (MNG-6893) Update plugin versions in super POM (api 3.0)
[ https://issues.apache.org/jira/browse/MNG-6893?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MNG-6893: Fix Version/s: wontfix-candidate > Update plugin versions in super POM (api 3.0) > - > > Key: MNG-6893 > URL: https://issues.apache.org/jira/browse/MNG-6893 > Project: Maven > Issue Type: Improvement >Reporter: Sylwester Lachiewicz >Priority: Major > Fix For: wontfix-candidate, 3.7.0 > > Time Spent: 10m > Remaining Estimate: 0h > > Update plugins in maven-model-builder pom-4.0.0.xml > * maven-ant-run from 1.3 to 3.0.0 (/) > * maven-assembly-plugin from 2.2-beta-5 to XXX > * maven-dependency-plugin from 2.8 to XXX > * maven-dependency-plugin from 2.5.3 to XXX -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6889) Mark command line option --legacy-local-repository as deprecated
[ https://issues.apache.org/jira/browse/MNG-6889?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17231788#comment-17231788 ] Michael Osipov commented on MNG-6889: - Unless MNG-7001 is not properly solved, I see now way to deprecate or remove this. > Mark command line option --legacy-local-repository as deprecated > > > Key: MNG-6889 > URL: https://issues.apache.org/jira/browse/MNG-6889 > Project: Maven > Issue Type: Task > Components: Command Line >Affects Versions: 3.6.3 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Minor > Fix For: 3.7.0 > > > We should at least mark this option as deprecated or even better remove this > option but this would be inconsistent to remove something which has not been > marked deprecated before. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MNG-6889) Mark command line option --legacy-local-repository as deprecated
[ https://issues.apache.org/jira/browse/MNG-6889?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MNG-6889: Fix Version/s: (was: 3.7.0) Issues to be reviewed for 4.x > Mark command line option --legacy-local-repository as deprecated > > > Key: MNG-6889 > URL: https://issues.apache.org/jira/browse/MNG-6889 > Project: Maven > Issue Type: Task > Components: Command Line >Affects Versions: 3.6.3 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Minor > Fix For: Issues to be reviewed for 4.x > > > We should at least mark this option as deprecated or even better remove this > option but this would be inconsistent to remove something which has not been > marked deprecated before. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MNG-7007) Remove documented backward compatibility
[
https://issues.apache.org/jira/browse/MNG-7007?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MNG-7007:
Description:
These spots document backward compatibility:
{noformat}
./maven-core/src/main/java/org/apache/maven/execution/MavenSession.java://
Backward compat
./maven-core/src/main/java/org/apache/maven/lifecycle/DefaultLifecycleExecutor.java:
// NOTE: Backward-compat with maven-help-plugin:2.1
./maven-core/src/main/java/org/apache/maven/lifecycle/mapping/Lifecycle.java:
* NOTE: This exists merely for backward-compat with legacy-style lifecycle
definitions and allows configuration
./maven-core/src/main/java/org/apache/maven/plugin/DefaultBuildPluginManager.java:
// This is necessary to avoid creating compatibility problems for
existing plugins that use
./maven-core/src/main/java/org/apache/maven/plugin/LegacySupport.java: * Helps
to provide backward-compatibility with plugins that use legacy components.
Warning: This is an
./maven-core/src/main/java/org/apache/maven/plugin/internal/DefaultLegacySupport.java:
* Helps to provide backward-compatibility with plugins that use legacy
components. Warning: This is an
./maven-core/src/main/java/org/apache/maven/plugin/internal/PluginDependencyResolutionListener.java:
* core wagon versions. This is a hack to provide backward-compat with Maven 2
(MNG-4528, MNG-4561).
./maven-core/src/main/java/org/apache/maven/plugin/internal/WagonExcluder.java:
* core wagon versions. This is a hack to provide backward-compat with Maven 2
(MNG-4528, MNG-4561).
./maven-core/src/main/java/org/apache/maven/plugin/version/internal/DefaultPluginVersionResolver.java:
logger.debug( "Ignoring incompatible plugin version " + version +
": " + e.getMessage() );
./maven-core/src/main/java/org/apache/maven/project/DefaultProjectBuildingHelper.java:
* This is purely for backward-compat with 2.x where
consisting of a single artifact where
./maven-core/src/main/java/org/apache/maven/project/DuplicateArtifactAttachmentException.java:
* Currently, this modification would create compatibility problems for
existing plugins.
./maven-core/src/main/java/org/apache/maven/project/MavenProject.java: *
@throws DuplicateArtifactAttachmentException will never happen but leave it for
backward compatibility
./maven-core/src/main/java/org/apache/maven/project/artifact/DefaultMetadataSource.java:
* This realizes the metadata source via the default hint to provide
backward-compat with Maven 2.x whose Plexus version
./maven-core/src/main/java/org/apache/maven/toolchain/java/DefaultJavaToolChain.java:
* Provides backwards compatibility with Maven 3.2.3 and earlier. Clients that
do not require compatibility with Maven
./maven-core/src/main/java/org/apache/maven/toolchain/java/DefaultJavaToolChain.java:
* @deprecated clients that do not require compatibility with Maven 3.2.3 and
earlier should link to
./maven-core/src/main/java/org/apache/maven/toolchain/java/JavaToolchainFactory.java:
// use DefaultJavaToolChain for compatibility with maven 3.2.3 and
earlier
./maven-model-builder/src/main/java/org/apache/maven/model/building/ModelBuildingRequest.java:
* Denotes validation as performed by Maven 2.0. This validation level is
meant as a compatibility mode to allow
./maven-model-builder/src/main/java/org/apache/maven/model/inheritance/DefaultInheritanceAssembler.java:
* sake of backward-compat with 2.x (MNG-5000). In general, it is
wrong to
./maven-model-builder/src/main/java/org/apache/maven/model/normalization/DefaultModelNormalizer.java:
* NOTE: This is primarily to keep backward-compat with Maven 2.x which
did not validate that dependencies are
./maven-model-builder/src/main/java/org/apache/maven/model/normalization/DefaultModelNormalizer.java:
* the first occurrence. So when we're in lenient/compat mode, we have
to deal with such broken POMs and mimic
./maven-model-builder/src/main/java/org/apache/maven/model/validation/DefaultModelValidator.java:
* order to don't break backward-compat with those, only
warn but don't error out.
./maven-model-builder/src/main/java/org/apache/maven/model/validation/DefaultModelValidator.java:
// note this will not be hit for Maven 1.x project.xml as it is an
incompatible schema
{noformat}
They need to be reviewed one by one and removed if possible.
was:
These spots document backward compatibility:
{noformat}
./maven-core/src/main/java/org/apache/maven/execution/MavenSession.java://
Backward compat
./maven-core/src/main/java/org/apache/maven/lifecycle/DefaultLifecycleExecutor.java:
// NOTE: Backward-compat with maven-help-plugin:2.1
./maven-core/src/main/java/org/apache/maven/lifecycle/mapping/Lifecycle.java:
* NOTE: This exists merely for backward-compat with legacy-style lifecycle
definitions and allows config
[jira] [Commented] (MNG-7007) Remove documented backward compatibility
[
https://issues.apache.org/jira/browse/MNG-7007?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17231794#comment-17231794
]
Michael Osipov commented on MNG-7007:
-
Excluding
{noformat}
./maven-embedder/src/main/java/org/apache/maven/cli/CLIManager.java://
Adding this back in for compatibility with the verifier that hard codes this
option.
./maven-embedder/src/main/java/org/apache/maven/cli/CLIManager.java:
options.addOption( Option.builder( "npr" ).longOpt( "no-plugin-registry"
).desc( "Ineffective, only kept for backward compatibility" ).build() );
./maven-embedder/src/main/java/org/apache/maven/cli/CLIManager.java:
options.addOption( Option.builder( "cpu" ).longOpt( "check-plugin-updates"
).desc( "Ineffective, only kept for backward compatibility" ).build() );
./maven-embedder/src/main/java/org/apache/maven/cli/CLIManager.java:
options.addOption( Option.builder( "up" ).longOpt( "update-plugins" ).desc(
"Ineffective, only kept for backward compatibility" ).build() );
./maven-embedder/src/main/java/org/apache/maven/cli/CLIManager.java:
options.addOption( Option.builder( "npu" ).longOpt( "no-plugin-updates" ).desc(
"Ineffective, only kept for backward compatibility" ).build() );
{noformat}
It is already handled by MNG-6888.
> Remove documented backward compatibility
>
>
> Key: MNG-7007
> URL: https://issues.apache.org/jira/browse/MNG-7007
> Project: Maven
> Issue Type: Task
>Affects Versions: 3.6.3
>Reporter: Michael Osipov
>Priority: Major
>
> These spots document backward compatibility:
> {noformat}
> ./maven-core/src/main/java/org/apache/maven/execution/MavenSession.java:
> // Backward compat
> ./maven-core/src/main/java/org/apache/maven/lifecycle/DefaultLifecycleExecutor.java:
> // NOTE: Backward-compat with maven-help-plugin:2.1
> ./maven-core/src/main/java/org/apache/maven/lifecycle/mapping/Lifecycle.java:
> * NOTE: This exists merely for backward-compat with legacy-style
> lifecycle definitions and allows configuration
> ./maven-core/src/main/java/org/apache/maven/plugin/DefaultBuildPluginManager.java:
> // This is necessary to avoid creating compatibility problems for
> existing plugins that use
> ./maven-core/src/main/java/org/apache/maven/plugin/LegacySupport.java: *
> Helps to provide backward-compatibility with plugins that use legacy
> components. Warning: This is an
> ./maven-core/src/main/java/org/apache/maven/plugin/internal/DefaultLegacySupport.java:
> * Helps to provide backward-compatibility with plugins that use legacy
> components. Warning: This is an
> ./maven-core/src/main/java/org/apache/maven/plugin/internal/PluginDependencyResolutionListener.java:
> * core wagon versions. This is a hack to provide backward-compat with Maven
> 2 (MNG-4528, MNG-4561).
> ./maven-core/src/main/java/org/apache/maven/plugin/internal/WagonExcluder.java:
> * core wagon versions. This is a hack to provide backward-compat with Maven
> 2 (MNG-4528, MNG-4561).
> ./maven-core/src/main/java/org/apache/maven/plugin/version/internal/DefaultPluginVersionResolver.java:
> logger.debug( "Ignoring incompatible plugin version " + version +
> ": " + e.getMessage() );
> ./maven-core/src/main/java/org/apache/maven/project/DefaultProjectBuildingHelper.java:
> * This is purely for backward-compat with 2.x where
> consisting of a single artifact where
> ./maven-core/src/main/java/org/apache/maven/project/DuplicateArtifactAttachmentException.java:
> * Currently, this modification would create compatibility problems for
> existing plugins.
> ./maven-core/src/main/java/org/apache/maven/project/MavenProject.java: *
> @throws DuplicateArtifactAttachmentException will never happen but leave it
> for backward compatibility
> ./maven-core/src/main/java/org/apache/maven/project/artifact/DefaultMetadataSource.java:
> * This realizes the metadata source via the default hint to provide
> backward-compat with Maven 2.x whose Plexus version
> ./maven-core/src/main/java/org/apache/maven/toolchain/java/DefaultJavaToolChain.java:
> * Provides backwards compatibility with Maven 3.2.3 and earlier. Clients
> that do not require compatibility with Maven
> ./maven-core/src/main/java/org/apache/maven/toolchain/java/DefaultJavaToolChain.java:
> * @deprecated clients that do not require compatibility with Maven 3.2.3 and
> earlier should link to
> ./maven-core/src/main/java/org/apache/maven/toolchain/java/JavaToolchainFactory.java:
> // use DefaultJavaToolChain for compatibility with maven 3.2.3 and
> earlier
> ./maven-embedder/src/main/java/org/apache/maven/cli/CLIManager.java:
> // Adding this back in for compatibility with the verifier that hard codes
> this option.
> ./maven-embedder/src/main/jav
[jira] [Commented] (MNG-6893) Update plugin versions in super POM (api 3.0)
[ https://issues.apache.org/jira/browse/MNG-6893?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17231796#comment-17231796 ] Sylwester Lachiewicz commented on MNG-6893: --- Before we move to pom 5.0 and remove everything it would be good to update to latest versions based on api 3.0 so maven-compat will not be required > Update plugin versions in super POM (api 3.0) > - > > Key: MNG-6893 > URL: https://issues.apache.org/jira/browse/MNG-6893 > Project: Maven > Issue Type: Improvement >Reporter: Sylwester Lachiewicz >Priority: Major > Fix For: wontfix-candidate, 3.7.0 > > Time Spent: 10m > Remaining Estimate: 0h > > Update plugins in maven-model-builder pom-4.0.0.xml > * maven-ant-run from 1.3 to 3.0.0 (/) > * maven-assembly-plugin from 2.2-beta-5 to XXX > * maven-dependency-plugin from 2.8 to XXX > * maven-dependency-plugin from 2.5.3 to XXX -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MNG-7007) Remove documented backward compatibility
[
https://issues.apache.org/jira/browse/MNG-7007?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MNG-7007:
Description:
These spots document backward compatibility:
{noformat}
./maven-core/src/main/java/org/apache/maven/execution/MavenSession.java://
Backward compat
./maven-core/src/main/java/org/apache/maven/lifecycle/DefaultLifecycleExecutor.java:
// NOTE: Backward-compat with maven-help-plugin:2.1
./maven-core/src/main/java/org/apache/maven/lifecycle/mapping/Lifecycle.java:
* NOTE: This exists merely for backward-compat with legacy-style lifecycle
definitions and allows configuration
./maven-core/src/main/java/org/apache/maven/plugin/DefaultBuildPluginManager.java:
// This is necessary to avoid creating compatibility problems for
existing plugins that use
./maven-core/src/main/java/org/apache/maven/plugin/LegacySupport.java: * Helps
to provide backward-compatibility with plugins that use legacy components.
Warning: This is an
./maven-core/src/main/java/org/apache/maven/plugin/internal/DefaultLegacySupport.java:
* Helps to provide backward-compatibility with plugins that use legacy
components. Warning: This is an
./maven-core/src/main/java/org/apache/maven/plugin/internal/PluginDependencyResolutionListener.java:
* core wagon versions. This is a hack to provide backward-compat with Maven 2
(MNG-4528, MNG-4561).
./maven-core/src/main/java/org/apache/maven/plugin/internal/WagonExcluder.java:
* core wagon versions. This is a hack to provide backward-compat with Maven 2
(MNG-4528, MNG-4561).
./maven-core/src/main/java/org/apache/maven/project/DefaultProjectBuildingHelper.java:
* This is purely for backward-compat with 2.x where
consisting of a single artifact where
./maven-core/src/main/java/org/apache/maven/project/DuplicateArtifactAttachmentException.java:
* Currently, this modification would create compatibility problems for
existing plugins.
./maven-core/src/main/java/org/apache/maven/project/MavenProject.java: *
@throws DuplicateArtifactAttachmentException will never happen but leave it for
backward compatibility
./maven-core/src/main/java/org/apache/maven/project/artifact/DefaultMetadataSource.java:
* This realizes the metadata source via the default hint to provide
backward-compat with Maven 2.x whose Plexus version
./maven-core/src/main/java/org/apache/maven/toolchain/java/DefaultJavaToolChain.java:
* Provides backwards compatibility with Maven 3.2.3 and earlier. Clients that
do not require compatibility with Maven
./maven-core/src/main/java/org/apache/maven/toolchain/java/DefaultJavaToolChain.java:
* @deprecated clients that do not require compatibility with Maven 3.2.3 and
earlier should link to
./maven-core/src/main/java/org/apache/maven/toolchain/java/JavaToolchainFactory.java:
// use DefaultJavaToolChain for compatibility with maven 3.2.3 and
earlier
./maven-model-builder/src/main/java/org/apache/maven/model/building/ModelBuildingRequest.java:
* Denotes validation as performed by Maven 2.0. This validation level is
meant as a compatibility mode to allow
./maven-model-builder/src/main/java/org/apache/maven/model/inheritance/DefaultInheritanceAssembler.java:
* sake of backward-compat with 2.x (MNG-5000). In general, it is
wrong to
./maven-model-builder/src/main/java/org/apache/maven/model/normalization/DefaultModelNormalizer.java:
* NOTE: This is primarily to keep backward-compat with Maven 2.x which
did not validate that dependencies are
./maven-model-builder/src/main/java/org/apache/maven/model/normalization/DefaultModelNormalizer.java:
* the first occurrence. So when we're in lenient/compat mode, we have
to deal with such broken POMs and mimic
./maven-model-builder/src/main/java/org/apache/maven/model/validation/DefaultModelValidator.java:
* order to don't break backward-compat with those, only
warn but don't error out.
./maven-model-builder/src/main/java/org/apache/maven/model/validation/DefaultModelValidator.java:
// note this will not be hit for Maven 1.x project.xml as it is an
incompatible schema
{noformat}
They need to be reviewed one by one and removed if possible.
was:
These spots document backward compatibility:
{noformat}
./maven-core/src/main/java/org/apache/maven/execution/MavenSession.java://
Backward compat
./maven-core/src/main/java/org/apache/maven/lifecycle/DefaultLifecycleExecutor.java:
// NOTE: Backward-compat with maven-help-plugin:2.1
./maven-core/src/main/java/org/apache/maven/lifecycle/mapping/Lifecycle.java:
* NOTE: This exists merely for backward-compat with legacy-style lifecycle
definitions and allows configuration
./maven-core/src/main/java/org/apache/maven/plugin/DefaultBuildPluginManager.java:
// This is necessary to avoid creating compatibility problems for
existing plugins that use
./maven-cor
[jira] [Commented] (MNG-6893) Update plugin versions in super POM (api 3.0)
[ https://issues.apache.org/jira/browse/MNG-6893?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17231801#comment-17231801 ] Michael Osipov commented on MNG-6893: - This will happen before POM 5.0.0, in Maven 4.0.0. I wouldn't update something which is going to be removed anyway. We don't need two surprises. I have already created a branch which drops everything. All ITs pass. > Update plugin versions in super POM (api 3.0) > - > > Key: MNG-6893 > URL: https://issues.apache.org/jira/browse/MNG-6893 > Project: Maven > Issue Type: Improvement >Reporter: Sylwester Lachiewicz >Priority: Major > Fix For: wontfix-candidate, 3.7.0 > > Time Spent: 10m > Remaining Estimate: 0h > > Update plugins in maven-model-builder pom-4.0.0.xml > * maven-ant-run from 1.3 to 3.0.0 (/) > * maven-assembly-plugin from 2.2-beta-5 to XXX > * maven-dependency-plugin from 2.8 to XXX > * maven-dependency-plugin from 2.5.3 to XXX -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (MNG-6893) Update plugin versions in super POM (api 3.0)
[ https://issues.apache.org/jira/browse/MNG-6893?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylwester Lachiewicz closed MNG-6893. - Fix Version/s: (was: 3.7.0) (was: wontfix-candidate) Resolution: Won't Fix > Update plugin versions in super POM (api 3.0) > - > > Key: MNG-6893 > URL: https://issues.apache.org/jira/browse/MNG-6893 > Project: Maven > Issue Type: Improvement >Reporter: Sylwester Lachiewicz >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > Update plugins in maven-model-builder pom-4.0.0.xml > * maven-ant-run from 1.3 to 3.0.0 (/) > * maven-assembly-plugin from 2.2-beta-5 to XXX > * maven-dependency-plugin from 2.8 to XXX > * maven-dependency-plugin from 2.5.3 to XXX -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (MNG-7020) Remove Maven 2 WagonExcluder backward compat code
Michael Osipov created MNG-7020: --- Summary: Remove Maven 2 WagonExcluder backward compat code Key: MNG-7020 URL: https://issues.apache.org/jira/browse/MNG-7020 Project: Maven Issue Type: Task Components: Class Loading, Dependencies Affects Versions: 3.6.3 Reporter: Michael Osipov Assignee: Michael Osipov Fix For: 3.7.0-candidate Maven includes a Wagon Excluder when Maven 2 artifacts are use with Wagon 1.0.x. This is ancient Maven 2 backward compat. Let's remove it and hope everyone has moved on to Maven 3.x artifacts and Wagon 3.x. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-7007) Remove documented backward compatibility
[
https://issues.apache.org/jira/browse/MNG-7007?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17231857#comment-17231857
]
Michael Osipov commented on MNG-7007:
-
Excluding
{noformat}
./maven-core/src/main/java/org/apache/maven/plugin/internal/PluginDependencyResolutionListener.java:
* core wagon versions. This is a hack to provide backward-compat with Maven 2
(MNG-4528, MNG-4561).
./maven-core/src/main/java/org/apache/maven/plugin/internal/WagonExcluder.java:
* core wagon versions. This is a hack to provide backward-compat with Maven 2
(MNG-4528, MNG-4561).
{noformat}
it is already handled by MNG-7020.
> Remove documented backward compatibility
>
>
> Key: MNG-7007
> URL: https://issues.apache.org/jira/browse/MNG-7007
> Project: Maven
> Issue Type: Task
>Affects Versions: 3.6.3
>Reporter: Michael Osipov
>Priority: Major
>
> These spots document backward compatibility:
> {noformat}
> ./maven-core/src/main/java/org/apache/maven/execution/MavenSession.java:
> // Backward compat
> ./maven-core/src/main/java/org/apache/maven/lifecycle/DefaultLifecycleExecutor.java:
> // NOTE: Backward-compat with maven-help-plugin:2.1
> ./maven-core/src/main/java/org/apache/maven/lifecycle/mapping/Lifecycle.java:
> * NOTE: This exists merely for backward-compat with legacy-style
> lifecycle definitions and allows configuration
> ./maven-core/src/main/java/org/apache/maven/plugin/DefaultBuildPluginManager.java:
> // This is necessary to avoid creating compatibility problems for
> existing plugins that use
> ./maven-core/src/main/java/org/apache/maven/plugin/LegacySupport.java: *
> Helps to provide backward-compatibility with plugins that use legacy
> components. Warning: This is an
> ./maven-core/src/main/java/org/apache/maven/plugin/internal/DefaultLegacySupport.java:
> * Helps to provide backward-compatibility with plugins that use legacy
> components. Warning: This is an
> ./maven-core/src/main/java/org/apache/maven/plugin/internal/PluginDependencyResolutionListener.java:
> * core wagon versions. This is a hack to provide backward-compat with Maven
> 2 (MNG-4528, MNG-4561).
> ./maven-core/src/main/java/org/apache/maven/plugin/internal/WagonExcluder.java:
> * core wagon versions. This is a hack to provide backward-compat with Maven
> 2 (MNG-4528, MNG-4561).
> ./maven-core/src/main/java/org/apache/maven/project/DefaultProjectBuildingHelper.java:
> * This is purely for backward-compat with 2.x where
> consisting of a single artifact where
> ./maven-core/src/main/java/org/apache/maven/project/DuplicateArtifactAttachmentException.java:
> * Currently, this modification would create compatibility problems for
> existing plugins.
> ./maven-core/src/main/java/org/apache/maven/project/MavenProject.java: *
> @throws DuplicateArtifactAttachmentException will never happen but leave it
> for backward compatibility
> ./maven-core/src/main/java/org/apache/maven/project/artifact/DefaultMetadataSource.java:
> * This realizes the metadata source via the default hint to provide
> backward-compat with Maven 2.x whose Plexus version
> ./maven-core/src/main/java/org/apache/maven/toolchain/java/DefaultJavaToolChain.java:
> * Provides backwards compatibility with Maven 3.2.3 and earlier. Clients
> that do not require compatibility with Maven
> ./maven-core/src/main/java/org/apache/maven/toolchain/java/DefaultJavaToolChain.java:
> * @deprecated clients that do not require compatibility with Maven 3.2.3 and
> earlier should link to
> ./maven-core/src/main/java/org/apache/maven/toolchain/java/JavaToolchainFactory.java:
> // use DefaultJavaToolChain for compatibility with maven 3.2.3 and
> earlier
> ./maven-model-builder/src/main/java/org/apache/maven/model/building/ModelBuildingRequest.java:
> * Denotes validation as performed by Maven 2.0. This validation level is
> meant as a compatibility mode to allow
> ./maven-model-builder/src/main/java/org/apache/maven/model/inheritance/DefaultInheritanceAssembler.java:
> * sake of backward-compat with 2.x (MNG-5000). In general, it is
> wrong to
> ./maven-model-builder/src/main/java/org/apache/maven/model/normalization/DefaultModelNormalizer.java:
> * NOTE: This is primarily to keep backward-compat with Maven 2.x
> which did not validate that dependencies are
> ./maven-model-builder/src/main/java/org/apache/maven/model/normalization/DefaultModelNormalizer.java:
> * the first occurrence. So when we're in lenient/compat mode, we
> have to deal with such broken POMs and mimic
> ./maven-model-builder/src/main/java/org/apache/maven/model/validation/DefaultModelValidator.java:
> * order to don't break backward-compat with those, only
> warn but don't error out.
> ./maven
[GitHub] [maven] michael-o commented on pull request #393: [MNG-7019] Notify also at start when profile is missing
michael-o commented on pull request #393: URL: https://github.com/apache/maven/pull/393#issuecomment-727065635 Is this PR acceptable for you? This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Updated] (MNG-7007) Remove documented backward compatibility
[
https://issues.apache.org/jira/browse/MNG-7007?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MNG-7007:
Description:
These spots document backward compatibility:
{noformat}
./maven-core/src/main/java/org/apache/maven/execution/MavenSession.java://
Backward compat
./maven-core/src/main/java/org/apache/maven/lifecycle/DefaultLifecycleExecutor.java:
// NOTE: Backward-compat with maven-help-plugin:2.1
./maven-core/src/main/java/org/apache/maven/lifecycle/mapping/Lifecycle.java:
* NOTE: This exists merely for backward-compat with legacy-style lifecycle
definitions and allows configuration
./maven-core/src/main/java/org/apache/maven/plugin/DefaultBuildPluginManager.java:
// This is necessary to avoid creating compatibility problems for
existing plugins that use
./maven-core/src/main/java/org/apache/maven/plugin/LegacySupport.java: * Helps
to provide backward-compatibility with plugins that use legacy components.
Warning: This is an
./maven-core/src/main/java/org/apache/maven/plugin/internal/DefaultLegacySupport.java:
* Helps to provide backward-compatibility with plugins that use legacy
components. Warning: This is an
./maven-core/src/main/java/org/apache/maven/project/DefaultProjectBuildingHelper.java:
* This is purely for backward-compat with 2.x where
consisting of a single artifact where
./maven-core/src/main/java/org/apache/maven/project/DuplicateArtifactAttachmentException.java:
* Currently, this modification would create compatibility problems for
existing plugins.
./maven-core/src/main/java/org/apache/maven/project/MavenProject.java: *
@throws DuplicateArtifactAttachmentException will never happen but leave it for
backward compatibility
./maven-core/src/main/java/org/apache/maven/project/artifact/DefaultMetadataSource.java:
* This realizes the metadata source via the default hint to provide
backward-compat with Maven 2.x whose Plexus version
./maven-core/src/main/java/org/apache/maven/toolchain/java/DefaultJavaToolChain.java:
* Provides backwards compatibility with Maven 3.2.3 and earlier. Clients that
do not require compatibility with Maven
./maven-core/src/main/java/org/apache/maven/toolchain/java/DefaultJavaToolChain.java:
* @deprecated clients that do not require compatibility with Maven 3.2.3 and
earlier should link to
./maven-core/src/main/java/org/apache/maven/toolchain/java/JavaToolchainFactory.java:
// use DefaultJavaToolChain for compatibility with maven 3.2.3 and
earlier
./maven-model-builder/src/main/java/org/apache/maven/model/building/ModelBuildingRequest.java:
* Denotes validation as performed by Maven 2.0. This validation level is
meant as a compatibility mode to allow
./maven-model-builder/src/main/java/org/apache/maven/model/inheritance/DefaultInheritanceAssembler.java:
* sake of backward-compat with 2.x (MNG-5000). In general, it is
wrong to
./maven-model-builder/src/main/java/org/apache/maven/model/normalization/DefaultModelNormalizer.java:
* NOTE: This is primarily to keep backward-compat with Maven 2.x which
did not validate that dependencies are
./maven-model-builder/src/main/java/org/apache/maven/model/normalization/DefaultModelNormalizer.java:
* the first occurrence. So when we're in lenient/compat mode, we have
to deal with such broken POMs and mimic
./maven-model-builder/src/main/java/org/apache/maven/model/validation/DefaultModelValidator.java:
* order to don't break backward-compat with those, only
warn but don't error out.
./maven-model-builder/src/main/java/org/apache/maven/model/validation/DefaultModelValidator.java:
// note this will not be hit for Maven 1.x project.xml as it is an
incompatible schema
{noformat}
They need to be reviewed one by one and removed if possible.
was:
These spots document backward compatibility:
{noformat}
./maven-core/src/main/java/org/apache/maven/execution/MavenSession.java://
Backward compat
./maven-core/src/main/java/org/apache/maven/lifecycle/DefaultLifecycleExecutor.java:
// NOTE: Backward-compat with maven-help-plugin:2.1
./maven-core/src/main/java/org/apache/maven/lifecycle/mapping/Lifecycle.java:
* NOTE: This exists merely for backward-compat with legacy-style lifecycle
definitions and allows configuration
./maven-core/src/main/java/org/apache/maven/plugin/DefaultBuildPluginManager.java:
// This is necessary to avoid creating compatibility problems for
existing plugins that use
./maven-core/src/main/java/org/apache/maven/plugin/LegacySupport.java: * Helps
to provide backward-compatibility with plugins that use legacy components.
Warning: This is an
./maven-core/src/main/java/org/apache/maven/plugin/internal/DefaultLegacySupport.java:
* Helps to provide backward-compatibility with plugins that use legacy
components. Warning: This is an
./maven-core/src/main/java/o
[GitHub] [maven-integration-testing] michael-o opened a new pull request #78: [MNG-7020] Remove Maven 2 WagonExcluder backward compat code
michael-o opened a new pull request #78: URL: https://github.com/apache/maven-integration-testing/pull/78 * Disable unused tests * Update Maven 2 plugins to Maven 3 to avoid conflicts with old Maven and Wagon 1 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven] michael-o opened a new pull request #394: [MNG-7020] Remove Maven 2 WagonExcluder backward compat code
michael-o opened a new pull request #394: URL: https://github.com/apache/maven/pull/394 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Created] (MNG-7021) Remove old MHELP backward compat code
Michael Osipov created MNG-7021: --- Summary: Remove old MHELP backward compat code Key: MNG-7021 URL: https://issues.apache.org/jira/browse/MNG-7021 Project: Maven Issue Type: Task Components: core Affects Versions: 3.6.3 Reporter: Michael Osipov Assignee: Michael Osipov Fix For: 3.7.0-candidate Remove pre MHELP 3.0.x code. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MNG-7007) Remove documented backward compatibility
[
https://issues.apache.org/jira/browse/MNG-7007?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MNG-7007:
Description:
These spots document backward compatibility:
{noformat}
./maven-core/src/main/java/org/apache/maven/execution/MavenSession.java://
Backward compat
./maven-core/src/main/java/org/apache/maven/lifecycle/mapping/Lifecycle.java:
* NOTE: This exists merely for backward-compat with legacy-style lifecycle
definitions and allows configuration
./maven-core/src/main/java/org/apache/maven/plugin/DefaultBuildPluginManager.java:
// This is necessary to avoid creating compatibility problems for
existing plugins that use
./maven-core/src/main/java/org/apache/maven/plugin/LegacySupport.java: * Helps
to provide backward-compatibility with plugins that use legacy components.
Warning: This is an
./maven-core/src/main/java/org/apache/maven/plugin/internal/DefaultLegacySupport.java:
* Helps to provide backward-compatibility with plugins that use legacy
components. Warning: This is an
./maven-core/src/main/java/org/apache/maven/project/DefaultProjectBuildingHelper.java:
* This is purely for backward-compat with 2.x where
consisting of a single artifact where
./maven-core/src/main/java/org/apache/maven/project/DuplicateArtifactAttachmentException.java:
* Currently, this modification would create compatibility problems for
existing plugins.
./maven-core/src/main/java/org/apache/maven/project/MavenProject.java: *
@throws DuplicateArtifactAttachmentException will never happen but leave it for
backward compatibility
./maven-core/src/main/java/org/apache/maven/project/artifact/DefaultMetadataSource.java:
* This realizes the metadata source via the default hint to provide
backward-compat with Maven 2.x whose Plexus version
./maven-core/src/main/java/org/apache/maven/toolchain/java/DefaultJavaToolChain.java:
* Provides backwards compatibility with Maven 3.2.3 and earlier. Clients that
do not require compatibility with Maven
./maven-core/src/main/java/org/apache/maven/toolchain/java/DefaultJavaToolChain.java:
* @deprecated clients that do not require compatibility with Maven 3.2.3 and
earlier should link to
./maven-core/src/main/java/org/apache/maven/toolchain/java/JavaToolchainFactory.java:
// use DefaultJavaToolChain for compatibility with maven 3.2.3 and
earlier
./maven-model-builder/src/main/java/org/apache/maven/model/building/ModelBuildingRequest.java:
* Denotes validation as performed by Maven 2.0. This validation level is
meant as a compatibility mode to allow
./maven-model-builder/src/main/java/org/apache/maven/model/inheritance/DefaultInheritanceAssembler.java:
* sake of backward-compat with 2.x (MNG-5000). In general, it is
wrong to
./maven-model-builder/src/main/java/org/apache/maven/model/normalization/DefaultModelNormalizer.java:
* NOTE: This is primarily to keep backward-compat with Maven 2.x which
did not validate that dependencies are
./maven-model-builder/src/main/java/org/apache/maven/model/normalization/DefaultModelNormalizer.java:
* the first occurrence. So when we're in lenient/compat mode, we have
to deal with such broken POMs and mimic
./maven-model-builder/src/main/java/org/apache/maven/model/validation/DefaultModelValidator.java:
* order to don't break backward-compat with those, only
warn but don't error out.
./maven-model-builder/src/main/java/org/apache/maven/model/validation/DefaultModelValidator.java:
// note this will not be hit for Maven 1.x project.xml as it is an
incompatible schema
{noformat}
They need to be reviewed one by one and removed if possible.
was:
These spots document backward compatibility:
{noformat}
./maven-core/src/main/java/org/apache/maven/execution/MavenSession.java://
Backward compat
./maven-core/src/main/java/org/apache/maven/lifecycle/DefaultLifecycleExecutor.java:
// NOTE: Backward-compat with maven-help-plugin:2.1
./maven-core/src/main/java/org/apache/maven/lifecycle/mapping/Lifecycle.java:
* NOTE: This exists merely for backward-compat with legacy-style lifecycle
definitions and allows configuration
./maven-core/src/main/java/org/apache/maven/plugin/DefaultBuildPluginManager.java:
// This is necessary to avoid creating compatibility problems for
existing plugins that use
./maven-core/src/main/java/org/apache/maven/plugin/LegacySupport.java: * Helps
to provide backward-compatibility with plugins that use legacy components.
Warning: This is an
./maven-core/src/main/java/org/apache/maven/plugin/internal/DefaultLegacySupport.java:
* Helps to provide backward-compatibility with plugins that use legacy
components. Warning: This is an
./maven-core/src/main/java/org/apache/maven/project/DefaultProjectBuildingHelper.java:
* This is purely for backward-compat with 2.x where
consisting
[jira] [Commented] (MNG-7007) Remove documented backward compatibility
[
https://issues.apache.org/jira/browse/MNG-7007?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17231860#comment-17231860
]
Michael Osipov commented on MNG-7007:
-
Excluding
{noformat}
./maven-core/src/main/java/org/apache/maven/lifecycle/DefaultLifecycleExecutor.java:
// NOTE: Backward-compat with maven-help-plugin:2.1
{noformat}
it is already handled by MNG-7021.
> Remove documented backward compatibility
>
>
> Key: MNG-7007
> URL: https://issues.apache.org/jira/browse/MNG-7007
> Project: Maven
> Issue Type: Task
>Affects Versions: 3.6.3
>Reporter: Michael Osipov
>Priority: Major
>
> These spots document backward compatibility:
> {noformat}
> ./maven-core/src/main/java/org/apache/maven/execution/MavenSession.java:
> // Backward compat
> ./maven-core/src/main/java/org/apache/maven/lifecycle/mapping/Lifecycle.java:
> * NOTE: This exists merely for backward-compat with legacy-style
> lifecycle definitions and allows configuration
> ./maven-core/src/main/java/org/apache/maven/plugin/DefaultBuildPluginManager.java:
> // This is necessary to avoid creating compatibility problems for
> existing plugins that use
> ./maven-core/src/main/java/org/apache/maven/plugin/LegacySupport.java: *
> Helps to provide backward-compatibility with plugins that use legacy
> components. Warning: This is an
> ./maven-core/src/main/java/org/apache/maven/plugin/internal/DefaultLegacySupport.java:
> * Helps to provide backward-compatibility with plugins that use legacy
> components. Warning: This is an
> ./maven-core/src/main/java/org/apache/maven/project/DefaultProjectBuildingHelper.java:
> * This is purely for backward-compat with 2.x where
> consisting of a single artifact where
> ./maven-core/src/main/java/org/apache/maven/project/DuplicateArtifactAttachmentException.java:
> * Currently, this modification would create compatibility problems for
> existing plugins.
> ./maven-core/src/main/java/org/apache/maven/project/MavenProject.java: *
> @throws DuplicateArtifactAttachmentException will never happen but leave it
> for backward compatibility
> ./maven-core/src/main/java/org/apache/maven/project/artifact/DefaultMetadataSource.java:
> * This realizes the metadata source via the default hint to provide
> backward-compat with Maven 2.x whose Plexus version
> ./maven-core/src/main/java/org/apache/maven/toolchain/java/DefaultJavaToolChain.java:
> * Provides backwards compatibility with Maven 3.2.3 and earlier. Clients
> that do not require compatibility with Maven
> ./maven-core/src/main/java/org/apache/maven/toolchain/java/DefaultJavaToolChain.java:
> * @deprecated clients that do not require compatibility with Maven 3.2.3 and
> earlier should link to
> ./maven-core/src/main/java/org/apache/maven/toolchain/java/JavaToolchainFactory.java:
> // use DefaultJavaToolChain for compatibility with maven 3.2.3 and
> earlier
> ./maven-model-builder/src/main/java/org/apache/maven/model/building/ModelBuildingRequest.java:
> * Denotes validation as performed by Maven 2.0. This validation level is
> meant as a compatibility mode to allow
> ./maven-model-builder/src/main/java/org/apache/maven/model/inheritance/DefaultInheritanceAssembler.java:
> * sake of backward-compat with 2.x (MNG-5000). In general, it is
> wrong to
> ./maven-model-builder/src/main/java/org/apache/maven/model/normalization/DefaultModelNormalizer.java:
> * NOTE: This is primarily to keep backward-compat with Maven 2.x
> which did not validate that dependencies are
> ./maven-model-builder/src/main/java/org/apache/maven/model/normalization/DefaultModelNormalizer.java:
> * the first occurrence. So when we're in lenient/compat mode, we
> have to deal with such broken POMs and mimic
> ./maven-model-builder/src/main/java/org/apache/maven/model/validation/DefaultModelValidator.java:
> * order to don't break backward-compat with those, only
> warn but don't error out.
> ./maven-model-builder/src/main/java/org/apache/maven/model/validation/DefaultModelValidator.java:
> // note this will not be hit for Maven 1.x project.xml as it is
> an incompatible schema
> {noformat}
> They need to be reviewed one by one and removed if possible.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [maven] michael-o opened a new pull request #395: [MNG-7021] Remove old MHELP backward compat code
michael-o opened a new pull request #395: URL: https://github.com/apache/maven/pull/395 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MDEP-729) NullPointerException when running dependency:tree in verbose mode
[ https://issues.apache.org/jira/browse/MDEP-729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17231867#comment-17231867 ] Michael Osipov commented on MDEP-729: - Against what project? > NullPointerException when running dependency:tree in verbose mode > - > > Key: MDEP-729 > URL: https://issues.apache.org/jira/browse/MDEP-729 > Project: Maven Dependency Plugin > Issue Type: Bug >Reporter: Elliotte Rusty Harold >Priority: Major > > With Java 8, command was > > $ mvn org.apache.maven.plugins:maven-dependency-plugin:3.1.4-SNAPSHOT:tree > -Dincludes=com.fasterxml.jackson.core -Dverbose=true -e > > Not yet sure whether the specific project matters. > > > Caused by: java.lang.NullPointerException > at > org.apache.maven.plugins.dependency.tree.VerboseDependencyGraphBuilder.applyDependencyManagementDfs > (VerboseDependencyGraphBuilder.java:163) > at > > ``` > [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-dependency-plugin:3.1.4-SNAPSHOT:tree > (default-cli) on project google-cloud-storage: Execution default-cli of goal > org.apache.maven.plugins:maven-dependency-plugin:3.1.4-SNAPSHOT:tree failed.: > NullPointerException -> [Help 1] > org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute > goal org.apache.maven.plugins:maven-dependency-plugin:3.1.4-SNAPSHOT:tree > (default-cli) on project google-cloud-storage: Execution default-cli of goal > org.apache.maven.plugins:maven-dependency-plugin:3.1.4-SNAPSHOT:tree failed. > at org.apache.maven.lifecycle.internal.MojoExecutor.execute > (MojoExecutor.java:215) > at org.apache.maven.lifecycle.internal.MojoExecutor.execute > (MojoExecutor.java:156) > at org.apache.maven.lifecycle.internal.MojoExecutor.execute > (MojoExecutor.java:148) > at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject > (LifecycleModuleBuilder.java:117) > at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject > (LifecycleModuleBuilder.java:81) > at > org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build > (SingleThreadedBuilder.java:56) > at org.apache.maven.lifecycle.internal.LifecycleStarter.execute > (LifecycleStarter.java:128) > at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305) > at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192) > at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105) > at org.apache.maven.cli.MavenCli.execute (MavenCli.java:957) > at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:289) > at org.apache.maven.cli.MavenCli.main (MavenCli.java:193) > 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:282) > at org.codehaus.plexus.classworlds.launcher.Launcher.launch > (Launcher.java:225) > at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode > (Launcher.java:406) > at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:347) > Caused by: org.apache.maven.plugin.PluginExecutionException: Execution > default-cli of goal > org.apache.maven.plugins:maven-dependency-plugin:3.1.4-SNAPSHOT:tree failed. > at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo > (DefaultBuildPluginManager.java:148) > at org.apache.maven.lifecycle.internal.MojoExecutor.execute > (MojoExecutor.java:210) > at org.apache.maven.lifecycle.internal.MojoExecutor.execute > (MojoExecutor.java:156) > at org.apache.maven.lifecycle.internal.MojoExecutor.execute > (MojoExecutor.java:148) > at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject > (LifecycleModuleBuilder.java:117) > at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject > (LifecycleModuleBuilder.java:81) > at > org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build > (SingleThreadedBuilder.java:56) > at org.apache.maven.lifecycle.internal.LifecycleStarter.execute > (LifecycleStarter.java:128) > at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305) > at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192) > at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105) > at org.apache.maven.cli.MavenCli.execute (MavenCli.java:957) > at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:289) > at org.apache.maven.cli.MavenCli.main (MavenCli.java:193) > at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method) > at sun.re
[jira] [Updated] (MNG-7022) Remove o.a.m.lifecycle.mapping.Lifecycle optional mojos backward compat code
[
https://issues.apache.org/jira/browse/MNG-7022?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MNG-7022:
Fix Version/s: 3.7.0
> Remove o.a.m.lifecycle.mapping.Lifecycle optional mojos backward compat code
>
>
> Key: MNG-7022
> URL: https://issues.apache.org/jira/browse/MNG-7022
> Project: Maven
> Issue Type: Task
>Affects Versions: 3.6.3
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.7.0
>
>
> The handing of optional mojos was dropped long ago in
> ac8db28f3b8cd64192c3d038ee5557354ffb7a30, but the injection remained intact
> for backward compat reasons on legacy {{components.xml}}. Newer setups are
> encouraged to move to
> [{{lifecycle.xml}}|https://maven.apache.org/ref/3.6.3/maven-plugin-api/lifecycle-mappings.html].
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Moved] (MNG-7022) Remove o.a.m.lifecycle.mapping.Lifecycle optional mojos backward compat code
[
https://issues.apache.org/jira/browse/MNG-7022?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov moved MEAR-290 to MNG-7022:
--
Key: MNG-7022 (was: MEAR-290)
Project: Maven (was: Maven EAR Plugin)
> Remove o.a.m.lifecycle.mapping.Lifecycle optional mojos backward compat code
>
>
> Key: MNG-7022
> URL: https://issues.apache.org/jira/browse/MNG-7022
> Project: Maven
> Issue Type: Task
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
>
> The handing of optional mojos was dropped long ago in
> ac8db28f3b8cd64192c3d038ee5557354ffb7a30, but the injection remained intact
> for backward compat reasons on legacy {{components.xml}}. Newer setups are
> encouraged to move to
> [{{lifecycle.xml}}|https://maven.apache.org/ref/3.6.3/maven-plugin-api/lifecycle-mappings.html].
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (MEAR-290) Remove o.a.m.lifecycle.mapping.Lifecycle optional mojos backward compat code
Michael Osipov created MEAR-290:
---
Summary: Remove o.a.m.lifecycle.mapping.Lifecycle optional mojos
backward compat code
Key: MEAR-290
URL: https://issues.apache.org/jira/browse/MEAR-290
Project: Maven EAR Plugin
Issue Type: Task
Reporter: Michael Osipov
Assignee: Michael Osipov
The handing of optional mojos was dropped long ago in
ac8db28f3b8cd64192c3d038ee5557354ffb7a30, but the injection remained intact for
backward compat reasons on legacy {{components.xml}}. Newer setups are
encouraged to move to
[{{lifecycle.xml}}|https://maven.apache.org/ref/3.6.3/maven-plugin-api/lifecycle-mappings.html].
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (MNG-7022) Remove o.a.m.lifecycle.mapping.Lifecycle optional mojos backward compat code
[
https://issues.apache.org/jira/browse/MNG-7022?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MNG-7022:
Fix Version/s: (was: 3.7.0)
3.7.0-candidate
> Remove o.a.m.lifecycle.mapping.Lifecycle optional mojos backward compat code
>
>
> Key: MNG-7022
> URL: https://issues.apache.org/jira/browse/MNG-7022
> Project: Maven
> Issue Type: Task
>Affects Versions: 3.6.3
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.7.0-candidate
>
>
> The handing of optional mojos was dropped long ago in
> ac8db28f3b8cd64192c3d038ee5557354ffb7a30, but the injection remained intact
> for backward compat reasons on legacy {{components.xml}}. Newer setups are
> encouraged to move to
> [{{lifecycle.xml}}|https://maven.apache.org/ref/3.6.3/maven-plugin-api/lifecycle-mappings.html].
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
