[jira] [Commented] (MPOM-244) Upload SHA-512 to Staging Repository
[ https://issues.apache.org/jira/browse/MPOM-244?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17245755#comment-17245755 ] Konrad Windszus commented on MPOM-244: -- Manual steps fiddling with your Maven installation are IMHO too much effort. I guess this can only be fixed once Maven 4 is released and enforced... > Upload SHA-512 to Staging Repository > > > Key: MPOM-244 > URL: https://issues.apache.org/jira/browse/MPOM-244 > Project: Maven POMs > Issue Type: Improvement >Affects Versions: ASF-23 >Reporter: Konrad Windszus >Priority: Major > > As now the ASF staging repository supports SHA2 hashes > (https://issues.apache.org/jira/browse/INFRA-14923) they should be generated > for > - all attached artifacts and > - deployed to the Staging repository (i.e. attached to build as well) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [maven-checkstyle-plugin] bmarwell commented on pull request #17: [MCHECKSTYLE-385] rework code to use a Violation.java class.
bmarwell commented on pull request #17: URL: https://github.com/apache/maven-checkstyle-plugin/pull/17#issuecomment-740494240 Rebased, CI running again https://ci-builds.apache.org/blue/organizations/jenkins/Maven%2Fmaven-box%2Fmaven-checkstyle-plugin/detail/MCHECKSTYLE-385/15/pipeline 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-checkstyle-plugin] bmarwell commented on pull request #17: [MCHECKSTYLE-385] rework code to use a Violation.java class.
bmarwell commented on pull request #17: URL: https://github.com/apache/maven-checkstyle-plugin/pull/17#issuecomment-740508298 Fixed in https://github.com/apache/maven-checkstyle-plugin/commit/b259e84bdd0ed798ec52d1500d8323c18f0790ea. 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-checkstyle-plugin] bmarwell closed pull request #17: [MCHECKSTYLE-385] rework code to use a Violation.java class.
bmarwell closed pull request #17: URL: https://github.com/apache/maven-checkstyle-plugin/pull/17 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] rmannibucau commented on pull request #21: [MJLINK-52] Add classifier support
rmannibucau commented on pull request #21: URL: https://github.com/apache/maven-jlink-plugin/pull/21#issuecomment-740512358 Looks better than it was so +1. Can need some more tests like with a null module artifact or switched one but can come later imho. 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] rmannibucau commented on pull request #23: [MJLINK-57] Migrate to slf4j
rmannibucau commented on pull request #23: URL: https://github.com/apache/maven-jlink-plugin/pull/23#issuecomment-740513922 Isnt it better to use the class logger like before rather than a static one which looses the context when logging the class name for these cases? Also not sure it is worth using slf4j first and put it at plugin level, we use maven one so it should be provided anyway. 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] (MCHECKSTYLE-385) Violation should be a value class
[
https://issues.apache.org/jira/browse/MCHECKSTYLE-385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17245783#comment-17245783
]
Hudson commented on MCHECKSTYLE-385:
Build succeeded in Jenkins: Maven » Maven TLP » maven-checkstyle-plugin »
master #23
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven-checkstyle-plugin/job/master/23/
> Violation should be a value class
> -
>
> Key: MCHECKSTYLE-385
> URL: https://issues.apache.org/jira/browse/MCHECKSTYLE-385
> Project: Maven Checkstyle Plugin
> Issue Type: Improvement
> Components: checkstyle:check
>Affects Versions: 3.1.0
> Environment: Any (Linux, Window OS, etc.)
>Reporter: Benjamin Marwell
>Priority: Minor
> Labels: easyfix, pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Dear developers,
> while starting to implement the feature
> https://issues.apache.org/jira/browse/MCHECKSTYLE-356, I found out that a
> refactoring is needed.
>
> The method {color:#403294}{{int countViolations(Parser)}}{color} does so many
> things besides counting violations. Some of them are:
> * checking, if printing violations is wanted.
> * actually printing violations
> * counting violations
> * counting ignored violations
> * checking ignored violations count > 0 and logging
> * Keeping track of file changes
> I would like to rework this part of the code with no functional changes by
> creating a "Violation" value class.
> PR follows.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (MCHECKSTYLE-385) Violation should be a value class
[
https://issues.apache.org/jira/browse/MCHECKSTYLE-385?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Marwell resolved MCHECKSTYLE-385.
--
Fix Version/s: 3.1.2
Assignee: Benjamin Marwell
Resolution: Fixed
> Violation should be a value class
> -
>
> Key: MCHECKSTYLE-385
> URL: https://issues.apache.org/jira/browse/MCHECKSTYLE-385
> Project: Maven Checkstyle Plugin
> Issue Type: Improvement
> Components: checkstyle:check
>Affects Versions: 3.1.0
> Environment: Any (Linux, Window OS, etc.)
>Reporter: Benjamin Marwell
>Assignee: Benjamin Marwell
>Priority: Minor
> Labels: easyfix, pull-request-available
> Fix For: 3.1.2
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Dear developers,
> while starting to implement the feature
> https://issues.apache.org/jira/browse/MCHECKSTYLE-356, I found out that a
> refactoring is needed.
>
> The method {color:#403294}{{int countViolations(Parser)}}{color} does so many
> things besides counting violations. Some of them are:
> * checking, if printing violations is wanted.
> * actually printing violations
> * counting violations
> * counting ignored violations
> * checking ignored violations count > 0 and logging
> * Keeping track of file changes
> I would like to rework this part of the code with no functional changes by
> creating a "Violation" value class.
> PR follows.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MPOM-244) Upload SHA-512 to Staging Repository
[ https://issues.apache.org/jira/browse/MPOM-244?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17245814#comment-17245814 ] Michael Osipov commented on MPOM-244: - If you really need it, you will do it. > Upload SHA-512 to Staging Repository > > > Key: MPOM-244 > URL: https://issues.apache.org/jira/browse/MPOM-244 > Project: Maven POMs > Issue Type: Improvement >Affects Versions: ASF-23 >Reporter: Konrad Windszus >Priority: Major > > As now the ASF staging repository supports SHA2 hashes > (https://issues.apache.org/jira/browse/INFRA-14923) they should be generated > for > - all attached artifacts and > - deployed to the Staging repository (i.e. attached to build as well) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [maven-jlink-plugin] bmarwell commented on pull request #20: (build) Add Java8 + Toolchain tests
bmarwell commented on pull request #20: URL: https://github.com/apache/maven-jlink-plugin/pull/20#issuecomment-740547709 > The "jabba + openj9@11" could be replaced with a usage of setup-java action. Not? I would not know how. The Jabba plugin puts the installation path into an env variable which I use for the toolchain. AFAIK, the setup-java action cannot do that and will always update $JAVA_HOME. Reference: https://github.com/actions/setup-java/blob/61c9e3a719405cb24d9c40bd15467232f9ab55bc/action.yml#L49-L51 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] bmarwell commented on pull request #14: [MJLINK-41] add support for --add-options argument (JDK14+).
bmarwell commented on pull request #14: URL: https://github.com/apache/maven-jlink-plugin/pull/14#issuecomment-740548516 > Small point: should jvm version be checked to fail if it is not supported? Thanks, I will add a nice error message if neither the toolchain (if present) nor the maven JDK is at least Java 14. 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] bmarwell commented on pull request #23: [MJLINK-57] Migrate to slf4j
bmarwell commented on pull request #23: URL: https://github.com/apache/maven-jlink-plugin/pull/23#issuecomment-740549053 > Isnt it better to use the class logger like before rather than a static one which looses the context when logging the class name for these cases? > Also not sure it is worth using slf4j first and put it at plugin level, we use maven one so it should be provided anyway. We came up with this Issue and PR because Elliotte suggested to use slf4j. I think he refers to this page: https://maven.apache.org/maven-logging.html Is this still valid? 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] elharo commented on pull request #23: [MJLINK-57] Migrate to slf4j
elharo commented on pull request #23: URL: https://github.com/apache/maven-jlink-plugin/pull/23#issuecomment-740551021 Yes, we'd like to get rid of the maven logging and just use SLF4J everywhere 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] rmannibucau commented on pull request #23: [MJLINK-57] Migrate to slf4j
rmannibucau commented on pull request #23: URL: https://github.com/apache/maven-jlink-plugin/pull/23#issuecomment-740553825 My point was not about slf4j, the slf4j part was just "no need to move mojo to another logger since correct logger setup is already wired", the point is that the logger is not equivalent to previous one and IMHO it is important to keep the behavior we have with getLog() for loggers (which implies moving to slf4j direct API is a wrong solution for mojos but this is a side effect of the real point). 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] bmarwell commented on pull request #21: [MJLINK-52] Add classifier support
bmarwell commented on pull request #21: URL: https://github.com/apache/maven-jlink-plugin/pull/21#issuecomment-740554700 Hey, I will not merge it right now because I just saw the the plugin will always write to `target/maven-jlink`. If multiple artifacts would be generated, they would overwrite each other. Thus, subfolders will be needed. 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] (DOXIA-616) Markdown: Properly expose the language specified in fenced code blocks
[
https://issues.apache.org/jira/browse/DOXIA-616?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17245837#comment-17245837
]
Bertrand Martin commented on DOXIA-616:
---
[~hboutemy][~michael-o][~michaelo] Guys, does this sound a reasonable
enhancement? (looks like to me...)
> Markdown: Properly expose the language specified in fenced code blocks
> --
>
> Key: DOXIA-616
> URL: https://issues.apache.org/jira/browse/DOXIA-616
> Project: Maven Doxia
> Issue Type: Improvement
> Components: Module - Markdown
>Affects Versions: 1.8, 1.9, 1.9.1
>Reporter: Bertrand Martin
>Priority: Major
>
> h1. Use Case
> Writers can specify the language used in a fenced code block (typically for
> syntax highlighting), as in the example below:
> {code}
> ```java
> System.out.println("Beautiful\n");
> ```
> {code}
> Currently, the Doxia module for Markdown does not expose this information
> ("java") in the produced HTML, so a Maven skin (or frontend renderer) cannot
> leverage it.
> Produced HTML:
> {code:html}
>
>
> System.out.println("Beautiful\n");
>
>
> {code}
> Wanted result:
> {code:html}
>
>
> System.out.println("Beautiful\n");
>
>
> {code}
> h1. Specification
> Un-comment this block:
> https://github.com/apache/maven-doxia/blob/c439714e8f4a9e86f9962ac6be9a0077ae9b4d30/doxia-modules/doxia-module-markdown/src/main/java/org/apache/maven/doxia/module/markdown/FlexmarkDoxiaNodeRenderer.java#L103
> This should do the trick.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [maven-jlink-plugin] elharo commented on pull request #23: [MJLINK-57] Migrate to slf4j
elharo commented on pull request #23: URL: https://github.com/apache/maven-jlink-plugin/pull/23#issuecomment-740578992 This plugin has only been released in alpha so far. Thus no need to worry about API compatibility. 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] rmannibucau commented on pull request #23: [MJLINK-57] Migrate to slf4j
rmannibucau commented on pull request #23: URL: https://github.com/apache/maven-jlink-plugin/pull/23#issuecomment-740598352 @elharo it is not about the plugin compat but the feature it provides. A logger per mojo is a key feature for logs (in particular on CI), moving to a static instance breaks that (this is where getLog() is a saner pattern we shouldn't drop) 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] bmarwell commented on pull request #23: [MJLINK-57] Migrate to slf4j
bmarwell commented on pull request #23: URL: https://github.com/apache/maven-jlink-plugin/pull/23#issuecomment-740619544 > This plugin has only been released in alpha so far. Thus no need to worry about API compatibility. Sorry, you might have missed that, but there is a 3.0.0 release: https://search.maven.org/artifact/org.apache.maven.plugins/maven-jlink-plugin/3.0.0/maven-plugin Good thing you mentioned it. That might resolve a bit of the confusion we had. 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] elharo commented on pull request #23: [MJLINK-57] Migrate to slf4j
elharo commented on pull request #23: URL: https://github.com/apache/maven-jlink-plugin/pull/23#issuecomment-740621788 The [website](https://maven.apache.org/plugins/maven-jlink-plugin/) prominently states, "NOTE: This is an alpha release which means everything can change until we reach the first milestone release." 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-7049) Version range resolution downloads all poms, not just the highest version
Moti Nisenson-Ken created MNG-7049: -- Summary: Version range resolution downloads all poms, not just the highest version Key: MNG-7049 URL: https://issues.apache.org/jira/browse/MNG-7049 Project: Maven Issue Type: Bug Components: core Reporter: Moti Nisenson-Ken When specifying a version range for a dependency, maven will download and try to resolve all poms in that range which satisfy the range. The usage however is only to use the highestVersion. This causes two issues: # Performance - it's downloading numerous poms that aren't needed. # Fragility - if the version range covers any "bad" poms, then the build will fail. For example, consider that for a specific version, the parent of a pom is not present in the repository. This is enough to fail any build with a version range covering that specific version, as the range resolution stage will not complete. This is particularly harmful when that version would not be selected as the highest, anyway. Recommend to have a system property to control the desired behavior - it should be possible to short-circuit loading all the versions and to just to load the highest version. For another user report of this see: [https://stackoverflow.com/questions/25047859/restrict-maven-to-not-download-all-poms] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [maven-jlink-plugin] bmarwell commented on pull request #23: [MJLINK-57] Migrate to slf4j
bmarwell commented on pull request #23: URL: https://github.com/apache/maven-jlink-plugin/pull/23#issuecomment-740622513 > The [website](https://maven.apache.org/plugins/maven-jlink-plugin/) prominently states, "NOTE: This is an alpha release which means everything can change until we reach the first milestone release." That is why this issue exists: https://issues.apache.org/jira/browse/MJLINK-60 Along with this commit: https://github.com/apache/maven-jlink-plugin/commit/5e2b1272727400d81eb64a3de50557f343097319 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] rmannibucau commented on pull request #23: [MJLINK-57] Migrate to slf4j
rmannibucau commented on pull request #23: URL: https://github.com/apache/maven-jlink-plugin/pull/23#issuecomment-740628359 Hey guys, lt's keep the site update discussion for another thread, think we have enough with make the logger setup right. So we have 2 options I think: 1. do nothing (and I think it is fine) 2. use slf4j at the risk ot break some integration but if desired we must ensure it is done properly and not breaking the logging setup as mentionned I'm fine with both options while they are both correctly done ;). 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] rmannibucau edited a comment on pull request #23: [MJLINK-57] Migrate to slf4j
rmannibucau edited a comment on pull request #23: URL: https://github.com/apache/maven-jlink-plugin/pull/23#issuecomment-740628359 Hey guys, let's keep the site update discussion for another thread, think we have enough with make the logger setup right. So we have 2 options I think: 1. do nothing (and I think it is fine) 2. use slf4j at the risk ot break some integration but if desired we must ensure it is done properly and not breaking the logging setup as mentionned I'm fine with both options while they are both correctly done ;). 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] bmarwell commented on pull request #23: [MJLINK-57] Migrate to slf4j
bmarwell commented on pull request #23: URL: https://github.com/apache/maven-jlink-plugin/pull/23#issuecomment-740629505 This must be discussed on the mailing list. @elharo can you do that please? 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] struberg commented on pull request #23: [MJLINK-57] Migrate to slf4j
struberg commented on pull request #23: URL: https://github.com/apache/maven-jlink-plugin/pull/23#issuecomment-740632700 Hmm, to be honest - I still see no reason to use slf4j over our very own logging API. The discussion is very old actually, and I never was a fan of dropping our own classes in favour to some external dependencies. Did serve us very badly for quite a few cases over the years. Any class we explose in the classloader might create class clashes. The slf4j-api is rather stable, but even there there HAVE been bytecode incompatible changes. And then you need to do all sorts of crazy custom UrlClassLoaders with filtering inbetween just to not create classpath clashes with the projects being built. All that can be spared if we solely only expose and use our very own internal API and then (isolated in the very core) delegate to whatever logging backend we want. See https://issues.apache.org/jira/browse/MNG-7045 for a very similar issue. 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] rmannibucau commented on pull request #23: [MJLINK-57] Migrate to slf4j
rmannibucau commented on pull request #23: URL: https://github.com/apache/maven-jlink-plugin/pull/23#issuecomment-740635441 Strictly speaking slf4j is NOT stable (only 1.7 is stable and not last one sadly so it will break soon too). Other issue is that maven leaks slf4j without hanling slf4j configuration per classloader which leads to issue - but this is not related to this PR, more to a wrong decision earlier (or "wrong good idea" more exactly ;)). So do we lean towards cancelling this PR? No issue on my side for that. 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] (DOXIA-616) Markdown: Properly expose the language specified in fenced code blocks
[
https://issues.apache.org/jira/browse/DOXIA-616?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17245923#comment-17245923
]
Michael Osipov commented on DOXIA-616:
--
It does. The first question, does the code highligher we are using support ths.
> Markdown: Properly expose the language specified in fenced code blocks
> --
>
> Key: DOXIA-616
> URL: https://issues.apache.org/jira/browse/DOXIA-616
> Project: Maven Doxia
> Issue Type: Improvement
> Components: Module - Markdown
>Affects Versions: 1.8, 1.9, 1.9.1
>Reporter: Bertrand Martin
>Priority: Major
>
> h1. Use Case
> Writers can specify the language used in a fenced code block (typically for
> syntax highlighting), as in the example below:
> {code}
> ```java
> System.out.println("Beautiful\n");
> ```
> {code}
> Currently, the Doxia module for Markdown does not expose this information
> ("java") in the produced HTML, so a Maven skin (or frontend renderer) cannot
> leverage it.
> Produced HTML:
> {code:html}
>
>
> System.out.println("Beautiful\n");
>
>
> {code}
> Wanted result:
> {code:html}
>
>
> System.out.println("Beautiful\n");
>
>
> {code}
> h1. Specification
> Un-comment this block:
> https://github.com/apache/maven-doxia/blob/c439714e8f4a9e86f9962ac6be9a0077ae9b4d30/doxia-modules/doxia-module-markdown/src/main/java/org/apache/maven/doxia/module/markdown/FlexmarkDoxiaNodeRenderer.java#L103
> This should do the trick.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (DOXIA-616) Markdown: Properly expose the language specified in fenced code blocks
[
https://issues.apache.org/jira/browse/DOXIA-616?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17245923#comment-17245923
]
Michael Osipov edited comment on DOXIA-616 at 12/8/20, 2:39 PM:
It does. The first question is, does the code highligher we are using support
ths?
was (Author: michael-o):
It does. The first question, does the code highligher we are using support ths.
> Markdown: Properly expose the language specified in fenced code blocks
> --
>
> Key: DOXIA-616
> URL: https://issues.apache.org/jira/browse/DOXIA-616
> Project: Maven Doxia
> Issue Type: Improvement
> Components: Module - Markdown
>Affects Versions: 1.8, 1.9, 1.9.1
>Reporter: Bertrand Martin
>Priority: Major
>
> h1. Use Case
> Writers can specify the language used in a fenced code block (typically for
> syntax highlighting), as in the example below:
> {code}
> ```java
> System.out.println("Beautiful\n");
> ```
> {code}
> Currently, the Doxia module for Markdown does not expose this information
> ("java") in the produced HTML, so a Maven skin (or frontend renderer) cannot
> leverage it.
> Produced HTML:
> {code:html}
>
>
> System.out.println("Beautiful\n");
>
>
> {code}
> Wanted result:
> {code:html}
>
>
> System.out.println("Beautiful\n");
>
>
> {code}
> h1. Specification
> Un-comment this block:
> https://github.com/apache/maven-doxia/blob/c439714e8f4a9e86f9962ac6be9a0077ae9b4d30/doxia-modules/doxia-module-markdown/src/main/java/org/apache/maven/doxia/module/markdown/FlexmarkDoxiaNodeRenderer.java#L103
> This should do the trick.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (DOXIA-616) Markdown: Properly expose the language specified in fenced code blocks
[
https://issues.apache.org/jira/browse/DOXIA-616?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17245923#comment-17245923
]
Michael Osipov edited comment on DOXIA-616 at 12/8/20, 2:39 PM:
It does. The first question is, does the code highligher we are using support
this?
was (Author: michael-o):
It does. The first question is, does the code highligher we are using support
ths?
> Markdown: Properly expose the language specified in fenced code blocks
> --
>
> Key: DOXIA-616
> URL: https://issues.apache.org/jira/browse/DOXIA-616
> Project: Maven Doxia
> Issue Type: Improvement
> Components: Module - Markdown
>Affects Versions: 1.8, 1.9, 1.9.1
>Reporter: Bertrand Martin
>Priority: Major
>
> h1. Use Case
> Writers can specify the language used in a fenced code block (typically for
> syntax highlighting), as in the example below:
> {code}
> ```java
> System.out.println("Beautiful\n");
> ```
> {code}
> Currently, the Doxia module for Markdown does not expose this information
> ("java") in the produced HTML, so a Maven skin (or frontend renderer) cannot
> leverage it.
> Produced HTML:
> {code:html}
>
>
> System.out.println("Beautiful\n");
>
>
> {code}
> Wanted result:
> {code:html}
>
>
> System.out.println("Beautiful\n");
>
>
> {code}
> h1. Specification
> Un-comment this block:
> https://github.com/apache/maven-doxia/blob/c439714e8f4a9e86f9962ac6be9a0077ae9b4d30/doxia-modules/doxia-module-markdown/src/main/java/org/apache/maven/doxia/module/markdown/FlexmarkDoxiaNodeRenderer.java#L103
> This should do the trick.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [maven-jlink-plugin] elharo commented on pull request #23: [MJLINK-57] Migrate to slf4j
elharo commented on pull request #23: URL: https://github.com/apache/maven-jlink-plugin/pull/23#issuecomment-740673182 The current Maven project-wide decision is to use SLF4J. That's not what I would have chosen, but we shouldn't be deciding this on a plugin-by-plugin basis. Any changes to that policy should be made for the entire Maven project, not in one PR in one plugin. 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] rmannibucau commented on pull request #23: [MJLINK-57] Migrate to slf4j
rmannibucau commented on pull request #23: URL: https://github.com/apache/maven-jlink-plugin/pull/23#issuecomment-740676395 @elharo think there is a misconception there, maven != plugins. Plugins must use plugin API, nothing complicated. For maven-core there is this partial - since it was not agreed by everyone - decision to use slf4j. Here we are clearly in plugin land. BTW we can review this decision now master is on 4.x. 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] elharo commented on pull request #23: [MJLINK-57] Migrate to slf4j
elharo commented on pull request #23: URL: https://github.com/apache/maven-jlink-plugin/pull/23#issuecomment-740709447 I don't agree. This is a project wide decision. There's a lot of shared infrastructure and code between the plugins and the core. They should follow the same standards. 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] rmannibucau commented on pull request #23: [MJLINK-57] Migrate to slf4j
rmannibucau commented on pull request #23: URL: https://github.com/apache/maven-jlink-plugin/pull/23#issuecomment-740739995 @elharo we can agree to disagree but this thread tend to proove this is not right and we don't have any slf4j mojo alternative to getLog() to ensure logger is correct (as shown in this PR it is not) so guess slf4j is not an option for mojo until we get a getSlf4jLog() in the AbstractMojo and it will likely not be tomorrow since slf4j is not stable as explained by Mark and me earlier. So which alternative do you propose? We can open a thread on it on dev@ to not pollute this PR BTW. 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] (DOXIA-616) Markdown: Properly expose the language specified in fenced code blocks
[
https://issues.apache.org/jira/browse/DOXIA-616?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17246033#comment-17246033
]
Bertrand Martin commented on DOXIA-616:
---
That's how one of the [most utilized
highlighter|https://highlightjs.org/usage/] works.
[Prim.js|https://prismjs.com/] on the other hand insists on having a {{}} element.
Anyway, most highlighters prefer the below syntax:
{code:html}
p { color: red }
{code}
The class indicating the language can however be set on an ancestor, so the
below will work as well, for example:
{code:html}
p { color: red }
{code}
I'm concerned that FlexMark doesn't produce the {{}} element, though...
> Markdown: Properly expose the language specified in fenced code blocks
> --
>
> Key: DOXIA-616
> URL: https://issues.apache.org/jira/browse/DOXIA-616
> Project: Maven Doxia
> Issue Type: Improvement
> Components: Module - Markdown
>Affects Versions: 1.8, 1.9, 1.9.1
>Reporter: Bertrand Martin
>Priority: Major
>
> h1. Use Case
> Writers can specify the language used in a fenced code block (typically for
> syntax highlighting), as in the example below:
> {code}
> ```java
> System.out.println("Beautiful\n");
> ```
> {code}
> Currently, the Doxia module for Markdown does not expose this information
> ("java") in the produced HTML, so a Maven skin (or frontend renderer) cannot
> leverage it.
> Produced HTML:
> {code:html}
>
>
> System.out.println("Beautiful\n");
>
>
> {code}
> Wanted result:
> {code:html}
>
>
> System.out.println("Beautiful\n");
>
>
> {code}
> h1. Specification
> Un-comment this block:
> https://github.com/apache/maven-doxia/blob/c439714e8f4a9e86f9962ac6be9a0077ae9b4d30/doxia-modules/doxia-module-markdown/src/main/java/org/apache/maven/doxia/module/markdown/FlexmarkDoxiaNodeRenderer.java#L103
> This should do the trick.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-7049) Version range resolution downloads all poms, not just the highest version
[ https://issues.apache.org/jira/browse/MNG-7049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17246073#comment-17246073 ] Michael Osipov commented on MNG-7049: - I am so certain that I have seen a similiar request for this, but I can't remember whether it was with Maven Core or Maven Resolver. Will keep looking. > Version range resolution downloads all poms, not just the highest version > - > > Key: MNG-7049 > URL: https://issues.apache.org/jira/browse/MNG-7049 > Project: Maven > Issue Type: Bug > Components: core >Reporter: Moti Nisenson-Ken >Priority: Major > > When specifying a version range for a dependency, maven will download and try > to resolve all poms in that range which satisfy the range. The usage however > is only to use the highestVersion. This causes two issues: > # Performance - it's downloading numerous poms that aren't needed. > # Fragility - if the version range covers any "bad" poms, then the build > will fail. For example, consider that for a specific version, the parent of a > pom is not present in the repository. This is enough to fail any build with a > version range covering that specific version, as the range resolution stage > will not complete. This is particularly harmful when that version would not > be selected as the highest, anyway. > Recommend to have a system property to control the desired behavior - it > should be possible to short-circuit loading all the versions and to just to > load the highest version. > For another user report of this see: > [https://stackoverflow.com/questions/25047859/restrict-maven-to-not-download-all-poms] > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MRESOLVER-144) Maven Resolver deploys version metadata multiple times
[ https://issues.apache.org/jira/browse/MRESOLVER-144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17246072#comment-17246072 ] Michael Osipov commented on MRESOLVER-144: -- [~cstamas], did you get a chance to test MNG-6754? > Maven Resolver deploys version metadata multiple times > -- > > Key: MRESOLVER-144 > URL: https://issues.apache.org/jira/browse/MRESOLVER-144 > Project: Maven Resolver > Issue Type: Bug > Components: Resolver >Affects Versions: 1.6.1 >Reporter: Tamás Cservenák >Priority: Blocker > Time Spent: 10m > Remaining Estimate: 0h > > This causes problems like MDEPLOY-221 is. > Problem: > Maven deploys version metadata multiple times. Seems it is triggered by any > plugin that attaches artifact to MavenProject? > This happens with all 2.x m-deploy-p. 3.0.0-M1 fails. > Expected: > Maven deploy version (and any other) metadata only once with proper > timestmaps (those that have the deployed artifacts) whatever count of > attached artifacts are there. > Reproducer: > [https://github.com/cstamas/mvn-md-bug] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (SCM-947) Improve ChangeLog Mojo to use ChangeLog Request
[ https://issues.apache.org/jira/browse/SCM-947?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17246075#comment-17246075 ] Michael Osipov commented on SCM-947: Will pick up the PR as soon as I can. > Improve ChangeLog Mojo to use ChangeLog Request > --- > > Key: SCM-947 > URL: https://issues.apache.org/jira/browse/SCM-947 > Project: Maven SCM > Issue Type: Improvement > Components: documentation, maven-plugin >Affects Versions: 1.11.2 >Reporter: Clemens Quoß >Assignee: Michael Osipov >Priority: Minor > Fix For: 1.11.3 > > > Improve the changelog mojo to accept all parameters from the changelog > request. > No internal sanity checks, just 1:1 routing of params. > Call provider with request rather than distinct params (these calls are > already deprecated). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MRESOLVER-145) Introduce more SyncContext implementations
[ https://issues.apache.org/jira/browse/MRESOLVER-145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17246079#comment-17246079 ] Michael Osipov commented on MRESOLVER-145: -- This is not forgotten, but scheduled for mid Dec. > Introduce more SyncContext implementations > -- > > Key: MRESOLVER-145 > URL: https://issues.apache.org/jira/browse/MRESOLVER-145 > Project: Maven Resolver > Issue Type: New Feature > Components: Resolver >Reporter: Tamás Cservenák >Assignee: Michael Osipov >Priority: Minor > > Aside of existing "global" (too coarse, not really usable) and "redisson" > sync context implementations, we may try out more implementations and maybe > even benchmark/compare them. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [maven] michael-o commented on pull request #399: [MNG-7034] StackOverflowError thrown if a cycle exists in BOM imports
michael-o commented on pull request #399: URL: https://github.com/apache/maven/pull/399#issuecomment-740864726 @gnodet I would like to review. Can you ping me on Friday by noon? 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 edited a comment on pull request #399: [MNG-7034] StackOverflowError thrown if a cycle exists in BOM imports
michael-o edited a comment on pull request #399: URL: https://github.com/apache/maven/pull/399#issuecomment-740864726 @gnodet I would like to review too. Can you ping me on Friday by noon? 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] [Comment Edited] (MWAR-439) WAR Plugin 3.3.1 hits NPE when exploding if maven session start time is null
[
https://issues.apache.org/jira/browse/MWAR-439?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17225587#comment-17225587
]
Michael Osipov edited comment on MWAR-439 at 12/8/20, 7:05 PM:
---
This is extremely weird. It should never be null.
was (Author: michael-o):
This is extremely weird. IT should never be null.
> WAR Plugin 3.3.1 hits NPE when exploding if maven session start time is null
>
>
> Key: MWAR-439
> URL: https://issues.apache.org/jira/browse/MWAR-439
> Project: Maven WAR Plugin
> Issue Type: Bug
>Affects Versions: 3.3.1
> Environment: Windows 10
> Eclipse Version: 20200910-1200
> m2e Version: 1.16.1.20200710-1008
>Reporter: Ben DeLillo
>Priority: Major
>
> I don't have a distributable repro case, but I can say that in my
> multi-module project, when the exploded goal is invoked by eclipse and m2e
> the following error occurs:
> {code:java}
> Execution default of goal
> org.apache.maven.plugins:maven-war-plugin:3.3.1:exploded failed.
> (org.apache.maven.plugins:maven-war-plugin:3.3.1:exploded:default:process-resources)
> {code}
> The stack trace for this error is
> {code:java}
> org.apache.maven.plugin.PluginExecutionException: Execution default of goal
> org.apache.maven.plugins:maven-war-plugin:3.3.1:exploded failed. at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:148)
> at
> org.eclipse.m2e.core.internal.embedder.MavenImpl.execute(MavenImpl.java:332)
> at
> org.eclipse.m2e.core.internal.embedder.MavenImpl.lambda$8(MavenImpl.java:1380)
> at
> org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.executeBare(MavenExecutionContext.java:179)
> at
> org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.execute(MavenExecutionContext.java:114)
> at
> org.eclipse.m2e.core.internal.embedder.MavenImpl.execute(MavenImpl.java:1379)
> at
> org.eclipse.m2e.core.project.configurator.MojoExecutionBuildParticipant.build(MojoExecutionBuildParticipant.java:54)
> at
> org.eclipse.m2e.core.internal.builder.MavenBuilderImpl.build(MavenBuilderImpl.java:135)
> at
> org.eclipse.m2e.core.internal.builder.MavenBuilder$1.method(MavenBuilder.java:169)
> at
> org.eclipse.m2e.core.internal.builder.MavenBuilder$1.method(MavenBuilder.java:1)
> at
> org.eclipse.m2e.core.internal.builder.MavenBuilder$BuildMethod.lambda$1(MavenBuilder.java:114)
> at
> org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.executeBare(MavenExecutionContext.java:179)
> at
> org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.execute(MavenExecutionContext.java:114)
> at
> org.eclipse.m2e.core.internal.builder.MavenBuilder$BuildMethod.lambda$0(MavenBuilder.java:105)
> at
> org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.executeBare(MavenExecutionContext.java:179)
> at
> org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.execute(MavenExecutionContext.java:153)
> at
> org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.execute(MavenExecutionContext.java:101)
> at
> org.eclipse.m2e.core.internal.builder.MavenBuilder$BuildMethod.execute(MavenBuilder.java:88)
> at
> org.eclipse.m2e.core.internal.builder.MavenBuilder.build(MavenBuilder.java:197)
> at
> org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:832) at
> org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:45) at
> org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:220)
> at
> org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:263)
> at
> org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:316) at
> org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:45) at
> org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:319)
> at
> org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:371)
> at
> org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:392) at
> org.eclipse.core.internal.resources.Workspace.buildInternal(Workspace.java:515)
> at org.eclipse.core.internal.resources.Workspace.build(Workspace.java:405)
> at org.eclipse.ui.actions.GlobalBuildAction$1.run(GlobalBuildAction.java:180)
> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:63) Caused by:
> java.lang.NullPointerException at
> org.apache.maven.plugins.war.AbstractWarMojo$DefaultWarPackagingContext$1.visitFile(AbstractWarMojo.java:661)
> at
> org.apache.maven.plugins.war.AbstractWarMojo$DefaultWarPackagingContext$1.visitFile(AbstractWarMojo.java:656)
> at java.base/java.nio.file.Files.walkFileTree(Files.java:2804) at
> java.base/java.nio.file.Files.walkFileTree(Files.java:2876) at
> org.apache.maven.plugins.war.AbstractWarMojo$
[jira] [Commented] (MWAR-439) WAR Plugin 3.3.1 hits NPE when exploding if maven session start time is null
[
https://issues.apache.org/jira/browse/MWAR-439?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17246082#comment-17246082
]
Michael Osipov commented on MWAR-439:
-
Can you bisect between these two versions?
> WAR Plugin 3.3.1 hits NPE when exploding if maven session start time is null
>
>
> Key: MWAR-439
> URL: https://issues.apache.org/jira/browse/MWAR-439
> Project: Maven WAR Plugin
> Issue Type: Bug
>Affects Versions: 3.3.1
> Environment: Windows 10
> Eclipse Version: 20200910-1200
> m2e Version: 1.16.1.20200710-1008
>Reporter: Ben DeLillo
>Priority: Major
>
> I don't have a distributable repro case, but I can say that in my
> multi-module project, when the exploded goal is invoked by eclipse and m2e
> the following error occurs:
> {code:java}
> Execution default of goal
> org.apache.maven.plugins:maven-war-plugin:3.3.1:exploded failed.
> (org.apache.maven.plugins:maven-war-plugin:3.3.1:exploded:default:process-resources)
> {code}
> The stack trace for this error is
> {code:java}
> org.apache.maven.plugin.PluginExecutionException: Execution default of goal
> org.apache.maven.plugins:maven-war-plugin:3.3.1:exploded failed. at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:148)
> at
> org.eclipse.m2e.core.internal.embedder.MavenImpl.execute(MavenImpl.java:332)
> at
> org.eclipse.m2e.core.internal.embedder.MavenImpl.lambda$8(MavenImpl.java:1380)
> at
> org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.executeBare(MavenExecutionContext.java:179)
> at
> org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.execute(MavenExecutionContext.java:114)
> at
> org.eclipse.m2e.core.internal.embedder.MavenImpl.execute(MavenImpl.java:1379)
> at
> org.eclipse.m2e.core.project.configurator.MojoExecutionBuildParticipant.build(MojoExecutionBuildParticipant.java:54)
> at
> org.eclipse.m2e.core.internal.builder.MavenBuilderImpl.build(MavenBuilderImpl.java:135)
> at
> org.eclipse.m2e.core.internal.builder.MavenBuilder$1.method(MavenBuilder.java:169)
> at
> org.eclipse.m2e.core.internal.builder.MavenBuilder$1.method(MavenBuilder.java:1)
> at
> org.eclipse.m2e.core.internal.builder.MavenBuilder$BuildMethod.lambda$1(MavenBuilder.java:114)
> at
> org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.executeBare(MavenExecutionContext.java:179)
> at
> org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.execute(MavenExecutionContext.java:114)
> at
> org.eclipse.m2e.core.internal.builder.MavenBuilder$BuildMethod.lambda$0(MavenBuilder.java:105)
> at
> org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.executeBare(MavenExecutionContext.java:179)
> at
> org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.execute(MavenExecutionContext.java:153)
> at
> org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.execute(MavenExecutionContext.java:101)
> at
> org.eclipse.m2e.core.internal.builder.MavenBuilder$BuildMethod.execute(MavenBuilder.java:88)
> at
> org.eclipse.m2e.core.internal.builder.MavenBuilder.build(MavenBuilder.java:197)
> at
> org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:832) at
> org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:45) at
> org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:220)
> at
> org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:263)
> at
> org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:316) at
> org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:45) at
> org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:319)
> at
> org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:371)
> at
> org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:392) at
> org.eclipse.core.internal.resources.Workspace.buildInternal(Workspace.java:515)
> at org.eclipse.core.internal.resources.Workspace.build(Workspace.java:405)
> at org.eclipse.ui.actions.GlobalBuildAction$1.run(GlobalBuildAction.java:180)
> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:63) Caused by:
> java.lang.NullPointerException at
> org.apache.maven.plugins.war.AbstractWarMojo$DefaultWarPackagingContext$1.visitFile(AbstractWarMojo.java:661)
> at
> org.apache.maven.plugins.war.AbstractWarMojo$DefaultWarPackagingContext$1.visitFile(AbstractWarMojo.java:656)
> at java.base/java.nio.file.Files.walkFileTree(Files.java:2804) at
> java.base/java.nio.file.Files.walkFileTree(Files.java:2876) at
> org.apache.maven.plugins.war.AbstractWarMojo$DefaultWarPackagingContext.(AbstractWarMojo.java:655)
> at
> org.apache.maven.plugins.war.AbstractWarMojo.buildWebapp(AbstractWarMojo
[jira] [Comment Edited] (MRESOLVER-90) HTML content in POM: Maven should validate content before storing in local repo
[
https://issues.apache.org/jira/browse/MRESOLVER-90?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16867292#comment-16867292
]
Michael Osipov edited comment on MRESOLVER-90 at 12/8/20, 7:15 PM:
---
Wagon uses an HTTP interface, not an HTML one. There is no way to detect that
reliably. Those who impose a form-based on an HTTP interface should change the
working field. It is simply wrong.
was (Author: michael-o):
Wagon uses an HTTP interface, not an HTML one. There is no way to detect that
reliably. Those who impose a fofm-based on an HTTP interface should change the
working field. It is simply wrong.
> HTML content in POM: Maven should validate content before storing in local
> repo
> ---
>
> Key: MRESOLVER-90
> URL: https://issues.apache.org/jira/browse/MRESOLVER-90
> Project: Maven Resolver
> Issue Type: New Feature
>Affects Versions: 1.4.0
> Environment: both with maven 3.6.0 in CMD or in Eclipse 4.9.0
>Reporter: Jörg Hohwiller
>Priority: Major
> Labels: intern
>
> For some odd reasons somethimes errors just happen and a maven repo delivers
> an HTML error or login page for a request of a POM or JAR file. It seems as
> if the status code is valid then Maven (might be anything under the hood,
> maybe even ether?) is saving the result without any sanity check or
> validation.
> Therefore I frequently end up with "POM" or "JAR" files in my local repo that
> are no XML but HTML nonsens.
>
> Example:
> {code:java}
>
>
>
>
> Please Wait While Redirecting to Login page
>
>
>
>
>
>
> {code}
> I would expect maven to verify the content before officially placing it in
> the correct location inside the local maven repository on my disc.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6979) MavenSession.getCurrentProject may return an incorrect project in a multimodule build
[
https://issues.apache.org/jira/browse/MNG-6979?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17246098#comment-17246098
]
Michael Osipov commented on MNG-6979:
-
I wll have a look at this again...this year.
> MavenSession.getCurrentProject may return an incorrect project in a
> multimodule build
> -
>
> Key: MNG-6979
> URL: https://issues.apache.org/jira/browse/MNG-6979
> Project: Maven
> Issue Type: Bug
> Components: core
>Affects Versions: 3.6.3
>Reporter: George Gastaldi
>Assignee: Michael Osipov
>Priority: Major
> Attachments: project.zip
>
>
> Having an extension that just displays the current project, like in:
> {code:java}
> @Singleton
> @Named
> public class BuildModuleSelector extends AbstractMavenLifecycleParticipant {
> @Inject
> private Logger logger;
> @Override
> public void afterProjectsRead(MavenSession session) throws
> MavenExecutionException {
> logger.info(session.getCurrentProject().toString());
>
> session.setProjects(Collections.singletonList(session.getCurrentProject()));
> }
> }
> {code}
> Will fail to resolve the current project when executed in the root of a
> project that depends on a module with the same parent.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (MNG-6979) MavenSession.getCurrentProject may return an incorrect project in a multimodule build
[
https://issues.apache.org/jira/browse/MNG-6979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov reassigned MNG-6979:
---
Assignee: Michael Osipov
> MavenSession.getCurrentProject may return an incorrect project in a
> multimodule build
> -
>
> Key: MNG-6979
> URL: https://issues.apache.org/jira/browse/MNG-6979
> Project: Maven
> Issue Type: Bug
> Components: core
>Affects Versions: 3.6.3
>Reporter: George Gastaldi
>Assignee: Michael Osipov
>Priority: Major
> Attachments: project.zip
>
>
> Having an extension that just displays the current project, like in:
> {code:java}
> @Singleton
> @Named
> public class BuildModuleSelector extends AbstractMavenLifecycleParticipant {
> @Inject
> private Logger logger;
> @Override
> public void afterProjectsRead(MavenSession session) throws
> MavenExecutionException {
> logger.info(session.getCurrentProject().toString());
>
> session.setProjects(Collections.singletonList(session.getCurrentProject()));
> }
> }
> {code}
> Will fail to resolve the current project when executed in the root of a
> project that depends on a module with the same parent.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MRESOLVER-90) HTML content in POM: Maven should validate content before storing in local repo
[
https://issues.apache.org/jira/browse/MRESOLVER-90?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17246097#comment-17246097
]
Michael Osipov commented on MRESOLVER-90:
-
[~hohwille], Maven 4.0.0-alpha-1 will fail on wrong checksums by default. I
will check Resolver to do this one too if run w/o Maven. Can you verify this
from Maven master for you?
> HTML content in POM: Maven should validate content before storing in local
> repo
> ---
>
> Key: MRESOLVER-90
> URL: https://issues.apache.org/jira/browse/MRESOLVER-90
> Project: Maven Resolver
> Issue Type: New Feature
>Affects Versions: 1.4.0
> Environment: both with maven 3.6.0 in CMD or in Eclipse 4.9.0
>Reporter: Jörg Hohwiller
>Priority: Major
> Labels: intern
>
> For some odd reasons somethimes errors just happen and a maven repo delivers
> an HTML error or login page for a request of a POM or JAR file. It seems as
> if the status code is valid then Maven (might be anything under the hood,
> maybe even ether?) is saving the result without any sanity check or
> validation.
> Therefore I frequently end up with "POM" or "JAR" files in my local repo that
> are no XML but HTML nonsens.
>
> Example:
> {code:java}
>
>
>
>
> Please Wait While Redirecting to Login page
>
>
>
>
>
>
> {code}
> I would expect maven to verify the content before officially placing it in
> the correct location inside the local maven repository on my disc.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (MRESOLVER-151) Switch the default checksum policy from "warn" to "fail"
Michael Osipov created MRESOLVER-151: Summary: Switch the default checksum policy from "warn" to "fail" Key: MRESOLVER-151 URL: https://issues.apache.org/jira/browse/MRESOLVER-151 Project: Maven Resolver Issue Type: Task Components: Resolver Affects Versions: 1.6.1 Reporter: Michael Osipov Assignee: Michael Osipov Fix For: 1.7.0 This mirrors MNG-5728. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MRESOLVER-151) Switch the default checksum policy from "warn" to "fail"
[
https://issues.apache.org/jira/browse/MRESOLVER-151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MRESOLVER-151:
-
Description: This mirrors MNG-5728. The change has to happen in
{{DefaultChecksumPolicyProvider}}. (was: This mirrors MNG-5728. The change has
to happen in {{DefaultChecksumPolicyProvider}},)
> Switch the default checksum policy from "warn" to "fail"
>
>
> Key: MRESOLVER-151
> URL: https://issues.apache.org/jira/browse/MRESOLVER-151
> Project: Maven Resolver
> Issue Type: Task
> Components: Resolver
>Affects Versions: 1.6.1
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 1.7.0
>
>
> This mirrors MNG-5728. The change has to happen in
> {{DefaultChecksumPolicyProvider}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (MRESOLVER-151) Switch the default checksum policy from "warn" to "fail"
[
https://issues.apache.org/jira/browse/MRESOLVER-151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MRESOLVER-151:
-
Description: This mirrors MNG-5728. The change has to happen in
{{DefaultChecksumPolicyProvider}}, (was: This mirrors MNG-5728.)
> Switch the default checksum policy from "warn" to "fail"
>
>
> Key: MRESOLVER-151
> URL: https://issues.apache.org/jira/browse/MRESOLVER-151
> Project: Maven Resolver
> Issue Type: Task
> Components: Resolver
>Affects Versions: 1.6.1
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 1.7.0
>
>
> This mirrors MNG-5728. The change has to happen in
> {{DefaultChecksumPolicyProvider}},
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (MRESOLVER-90) HTML content in POM: Maven should validate content before storing in local repo
[
https://issues.apache.org/jira/browse/MRESOLVER-90?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MRESOLVER-90:
Fix Version/s: version-next
waiting-for-feedback
> HTML content in POM: Maven should validate content before storing in local
> repo
> ---
>
> Key: MRESOLVER-90
> URL: https://issues.apache.org/jira/browse/MRESOLVER-90
> Project: Maven Resolver
> Issue Type: New Feature
>Affects Versions: 1.4.0
> Environment: both with maven 3.6.0 in CMD or in Eclipse 4.9.0
>Reporter: Jörg Hohwiller
>Priority: Major
> Labels: intern
> Fix For: waiting-for-feedback, version-next
>
>
> For some odd reasons somethimes errors just happen and a maven repo delivers
> an HTML error or login page for a request of a POM or JAR file. It seems as
> if the status code is valid then Maven (might be anything under the hood,
> maybe even ether?) is saving the result without any sanity check or
> validation.
> Therefore I frequently end up with "POM" or "JAR" files in my local repo that
> are no XML but HTML nonsens.
>
> Example:
> {code:java}
>
>
>
>
> Please Wait While Redirecting to Login page
>
>
>
>
>
>
> {code}
> I would expect maven to verify the content before officially placing it in
> the correct location inside the local maven repository on my disc.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (MDEPLOY-260) Create correct SHA File content
[ https://issues.apache.org/jira/browse/MDEPLOY-260?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MDEPLOY-260: --- Fix Version/s: wontfix-candidate > Create correct SHA File content > --- > > Key: MDEPLOY-260 > URL: https://issues.apache.org/jira/browse/MDEPLOY-260 > Project: Maven Deploy Plugin > Issue Type: Improvement >Affects Versions: 3.0.0-M1 >Reporter: Karl Heinz Marbaise >Priority: Minor > Fix For: 3.0.0, wontfix-candidate > > > Currently the created SHA1 which is used at the moment contains only the > checksum but to check via command and shasum tool it needs to be enhanced to > contain the filename as well -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MDEPLOY-260) Create correct SHA File content
[ https://issues.apache.org/jira/browse/MDEPLOY-260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17246110#comment-17246110 ] Michael Osipov commented on MDEPLOY-260: Two reasons why this should be closed: 1. This plugin does not create any checksums at all. Resolver does. 2. There is no canonical checksum file format. > Create correct SHA File content > --- > > Key: MDEPLOY-260 > URL: https://issues.apache.org/jira/browse/MDEPLOY-260 > Project: Maven Deploy Plugin > Issue Type: Improvement >Affects Versions: 3.0.0-M1 >Reporter: Karl Heinz Marbaise >Priority: Minor > Fix For: 3.0.0, wontfix-candidate > > > Currently the created SHA1 which is used at the moment contains only the > checksum but to check via command and shasum tool it needs to be enhanced to > contain the filename as well -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6870) A maven project can't fetch its parent when its repository is configured with an interpolated variable
[ https://issues.apache.org/jira/browse/MNG-6870?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17246119#comment-17246119 ] Michael Osipov commented on MNG-6870: - [~rfscholte], here is your dup: MNG-6457. > A maven project can't fetch its parent when its repository is configured with > an interpolated variable > -- > > Key: MNG-6870 > URL: https://issues.apache.org/jira/browse/MNG-6870 > Project: Maven > Issue Type: Bug > Components: Artifacts and Repositories, Inheritance and Interpolation >Affects Versions: 3.6.3 >Reporter: Arnaud Rivero >Priority: Major > > Maven seems to be unable to fetch its parent pom.xml on a remote repository > when it uses an interpolated variable in its repositories configuration. > However, if no parent is declared in the same project pom.xml and the parent > is declared as a dependency instead, then it is downloaded. > If we have both the parent configured and declared as a dependency, the same > problem occurs : Maven can't download the parent from the remote repository > Lastly, if we replace the variable by its value, there are no problem > downloading the parent pom.xml > The problem occurs whether the variable is a property defined in the pom.xml > or is an environment variable > > It seems maven can only interpolate a variable value in a pom.xml after the > parent has been resolved > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MNG-6457) Resolving repository with an environment variable substitution fails when a parent pom needs to be looked up
[
https://issues.apache.org/jira/browse/MNG-6457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MNG-6457:
Fix Version/s: wontfix-candidate
> Resolving repository with an environment variable substitution fails when a
> parent pom needs to be looked up
>
>
> Key: MNG-6457
> URL: https://issues.apache.org/jira/browse/MNG-6457
> Project: Maven
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 3.3.3, 3.5.2
> Environment: ubuntu 18.04, also with windows 10
>Reporter: Martin Knoller Stocker
>Priority: Major
> Fix For: wontfix-candidate
>
>
> Having a repository entry with a environment variable substitution like
>
> {code:java}
>
>
> company-java-libs
> https://packagecloud.io/priv/${env.PACKAGECLOUD_JAVA_LIBS_READ_TOKEN}/company/java-libs/maven2
>
> true
>
>
> true
>
>
>
> {code}
> and a parent entry that is not present in your local repository
> {code:java}
>
> company
> a-parent-module
> 1.0.0
>
>
> {code}
> produces a parsing error when running maven commands:
> {code:java}
> [ERROR] [ERROR] Some problems were encountered while processing the POMs:
> [ERROR] Non-resolvable parent POM for __current_project_version__: Could
> not transfer artifact company:a-parent-module:pom:1.0.0 in company-java-libs
> from/to company-java-libs
> (https://packagecloud.io/priv/${env.PACKAGECLOUD_JAVA_LIBS_READ_TOKEN}/company/java-libs/maven2):
> Illegal character in path at index 30:
> https://packagecloud.io/priv/${env.PACKAGECLOUD_JAVA_LIBS_READ_TOKEN}/company/java-libs/maven2/__path__
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-7046) Revert MNG-5639 and make repo config static only
[ https://issues.apache.org/jira/browse/MNG-7046?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17246120#comment-17246120 ] Michael Osipov commented on MNG-7046: - [~rfscholte], MNG-6457 is the exact reason why this needs to be reverted. > Revert MNG-5639 and make repo config static only > > > Key: MNG-7046 > URL: https://issues.apache.org/jira/browse/MNG-7046 > Project: Maven > Issue Type: Task > Components: Artifacts and Repositories, Dependencies >Affects Versions: 3.6.3 >Reporter: Michael Osipov >Assignee: Michael Osipov >Priority: Major > Fix For: 4.0.0, 4.0.0-alpha-1 > > > As discussed in MNG-5639 repositories should always be known upfront, they > have to be static to avoid chicken and egg situations, a project should not > influence settings. It should be the way around. > In subsequent ticket it will be verified that repo configuration does not > contain any expression: > https://github.com/apache/maven/commit/d411c3fa98832e7d86d901fe86ff63ba907cf868#commitcomment-44782281. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6457) Resolving repository with an environment variable substitution fails when a parent pom needs to be looked up
[
https://issues.apache.org/jira/browse/MNG-6457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17246121#comment-17246121
]
Michael Osipov commented on MNG-6457:
-
Please see MNG-7046.
> Resolving repository with an environment variable substitution fails when a
> parent pom needs to be looked up
>
>
> Key: MNG-6457
> URL: https://issues.apache.org/jira/browse/MNG-6457
> Project: Maven
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 3.3.3, 3.5.2
> Environment: ubuntu 18.04, also with windows 10
>Reporter: Martin Knoller Stocker
>Priority: Major
> Fix For: wontfix-candidate
>
>
> Having a repository entry with a environment variable substitution like
>
> {code:java}
>
>
> company-java-libs
> https://packagecloud.io/priv/${env.PACKAGECLOUD_JAVA_LIBS_READ_TOKEN}/company/java-libs/maven2
>
> true
>
>
> true
>
>
>
> {code}
> and a parent entry that is not present in your local repository
> {code:java}
>
> company
> a-parent-module
> 1.0.0
>
>
> {code}
> produces a parsing error when running maven commands:
> {code:java}
> [ERROR] [ERROR] Some problems were encountered while processing the POMs:
> [ERROR] Non-resolvable parent POM for __current_project_version__: Could
> not transfer artifact company:a-parent-module:pom:1.0.0 in company-java-libs
> from/to company-java-libs
> (https://packagecloud.io/priv/${env.PACKAGECLOUD_JAVA_LIBS_READ_TOKEN}/company/java-libs/maven2):
> Illegal character in path at index 30:
> https://packagecloud.io/priv/${env.PACKAGECLOUD_JAVA_LIBS_READ_TOKEN}/company/java-libs/maven2/__path__
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-7044) Allow use of attributes in Maven pom.xml
[ https://issues.apache.org/jira/browse/MNG-7044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17246131#comment-17246131 ] Will Iverson commented on MNG-7044: --- Looks like the change would be to this file: https://github.com/codehaus-plexus/modello/blob/08152b14bb44867c038e52fc957c46ec1906668e/modello-plugins/modello-plugin-xpp3/src/main/java/org/codehaus/modello/plugin/xpp3/Xpp3ReaderGenerator.java It's a ~1600 line code generator. Looks like it doesn't actually have any tests for validating that a given pom.xml can be parsed/validated, just that the files generated by a *.mdo file can successfully compile. The maven-model project at https://github.com/apache/maven/blob/master/maven-model/pom.xml has a dependency on modello-maven-plugin, which in turn uses the above. Trying to time box to ~1hr at time. :) Next step is to try to generate a working test environment linking the above with SNAPSHOTs. My sense that this will all boil down to just a few lines to tweak the Xpp3ReaderGenerator.java is still there. The error message for an invalid pom.xml such as: Malformed POM /Users/wiverson/src/tiny-pom/pom.xml: Unknown attribute 'scope' for tag 'dependency' (position: START_TAG seen ...y groupId="junit" artifactId="junit" version="4.11" scope="test"/>... @22:81) @ /Users/wiverson/src/tiny-pom/pom.xml, line 22, column 81 ...is clearly coming from the Modello generated code, not the XSD. A simple version of the tweak to the code generator would just check to see if the attribute is a known field and allow it to be set if known, while throwing an error (like today) if not. A fancier version would emit an warning for a duplicate attribute/element declaration (just like a duplicate element declaration today. > Allow use of attributes in Maven pom.xml > > > Key: MNG-7044 > URL: https://issues.apache.org/jira/browse/MNG-7044 > Project: Maven > Issue Type: New Feature > Components: core, POM >Reporter: Will Iverson >Priority: Minor > Labels: features > > Proposal: The current pom.xml file is very verbose due to the exclusive use > of XML elements. This makes even simple declarations such as dependencies > unnecessarily verbose. > I would propose that a future version of Maven allow for the use of > attributes as an alternative declaration for pom.xml configuration. This > would only affect how Maven ingests project files - for consistency and > backward compatibility all generated pom.xml files would continue to be > element based. > Projects that declared a conflicting/duplicate attribute/element pairing > would be considered to be malformed, and would result in a built break. > By way of example of the benefit of this proposal, this declaration would be > reduced from: > > commons-cli > commons-cli > 1.4 > > ...to... > > This would allow many Maven projects to *dramatically* decrease the total > line count, which is one of the frequent criticisms of Maven compared with > other build tools. > If there is interest, I would be happy to help support this. My > hope/expectation is that the changes required to support this in Maven itself > would be quite minor - simply adding a bit of additional logic to look for > attributes in the XML parse and error reporting in the event of a duplication > (as well as supporting test cases). That said, I don't want to send in > patches for a change like this that would be dead on arrival. > This would, of course, represent a potentially large impact on the user and > tooling space (in particular, IDEs that integrate Maven support). As the > emitted files for resolved pom.xml files (those that are published in repos) > would remain the same, hopefully the overall impacts would be manageable. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (MPMD-311) Improve excludesFile docs
Matt Voboril created MPMD-311:
-
Summary: Improve excludesFile docs
Key: MPMD-311
URL: https://issues.apache.org/jira/browse/MPMD-311
Project: Maven PMD Plugin
Issue Type: Improvement
Components: CPD
Affects Versions: 3.14.0
Reporter: Matt Voboril
There is a bit of ambiguity when dealing with the \{exclude-cpd.properties}
file format.
It seems that there is a different format for handing duplication within the
same class and duplication across classes.
The documented format only handles those that are across files, whereas to
allow within only the same file, classes should be entered on separate lines.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [maven-pmd-plugin] TobiTenno opened a new pull request #39: [MPMD-311] - Improve excludeFileFromFailure docs
TobiTenno opened a new pull request #39: URL: https://github.com/apache/maven-pmd-plugin/pull/39 Improve the documentation around `exclude-cpd.properties` file formatting 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] (MPMD-311) Improve excludesFile docs
[
https://issues.apache.org/jira/browse/MPMD-311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Voboril updated MPMD-311:
--
Description:
There is a bit of ambiguity when dealing with the {{exclude-cpd.properties}}
file format.
It seems that there is a different format for handing duplication within the
same class and duplication across classes.
The documented format only handles those that are across files, whereas to
allow within only the same file, classes should be entered on separate lines.
was:
There is a bit of ambiguity when dealing with the \{exclude-cpd.properties}
file format.
It seems that there is a different format for handing duplication within the
same class and duplication across classes.
The documented format only handles those that are across files, whereas to
allow within only the same file, classes should be entered on separate lines.
> Improve excludesFile docs
> -
>
> Key: MPMD-311
> URL: https://issues.apache.org/jira/browse/MPMD-311
> Project: Maven PMD Plugin
> Issue Type: Improvement
> Components: CPD
>Affects Versions: 3.14.0
>Reporter: Matt Voboril
>Priority: Major
> Original Estimate: 10m
> Remaining Estimate: 10m
>
> There is a bit of ambiguity when dealing with the {{exclude-cpd.properties}}
> file format.
>
> It seems that there is a different format for handing duplication within the
> same class and duplication across classes.
>
> The documented format only handles those that are across files, whereas to
> allow within only the same file, classes should be entered on separate lines.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (MNG-7050) Create M2_REPOSITORY env variable for Local Repository and Wrapper locations
Manuel Jordan created MNG-7050:
--
Summary: Create M2_REPOSITORY env variable for Local Repository
and Wrapper locations
Key: MNG-7050
URL: https://issues.apache.org/jira/browse/MNG-7050
Project: Maven
Issue Type: Improvement
Components: core, maven wrapper, Settings
Affects Versions: 3.6.3
Reporter: Manuel Jordan
I need do mention about Gradle to understand and find the same solution or
approach for Maven.
In Gradle exists the {{GRADLE_HOME}} and {{GRADLE_USER_HOME}} (repository)
_environment variables_, for Maven the former through {{M2_HOME}} and about the
_repository_ I use the {{settings.xml}} file to define the
{{}} location
For both Maven and Gradle I can define in peace the place about where is
installed the software, for example other location than {{.m2}} and {{.gradle}}
to a secondary disk and even with customized directory names. Same goal about
the repository location, both for a secondary disk (remember for Maven through
the {{settings.xml}} file)
*Note*: therefore {{.gradle}} and {{.m2}} are empty and not used.
In Gradle about the wrapper created, the {{gradle-wrapper.properties}} file has:
{code:java}
distributionBase=GRADLE_USER_HOME
distributionPath=wrapper/dists
distributionUrl=https\://services.gradle.org/distributions/gradle-#.#.#-bin.zip
zipStoreBase=GRADLE_USER_HOME
zipStorePath=wrapper/dists
{code}
Then the final path is: {{GRADLE_USER_HOME/wrapper/dists}}
Therefore observe how {{GRADLE_USER_HOME}} (custom location - otherwise
{{.gradle}} by default) is used to define the:
* Local repository
* Base path to install the downloaded Gradle through the wrapper
*New Improvement*: Add for Maven an environment variable named M2_REPOSITORY
for the _Local Repository_ and _Wrapper Installation_ locations that Maven
should recognize automatically (*not* using the {{settings.xml}} file).
It with the purpose to have any Maven wrapper(s) installed according to that
_environment variable_ value (custom location - otherwise {{.m2}} by default)
and of course applied for the Local Repository location too.
*Observation*: If the {{settings.xml}} file exists it should override the
M2_REPOSITORY value.
*Therefore*: I need the {{maven-wrapper.properties}} using something like
{{M2_REPOSITORY}} (custom location - otherwise {{.m2}} by default) according
the developer/user in its machine.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [maven-jlink-plugin] struberg commented on pull request #23: [MJLINK-57] Migrate to slf4j
struberg commented on pull request #23: URL: https://github.com/apache/maven-jlink-plugin/pull/23#issuecomment-741587582 > The current Maven project-wide decision is to use SLF4J. It historically was actually more a one person decision which went out of control. Happened in around 2011 or so. We had tons of troubles due to that already. So we should start a decision on the list to discuss this more broadly. As an old ASF saying goes: if it didn't happen on the list, it didn't happen. 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] struberg edited a comment on pull request #23: [MJLINK-57] Migrate to slf4j
struberg edited a comment on pull request #23: URL: https://github.com/apache/maven-jlink-plugin/pull/23#issuecomment-741587582 > The current Maven project-wide decision is to use SLF4J. It historically was actually more a one person decision which went out of control. Happened in around 2011 or so. We had tons of troubles due to that already. So we should start a decision on the list to discuss this more broadly. As an old ASF saying goes: if it didn't happen on the list, it didn't happen. PS: I don't blame anyone for not knowing those old stories. I perfectly understand that you folks do a great job and just want to keep things solid and uniform. 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] (SUREFIRE-1862) IntegrationTestMojo should not silently swallow exceptions thrown by providers
[
https://issues.apache.org/jira/browse/SUREFIRE-1862?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17246336#comment-17246336
]
Marc Philipp commented on SUREFIRE-1862:
You're right, I missed that. Feel free to close this issue.
> IntegrationTestMojo should not silently swallow exceptions thrown by providers
> --
>
> Key: SUREFIRE-1862
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1862
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Failsafe Plugin
>Reporter: Marc Philipp
>Priority: Major
>
> The {{IntegrationTestMojo}}'s {{handleSummary}} method currently does not
> handle the passed {{firstForkException}}:
> [https://github.com/apache/maven-surefire/blob/52ec2773d168d35dcc681b184f72c1053a1b9f16/maven-failsafe-plugin/src/main/java/org/apache/maven/plugin/failsafe/IntegrationTestMojo.java#L485-L508]
> That leads to provider failures being silently ignored.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
