[jira] [Commented] (MNG-6065) Creating option --fail-on-severity / -fos to support errorless or warningless builds
[
https://issues.apache.org/jira/browse/MNG-6065?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17006334#comment-17006334
]
Hudson commented on MNG-6065:
-
Build succeeded in Jenkins: Maven TLP » maven » archives #13
See https://builds.apache.org/job/maven-box/job/maven/job/archives/13/
> Creating option --fail-on-severity / -fos to support errorless or warningless
> builds
>
>
> Key: MNG-6065
> URL: https://issues.apache.org/jira/browse/MNG-6065
> Project: Maven
> Issue Type: Improvement
>Affects Versions: 3.5.0
>Reporter: Robert Scholte
>Assignee: Robert Scholte
>Priority: Major
> Labels: infosupport
> Fix For: 3.7.0
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> I've been thinking the option {{--fail-level}} / {{-fl}} which is {{error}}
> by default, but could be changed to {{warning}}/{{warn}}. We've had similar
> request and they make sense: one should be able to execute a build without
> any warnings.
> I did an attempt to hook into the Logger to but that seems very tricky. The
> other option is to have this level available in the API, so Maven core and
> plugins can verify it for themselves and decide to throw an Exception. It is
> a simple implementation, but now every component is responsible for checking
> it, not really my preferred solution.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6065) Creating option --fail-on-severity / -fos to support errorless or warningless builds
[
https://issues.apache.org/jira/browse/MNG-6065?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17006328#comment-17006328
]
Hudson commented on MNG-6065:
-
Build succeeded in Jenkins: Maven TLP » maven » MNG-6695 #12
See https://builds.apache.org/job/maven-box/job/maven/job/MNG-6695/12/
> Creating option --fail-on-severity / -fos to support errorless or warningless
> builds
>
>
> Key: MNG-6065
> URL: https://issues.apache.org/jira/browse/MNG-6065
> Project: Maven
> Issue Type: Improvement
>Affects Versions: 3.5.0
>Reporter: Robert Scholte
>Assignee: Robert Scholte
>Priority: Major
> Labels: infosupport
> Fix For: 3.7.0
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> I've been thinking the option {{--fail-level}} / {{-fl}} which is {{error}}
> by default, but could be changed to {{warning}}/{{warn}}. We've had similar
> request and they make sense: one should be able to execute a build without
> any warnings.
> I did an attempt to hook into the Logger to but that seems very tricky. The
> other option is to have this level available in the API, so Maven core and
> plugins can verify it for themselves and decide to throw an Exception. It is
> a simple implementation, but now every component is responsible for checking
> it, not really my preferred solution.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6065) Creating option --fail-on-severity / -fos to support errorless or warningless builds
[
https://issues.apache.org/jira/browse/MNG-6065?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17006325#comment-17006325
]
Hudson commented on MNG-6065:
-
Build unstable in Jenkins: Maven TLP » maven » MNG-6169/MNG-6553 #25
See
https://builds.apache.org/job/maven-box/job/maven/job/MNG-6169%252FMNG-6553/25/
> Creating option --fail-on-severity / -fos to support errorless or warningless
> builds
>
>
> Key: MNG-6065
> URL: https://issues.apache.org/jira/browse/MNG-6065
> Project: Maven
> Issue Type: Improvement
>Affects Versions: 3.5.0
>Reporter: Robert Scholte
>Assignee: Robert Scholte
>Priority: Major
> Labels: infosupport
> Fix For: 3.7.0
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> I've been thinking the option {{--fail-level}} / {{-fl}} which is {{error}}
> by default, but could be changed to {{warning}}/{{warn}}. We've had similar
> request and they make sense: one should be able to execute a build without
> any warnings.
> I did an attempt to hook into the Logger to but that seems very tricky. The
> other option is to have this level available in the API, so Maven core and
> plugins can verify it for themselves and decide to throw an Exception. It is
> a simple implementation, but now every component is responsible for checking
> it, not really my preferred solution.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6065) Creating option --fail-on-severity / -fos to support errorless or warningless builds
[
https://issues.apache.org/jira/browse/MNG-6065?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17006324#comment-17006324
]
Hudson commented on MNG-6065:
-
Build unstable in Jenkins: Maven TLP » maven » MNG-6169/MNG-6556 #30
See
https://builds.apache.org/job/maven-box/job/maven/job/MNG-6169%252FMNG-6556/30/
> Creating option --fail-on-severity / -fos to support errorless or warningless
> builds
>
>
> Key: MNG-6065
> URL: https://issues.apache.org/jira/browse/MNG-6065
> Project: Maven
> Issue Type: Improvement
>Affects Versions: 3.5.0
>Reporter: Robert Scholte
>Assignee: Robert Scholte
>Priority: Major
> Labels: infosupport
> Fix For: 3.7.0
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> I've been thinking the option {{--fail-level}} / {{-fl}} which is {{error}}
> by default, but could be changed to {{warning}}/{{warn}}. We've had similar
> request and they make sense: one should be able to execute a build without
> any warnings.
> I did an attempt to hook into the Logger to but that seems very tricky. The
> other option is to have this level available in the API, so Maven core and
> plugins can verify it for themselves and decide to throw an Exception. It is
> a simple implementation, but now every component is responsible for checking
> it, not really my preferred solution.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6065) Creating option --fail-on-severity / -fos to support errorless or warningless builds
[
https://issues.apache.org/jira/browse/MNG-6065?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17006323#comment-17006323
]
Hudson commented on MNG-6065:
-
Build unstable in Jenkins: Maven TLP » maven » MRESOLVER-93 #6
See https://builds.apache.org/job/maven-box/job/maven/job/MRESOLVER-93/6/
> Creating option --fail-on-severity / -fos to support errorless or warningless
> builds
>
>
> Key: MNG-6065
> URL: https://issues.apache.org/jira/browse/MNG-6065
> Project: Maven
> Issue Type: Improvement
>Affects Versions: 3.5.0
>Reporter: Robert Scholte
>Assignee: Robert Scholte
>Priority: Major
> Labels: infosupport
> Fix For: 3.7.0
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> I've been thinking the option {{--fail-level}} / {{-fl}} which is {{error}}
> by default, but could be changed to {{warning}}/{{warn}}. We've had similar
> request and they make sense: one should be able to execute a build without
> any warnings.
> I did an attempt to hook into the Logger to but that seems very tricky. The
> other option is to have this level available in the API, so Maven core and
> plugins can verify it for themselves and decide to throw an Exception. It is
> a simple implementation, but now every component is responsible for checking
> it, not really my preferred solution.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6065) Creating option --fail-on-severity / -fos to support errorless or warningless builds
[
https://issues.apache.org/jira/browse/MNG-6065?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17006321#comment-17006321
]
Hudson commented on MNG-6065:
-
Build succeeded in Jenkins: Maven TLP » maven » MNG-6747 #9
See https://builds.apache.org/job/maven-box/job/maven/job/MNG-6747/9/
> Creating option --fail-on-severity / -fos to support errorless or warningless
> builds
>
>
> Key: MNG-6065
> URL: https://issues.apache.org/jira/browse/MNG-6065
> Project: Maven
> Issue Type: Improvement
>Affects Versions: 3.5.0
>Reporter: Robert Scholte
>Assignee: Robert Scholte
>Priority: Major
> Labels: infosupport
> Fix For: 3.7.0
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> I've been thinking the option {{--fail-level}} / {{-fl}} which is {{error}}
> by default, but could be changed to {{warning}}/{{warn}}. We've had similar
> request and they make sense: one should be able to execute a build without
> any warnings.
> I did an attempt to hook into the Logger to but that seems very tricky. The
> other option is to have this level available in the API, so Maven core and
> plugins can verify it for themselves and decide to throw an Exception. It is
> a simple implementation, but now every component is responsible for checking
> it, not really my preferred solution.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6065) Creating option --fail-on-severity / -fos to support errorless or warningless builds
[
https://issues.apache.org/jira/browse/MNG-6065?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17006315#comment-17006315
]
Hudson commented on MNG-6065:
-
Build failed in Jenkins: Maven TLP » maven » runITsWithJavaEA #48
See https://builds.apache.org/job/maven-box/job/maven/job/runITsWithJavaEA/48/
> Creating option --fail-on-severity / -fos to support errorless or warningless
> builds
>
>
> Key: MNG-6065
> URL: https://issues.apache.org/jira/browse/MNG-6065
> Project: Maven
> Issue Type: Improvement
>Affects Versions: 3.5.0
>Reporter: Robert Scholte
>Assignee: Robert Scholte
>Priority: Major
> Labels: infosupport
> Fix For: 3.7.0
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> I've been thinking the option {{--fail-level}} / {{-fl}} which is {{error}}
> by default, but could be changed to {{warning}}/{{warn}}. We've had similar
> request and they make sense: one should be able to execute a build without
> any warnings.
> I did an attempt to hook into the Logger to but that seems very tricky. The
> other option is to have this level available in the API, so Maven core and
> plugins can verify it for themselves and decide to throw an Exception. It is
> a simple implementation, but now every component is responsible for checking
> it, not really my preferred solution.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (SUREFIRE-1546) JUnit 5 runner does not honor JUnit 5 display names
[ https://issues.apache.org/jira/browse/SUREFIRE-1546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17006314#comment-17006314 ] Geoff Soutter commented on SUREFIRE-1546: - Awesome work Tibor! I am particularly interested in the use case for DynamicTest and DynamicContainer, so I intend to test the new version and see how that works. I guess Stig will do / has done the same for ParameterizedTest. If I find it is not matching my expectations/hopes, next thing would be to create a pull request with an integration test which shows how I would like it to work, as you suggested. > JUnit 5 runner does not honor JUnit 5 display names > --- > > Key: SUREFIRE-1546 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1546 > Project: Maven Surefire > Issue Type: Bug > Components: JUnit 5.x support >Affects Versions: 2.22.0 >Reporter: Romain Manni-Bucau >Assignee: Tibor Digana >Priority: Major > Labels: junit5 > Fix For: 3.0.0-M4 > > Time Spent: 40m > Remaining Estimate: 0h > > JUnit 5 runner should respect the test @DisplayName instead of displaying the > classname if any is defined. Seems last release doesn't support that feature > of JUnit 5 making the console output and reports not the expected ones. > > Origin: https://github.com/junit-team/junit5/issues/990 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6065) Creating option --fail-on-severity / -fos to support errorless or warningless builds
[
https://issues.apache.org/jira/browse/MNG-6065?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17006308#comment-17006308
]
Hudson commented on MNG-6065:
-
Build succeeded in Jenkins: Maven TLP » maven » MNG-6771 #19
See https://builds.apache.org/job/maven-box/job/maven/job/MNG-6771/19/
> Creating option --fail-on-severity / -fos to support errorless or warningless
> builds
>
>
> Key: MNG-6065
> URL: https://issues.apache.org/jira/browse/MNG-6065
> Project: Maven
> Issue Type: Improvement
>Affects Versions: 3.5.0
>Reporter: Robert Scholte
>Assignee: Robert Scholte
>Priority: Major
> Labels: infosupport
> Fix For: 3.7.0
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> I've been thinking the option {{--fail-level}} / {{-fl}} which is {{error}}
> by default, but could be changed to {{warning}}/{{warn}}. We've had similar
> request and they make sense: one should be able to execute a build without
> any warnings.
> I did an attempt to hook into the Logger to but that seems very tricky. The
> other option is to have this level available in the API, so Maven core and
> plugins can verify it for themselves and decide to throw an Exception. It is
> a simple implementation, but now every component is responsible for checking
> it, not really my preferred solution.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6065) Creating option --fail-on-severity / -fos to support errorless or warningless builds
[
https://issues.apache.org/jira/browse/MNG-6065?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17006305#comment-17006305
]
Hudson commented on MNG-6065:
-
Build failed in Jenkins: Maven TLP » maven » MNG-6829 #4
See https://builds.apache.org/job/maven-box/job/maven/job/MNG-6829/4/
> Creating option --fail-on-severity / -fos to support errorless or warningless
> builds
>
>
> Key: MNG-6065
> URL: https://issues.apache.org/jira/browse/MNG-6065
> Project: Maven
> Issue Type: Improvement
>Affects Versions: 3.5.0
>Reporter: Robert Scholte
>Assignee: Robert Scholte
>Priority: Major
> Labels: infosupport
> Fix For: 3.7.0
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> I've been thinking the option {{--fail-level}} / {{-fl}} which is {{error}}
> by default, but could be changed to {{warning}}/{{warn}}. We've had similar
> request and they make sense: one should be able to execute a build without
> any warnings.
> I did an attempt to hook into the Logger to but that seems very tricky. The
> other option is to have this level available in the API, so Maven core and
> plugins can verify it for themselves and decide to throw an Exception. It is
> a simple implementation, but now every component is responsible for checking
> it, not really my preferred solution.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6065) Creating option --fail-on-severity / -fos to support errorless or warningless builds
[
https://issues.apache.org/jira/browse/MNG-6065?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17006303#comment-17006303
]
Hudson commented on MNG-6065:
-
Build unstable in Jenkins: Maven TLP » maven » mng-5668-poc #12
See https://builds.apache.org/job/maven-box/job/maven/job/mng-5668-poc/12/
> Creating option --fail-on-severity / -fos to support errorless or warningless
> builds
>
>
> Key: MNG-6065
> URL: https://issues.apache.org/jira/browse/MNG-6065
> Project: Maven
> Issue Type: Improvement
>Affects Versions: 3.5.0
>Reporter: Robert Scholte
>Assignee: Robert Scholte
>Priority: Major
> Labels: infosupport
> Fix For: 3.7.0
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> I've been thinking the option {{--fail-level}} / {{-fl}} which is {{error}}
> by default, but could be changed to {{warning}}/{{warn}}. We've had similar
> request and they make sense: one should be able to execute a build without
> any warnings.
> I did an attempt to hook into the Logger to but that seems very tricky. The
> other option is to have this level available in the API, so Maven core and
> plugins can verify it for themselves and decide to throw an Exception. It is
> a simple implementation, but now every component is responsible for checking
> it, not really my preferred solution.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6065) Creating option --fail-on-severity / -fos to support errorless or warningless builds
[
https://issues.apache.org/jira/browse/MNG-6065?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17006300#comment-17006300
]
Hudson commented on MNG-6065:
-
Build failed in Jenkins: Maven TLP » maven » MNG-6825 #7
See https://builds.apache.org/job/maven-box/job/maven/job/MNG-6825/7/
> Creating option --fail-on-severity / -fos to support errorless or warningless
> builds
>
>
> Key: MNG-6065
> URL: https://issues.apache.org/jira/browse/MNG-6065
> Project: Maven
> Issue Type: Improvement
>Affects Versions: 3.5.0
>Reporter: Robert Scholte
>Assignee: Robert Scholte
>Priority: Major
> Labels: infosupport
> Fix For: 3.7.0
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> I've been thinking the option {{--fail-level}} / {{-fl}} which is {{error}}
> by default, but could be changed to {{warning}}/{{warn}}. We've had similar
> request and they make sense: one should be able to execute a build without
> any warnings.
> I did an attempt to hook into the Logger to but that seems very tricky. The
> other option is to have this level available in the API, so Maven core and
> plugins can verify it for themselves and decide to throw an Exception. It is
> a simple implementation, but now every component is responsible for checking
> it, not really my preferred solution.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6065) Creating option --fail-on-severity / -fos to support errorless or warningless builds
[
https://issues.apache.org/jira/browse/MNG-6065?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17006299#comment-17006299
]
Hudson commented on MNG-6065:
-
Build unstable in Jenkins: Maven TLP » maven » EOL #23
See https://builds.apache.org/job/maven-box/job/maven/job/EOL/23/
> Creating option --fail-on-severity / -fos to support errorless or warningless
> builds
>
>
> Key: MNG-6065
> URL: https://issues.apache.org/jira/browse/MNG-6065
> Project: Maven
> Issue Type: Improvement
>Affects Versions: 3.5.0
>Reporter: Robert Scholte
>Assignee: Robert Scholte
>Priority: Major
> Labels: infosupport
> Fix For: 3.7.0
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> I've been thinking the option {{--fail-level}} / {{-fl}} which is {{error}}
> by default, but could be changed to {{warning}}/{{warn}}. We've had similar
> request and they make sense: one should be able to execute a build without
> any warnings.
> I did an attempt to hook into the Logger to but that seems very tricky. The
> other option is to have this level available in the API, so Maven core and
> plugins can verify it for themselves and decide to throw an Exception. It is
> a simple implementation, but now every component is responsible for checking
> it, not really my preferred solution.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6065) Creating option --fail-on-severity / -fos to support errorless or warningless builds
[
https://issues.apache.org/jira/browse/MNG-6065?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17006298#comment-17006298
]
Hudson commented on MNG-6065:
-
Build failed in Jenkins: Maven TLP » maven » MODELTESTS_IMPROVEMENT #8
See
https://builds.apache.org/job/maven-box/job/maven/job/MODELTESTS_IMPROVEMENT/8/
> Creating option --fail-on-severity / -fos to support errorless or warningless
> builds
>
>
> Key: MNG-6065
> URL: https://issues.apache.org/jira/browse/MNG-6065
> Project: Maven
> Issue Type: Improvement
>Affects Versions: 3.5.0
>Reporter: Robert Scholte
>Assignee: Robert Scholte
>Priority: Major
> Labels: infosupport
> Fix For: 3.7.0
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> I've been thinking the option {{--fail-level}} / {{-fl}} which is {{error}}
> by default, but could be changed to {{warning}}/{{warn}}. We've had similar
> request and they make sense: one should be able to execute a build without
> any warnings.
> I did an attempt to hook into the Logger to but that seems very tricky. The
> other option is to have this level available in the API, so Maven core and
> plugins can verify it for themselves and decide to throw an Exception. It is
> a simple implementation, but now every component is responsible for checking
> it, not really my preferred solution.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6065) Creating option --fail-on-severity / -fos to support errorless or warningless builds
[
https://issues.apache.org/jira/browse/MNG-6065?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17006297#comment-17006297
]
Hudson commented on MNG-6065:
-
Build unstable in Jenkins: Maven TLP » maven » REMOVE_DEPRECATED #4
See https://builds.apache.org/job/maven-box/job/maven/job/REMOVE_DEPRECATED/4/
> Creating option --fail-on-severity / -fos to support errorless or warningless
> builds
>
>
> Key: MNG-6065
> URL: https://issues.apache.org/jira/browse/MNG-6065
> Project: Maven
> Issue Type: Improvement
>Affects Versions: 3.5.0
>Reporter: Robert Scholte
>Assignee: Robert Scholte
>Priority: Major
> Labels: infosupport
> Fix For: 3.7.0
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> I've been thinking the option {{--fail-level}} / {{-fl}} which is {{error}}
> by default, but could be changed to {{warning}}/{{warn}}. We've had similar
> request and they make sense: one should be able to execute a build without
> any warnings.
> I did an attempt to hook into the Logger to but that seems very tricky. The
> other option is to have this level available in the API, so Maven core and
> plugins can verify it for themselves and decide to throw an Exception. It is
> a simple implementation, but now every component is responsible for checking
> it, not really my preferred solution.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6065) Creating option --fail-on-severity / -fos to support errorless or warningless builds
[
https://issues.apache.org/jira/browse/MNG-6065?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17006296#comment-17006296
]
Hudson commented on MNG-6065:
-
Build unstable in Jenkins: Maven TLP » maven » MNG-6824 #4
See https://builds.apache.org/job/maven-box/job/maven/job/MNG-6824/4/
> Creating option --fail-on-severity / -fos to support errorless or warningless
> builds
>
>
> Key: MNG-6065
> URL: https://issues.apache.org/jira/browse/MNG-6065
> Project: Maven
> Issue Type: Improvement
>Affects Versions: 3.5.0
>Reporter: Robert Scholte
>Assignee: Robert Scholte
>Priority: Major
> Labels: infosupport
> Fix For: 3.7.0
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> I've been thinking the option {{--fail-level}} / {{-fl}} which is {{error}}
> by default, but could be changed to {{warning}}/{{warn}}. We've had similar
> request and they make sense: one should be able to execute a build without
> any warnings.
> I did an attempt to hook into the Logger to but that seems very tricky. The
> other option is to have this level available in the API, so Maven core and
> plugins can verify it for themselves and decide to throw an Exception. It is
> a simple implementation, but now every component is responsible for checking
> it, not really my preferred solution.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6065) Creating option --fail-on-severity / -fos to support errorless or warningless builds
[
https://issues.apache.org/jira/browse/MNG-6065?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17006293#comment-17006293
]
Hudson commented on MNG-6065:
-
Build unstable in Jenkins: Maven TLP » maven » MNG-6512-build-11 #2
See https://builds.apache.org/job/maven-box/job/maven/job/MNG-6512-build-11/2/
> Creating option --fail-on-severity / -fos to support errorless or warningless
> builds
>
>
> Key: MNG-6065
> URL: https://issues.apache.org/jira/browse/MNG-6065
> Project: Maven
> Issue Type: Improvement
>Affects Versions: 3.5.0
>Reporter: Robert Scholte
>Assignee: Robert Scholte
>Priority: Major
> Labels: infosupport
> Fix For: 3.7.0
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> I've been thinking the option {{--fail-level}} / {{-fl}} which is {{error}}
> by default, but could be changed to {{warning}}/{{warn}}. We've had similar
> request and they make sense: one should be able to execute a build without
> any warnings.
> I did an attempt to hook into the Logger to but that seems very tricky. The
> other option is to have this level available in the API, so Maven core and
> plugins can verify it for themselves and decide to throw an Exception. It is
> a simple implementation, but now every component is responsible for checking
> it, not really my preferred solution.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [maven] rosti-il opened a new pull request #304: Prevent printing the EXEC_DIR when it's just a disk letter
rosti-il opened a new pull request #304: Prevent printing the EXEC_DIR when it's just a disk letter URL: https://github.com/apache/maven/pull/304 This fixes following bug and also consistent with another 'cd /d "%EXEC_DIR%"' a few lines above. When you're on the root of some disk running mvn.cmd prints an extra line with current dir before the correct output. For example: D:\>mvn -version D:\ Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f) Maven home: D:\develop\apache-maven-3.6.3\bin\.. Java version: 11.0.5, vendor: Oracle Corporation, runtime: C:\Program Files\Java\jdk-11.0.5 Default locale: en_US, platform encoding: Cp1252 OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows" 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 With regards, Apache Git Services
[jira] [Commented] (MASSEMBLY-920) ContainerDescriptorHandler for MetaInf-Services breaks folder structure
[
https://issues.apache.org/jira/browse/MASSEMBLY-920?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17006174#comment-17006174
]
Steve R commented on MASSEMBLY-920:
---
Ah yeah this is biting me too.
> ContainerDescriptorHandler for MetaInf-Services breaks folder structure
> ---
>
> Key: MASSEMBLY-920
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-920
> Project: Maven Assembly Plugin
> Issue Type: Bug
>Affects Versions: 3.1.1
>Reporter: Otavio Biasutti
>Priority: Major
> Attachments: massembly-920.zip
>
>
> I have my own jar-with-dependecies assembly and I need to use the
> MetaInf-Services ContainerDescriptorHandler to aggregate all services and
> avoid overriding.
> The plugin does not respect the folder structure inside META-INF/services.
> Camel is a good example of dependecy that can be used to reproduce the
> problem. It defines its services in a nested folder structure, as in:
> {quote}
> META-INF/services/org/apache/camel/TypeConverter
> {quote}
> What really happens is that the folder structure is indeed created but the
> TypeConverter file is moved to the root of the services, i.e.
> *META-INF/services*
> I had to patch the code and define a custom ContainerDescriptorHandler to fix
> the problem.
> The fix is straightforward. I simply inherited the provided implementation of
> MetaInfServiceHandler and coded an overriden version of the following method
> like this:
> {code}
> @Override
> protected String getOutputPathPrefix(final FileInfo fileInfo) {
> return Paths.get(fileInfo.getName()).getParent().toString() + "/";
> }
> {code}
> All services were properly aggreggated after that.
> This may be the best fix for several related bugs I found online, like this
> one here:
> https://stackoverflow.com/questions/37304195/camel-restlet-not-working-in-jar
> Cheer
> Otávio
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MASSEMBLY-925) Detailed error message on assembly failure
[ https://issues.apache.org/jira/browse/MASSEMBLY-925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17006120#comment-17006120 ] Michael Osipov commented on MASSEMBLY-925: -- OK, thanks for the confirmation. > Detailed error message on assembly failure > -- > > Key: MASSEMBLY-925 > URL: https://issues.apache.org/jira/browse/MASSEMBLY-925 > Project: Maven Assembly Plugin > Issue Type: Improvement >Affects Versions: 3.2.0 >Reporter: Christian Domsch >Priority: Major > > If the assembly fails during processing of its dependencySets/fileSets, it > would be very convenient to get the current set/item it is trying to work on > while it fails. > I just lost about a couple days worth of tracking down, why my assembly > failed with the message: "Failed to create assembly: Error creating assembly > archive base: archive is not a ZIP archive -> [Help 1]" > Long story short, in our package feed (we are building our software in Azure) > one dependency that we used had a corrupt ZIP archive. Since this assembly is > the final one we use to build our installers, it contains 50 dependencySets > and some files and filesets. Which means, tracking down which of those was > causing the issue while one build roughly takes 40mins, is very time > consuming. > In order to improve this, it would be very helpful, if in the event of an > error, the plugin would tell you which module/dependency/file it actually > failed on. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [maven-changes-plugin] Nyamiou commented on a change in pull request #1: Fix the issue MCHANGES-398 that was caused by the change MPIR-323
Nyamiou commented on a change in pull request #1: Fix the issue MCHANGES-398 that was caused by the change MPIR-323 URL: https://github.com/apache/maven-changes-plugin/pull/1#discussion_r362209712 ## File path: src/main/java/org/apache/maven/plugins/changes/ChangesMojo.java ## @@ -191,7 +191,7 @@ * * @since 2.4 */ -@Parameter( defaultValue = "team-list.html" ) +@Parameter( defaultValue = "team.html" ) private String teamlist; Review comment: Done, the parameter is now "team". 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 With regards, Apache Git Services
[jira] [Comment Edited] (MASSEMBLY-925) Detailed error message on assembly failure
[ https://issues.apache.org/jira/browse/MASSEMBLY-925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17006055#comment-17006055 ] Christian Domsch edited comment on MASSEMBLY-925 at 12/31/19 11:11 AM: --- No, in this case it didn't help. This might also be due to the fact that -X caused such a tremendous amount of information that it overloaded everything. But regardless of that, I went into the -X logs and couldn't track down which dependency/artifact was causing the problem. was (Author: cdomsch): Not, in this case it didn't help. This might also be due to the fact that -X caused such a tremendous amount of information that it overloaded everything. But regardless of that, I went into the -X logs and couldn't track down which dependency/artifact was causing the problem. > Detailed error message on assembly failure > -- > > Key: MASSEMBLY-925 > URL: https://issues.apache.org/jira/browse/MASSEMBLY-925 > Project: Maven Assembly Plugin > Issue Type: Improvement >Affects Versions: 3.2.0 >Reporter: Christian Domsch >Priority: Major > > If the assembly fails during processing of its dependencySets/fileSets, it > would be very convenient to get the current set/item it is trying to work on > while it fails. > I just lost about a couple days worth of tracking down, why my assembly > failed with the message: "Failed to create assembly: Error creating assembly > archive base: archive is not a ZIP archive -> [Help 1]" > Long story short, in our package feed (we are building our software in Azure) > one dependency that we used had a corrupt ZIP archive. Since this assembly is > the final one we use to build our installers, it contains 50 dependencySets > and some files and filesets. Which means, tracking down which of those was > causing the issue while one build roughly takes 40mins, is very time > consuming. > In order to improve this, it would be very helpful, if in the event of an > error, the plugin would tell you which module/dependency/file it actually > failed on. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MASSEMBLY-925) Detailed error message on assembly failure
[ https://issues.apache.org/jira/browse/MASSEMBLY-925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17006055#comment-17006055 ] Christian Domsch commented on MASSEMBLY-925: Not, in this case it didn't help. This might also be due to the fact that -X caused such a tremendous amount of information that it overloaded everything. But regardless of that, I went into the -X logs and couldn't track down which dependency/artifact was causing the problem. > Detailed error message on assembly failure > -- > > Key: MASSEMBLY-925 > URL: https://issues.apache.org/jira/browse/MASSEMBLY-925 > Project: Maven Assembly Plugin > Issue Type: Improvement >Affects Versions: 3.2.0 >Reporter: Christian Domsch >Priority: Major > > If the assembly fails during processing of its dependencySets/fileSets, it > would be very convenient to get the current set/item it is trying to work on > while it fails. > I just lost about a couple days worth of tracking down, why my assembly > failed with the message: "Failed to create assembly: Error creating assembly > archive base: archive is not a ZIP archive -> [Help 1]" > Long story short, in our package feed (we are building our software in Azure) > one dependency that we used had a corrupt ZIP archive. Since this assembly is > the final one we use to build our installers, it contains 50 dependencySets > and some files and filesets. Which means, tracking down which of those was > causing the issue while one build roughly takes 40mins, is very time > consuming. > In order to improve this, it would be very helpful, if in the event of an > error, the plugin would tell you which module/dependency/file it actually > failed on. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (MSHADE-343) Shaded artifact has no version when finalName is set
[
https://issues.apache.org/jira/browse/MSHADE-343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed MSHADE-343.
-
Assignee: Robert Scholte
Resolution: Not A Bug
> Shaded artifact has no version when finalName is set
>
>
> Key: MSHADE-343
> URL: https://issues.apache.org/jira/browse/MSHADE-343
> Project: Maven Shade Plugin
> Issue Type: Bug
>Affects Versions: 3.2.2
>Reporter: Peter De Maeyer
>Assignee: Robert Scholte
>Priority: Minor
>
> {{ShadeMojo.shadedArtifactFile}} omits the version in the shaded artifact
> file name when {{finalName}} is set.
> That looks like a bug: I think the version should be part of the
> {{shadedName}} in any case.
> I just found this by eyeballing the code, I haven't tried reproducing it with
> an actual scenario yet.
> It only affects situations where {{finalName}} is explicitly set, and it only
> affects non-main artifacts (test jar, sources and test sources).
> The main shaded jar artifact doesn't go through this code path AFAICT, so is
> not affected.
> {code:java}
> if ( project.getBuild().getFinalName() != null )
> {
> // Shouldn't artifact.getVersion() be part of the shadedName here
> too?
> shadedName = project.getBuild().getFinalName() + "-" + classifier
> + "."
> + artifact.getArtifactHandler().getExtension();
> }
> else
> {
> shadedName = shadedArtifactId + "-" + artifact.getVersion() + "-"
> + classifier + "."
> + artifact.getArtifactHandler().getExtension();
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
