[jira] [Commented] (MPOM-310) Replace Google Analytics with ASF Matomo in documentation
[ https://issues.apache.org/jira/browse/MPOM-310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17505388#comment-17505388 ] Herve Boutemy commented on MPOM-310: the update here is only for the documentation of ASF parent POM = https://maven.apache.org/pom/asf/ then configured in https://github.com/apache/maven-apache-parent/tree/master/src/site-docs it's not for the ASF parent POM itself (which currently has no association site.xml configuration at all) > Replace Google Analytics with ASF Matomo in documentation > - > > Key: MPOM-310 > URL: https://issues.apache.org/jira/browse/MPOM-310 > Project: Maven POMs > Issue Type: Improvement > Components: asf >Affects Versions: ASF-25 >Reporter: Herve Boutemy >Assignee: Herve Boutemy >Priority: Major > Fix For: ASF-26 > > > ASF Parent POM documentation is published to Maven site: it need to follow > Maven's tracking practice that is changing with MPOM-300 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[GitHub] [maven-dependency-plugin] kezhenxu94 opened a new pull request #207: [MDEP-799] - improve dependency:tree to add optional JSON output of the results
kezhenxu94 opened a new pull request #207: URL: https://github.com/apache/maven-dependency-plugin/pull/207 Following this checklist to help us incorporate your contribution quickly and easily: - [x] Make sure there is a [JIRA issue](https://issues.apache.org/jira/browse/MDEP) 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. - [x] Each commit in the pull request should have a meaningful subject line and body. - [x] Format the pull request title like `[MDEP-XXX] - Fixes bug in ApproximateQuantiles`, where you replace `MDEP-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. - [x] Write a pull request description that is detailed enough to understand what the pull request does, how, and why. - [x] Run `mvn clean verify` to make sure basic checks pass. A more thorough check will be performed on your pull request automatically. - [x] You have run the integration tests successfully (`mvn -Prun-its clean verify`). 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. (I'm Apache Member and I've signed ICLA) 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. - [x] 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) - [x] In any other case, please file an [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf). -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Created] (MDEP-799) improve mvn dependency:tree - add optional JSON output of the results
Zhenxu Ke created MDEP-799: -- Summary: improve mvn dependency:tree - add optional JSON output of the results Key: MDEP-799 URL: https://issues.apache.org/jira/browse/MDEP-799 Project: Maven Dependency Plugin Issue Type: Improvement Components: tree Reporter: Zhenxu Ke I'd like to add an output type JSON, will open a pull request soon -- This message was sent by Atlassian Jira (v8.20.1#820001)
[GitHub] [maven-surefire] olamy commented on pull request #486: [SUREFIRE-2001] Sometimes the plugin prints an internal stack trace on BUILD FAILURE
olamy commented on pull request #486: URL: https://github.com/apache/maven-surefire/pull/486#issuecomment-1066006526 > @slawekjaranowski @hboutemy @olamy What's the difference between these constructors? What's the difference between these two exceptions. > > The purpose of both exceptions (`MojoExecutionException` and `MojoFailureException`) is written with the example of m-compiler-p in the Javadoc. Please provide a link. > Briefly speaking, the `MojoFailureException` is related to a config error, e.g. user error as for instance you configure the parameter `parallel` on the provider which does not support the `parallel` exec. On the other hand the `MojoExecutionException` is the error of the plugin itself. > what is the difference for the end user if term of build result and output? > Basically, this is wrong question and should not be given to me because I did not create this API for Plugins and I am not the author of `SurefireHelper.java`. This code existed here for years. I remember these calls of exceptions maybe 8 years. It means that the author of these exceptions knew that they should be called with purpose. I do not point any fingers on anybody. I'm just saying this code not worth it and can be simplify as it doesn;t bring any value for end user. The result is same. so if we can simplify a bit the surefire code that will be great. The code exists because it has been created with maven2 but doesn't have any sense anymore now with maven3 So **again** it can be simplified and I'm not blaming anybody. > > One can be wondering why we alter the constructors even if the second parameter is null. I am wondering about it too, but the most important is the result. I tried to call all constructors but this actually works properly and the message is as expected too. Pls give me a hint if you can, I appreciate it. The fact is that the clients are wondering why there is the stack trace on the console, and some users are asking these questions on the **StackOverlow**. These questions are bad for us especially in case of `BUILD FAILURE` because the stack trace gives a bad impression to the users that the the problem is in the plugin but the problem is not in the plugin in real! And I saw the colleagues of mine in the companies that they are not scrolling up to see the test error, there is no reason to print the stack trace if the `firstForkException` is null. Sometimes the newbies users do not understand that they should scroll higher a bit to see that the bottom is not important, but their practices come from they daily experiences of another tools where only exceptions are important to see and so the people sometimes filter out all relevant messages on the console, so they have this selective read abilities. So the stack trace is annoying if it is irrelevant to see for them. > please provide some example projects as I don't really understand your point here. and especially in a user point of view. > These questions regarding existence of exceptions should not be given to me as I am not the author of the `Maven Plugin API`. These exceptions were here always. I do not see any reason why we should not use them. We have always used them, so I am only preventing showing stack trace when should not be shown on the console. The exceptions have been used for many years, even before when I entered the ASF. It means that the exceptions have certain purpose for the author. The questions could be given to @krosenvold or @agudian as well, who were our colleagues and they are in the same situation as me or you or anybody else, which means that we use the API still the same way for years and we respect the API. I can see another reason why these questions are rised up, and they are not very technical, and I have to say that the same is elaborated in Olivier's PR and Olivier does not want to accept my arguments that the exceptions are two, we have to respect the API and the purpose, again please read my arguments below or have a look at the sample project provided, APIs > and the most imporant argument is that it is very silly to report **BUILD FAILURE if -Dmaven.test.failure.ignore=true** - try to read it because it is really funny to ignore my argument which explains that the users wants to ignore failures in the build but we finish the build with FAILURE. That's the reason why I recommended to Olivier to throw a **specific** exception as an error and not a failure. Why I want to recommend it? Because the developers make mistakes in the future and it is better to show them that `MojoExecutionException` is intended in the particular **IF statement**. Removing the calls of `MojoExecutionException` would be maybe an ego benefit in Olivier's PR but definitelly it would not be the rightest right decision. > it's not related to this PR and
[jira] [Commented] (MCOMPILER-347) Includes and excludes not passed into CompilerConfiguration
[
https://issues.apache.org/jira/browse/MCOMPILER-347?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17505373#comment-17505373
]
Hudson commented on MCOMPILER-347:
--
Build succeeded in Jenkins: Maven » Maven TLP » maven-compiler-plugin » master
#44
See
https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven-compiler-plugin/job/master/44/
> Includes and excludes not passed into CompilerConfiguration
> ---
>
> Key: MCOMPILER-347
> URL: https://issues.apache.org/jira/browse/MCOMPILER-347
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.5
>Reporter: zhangchang
>Assignee: Olivier Lamy
>Priority: Major
> Fix For: 3.11.0
>
>
> Some groovy script is only for runtime excute, other source need compile for
> test.
> So I set exclude in maven-compiler-plugin tag, but it not work.
> {code:java}
>
> ...
>
>
> maven-compiler-plugin
> 3.5
>
> groovy-eclipse-compiler
>
> **/rest/*
>
>
>
>
> org.codehaus.groovy
> groovy-eclipse-compiler
> 2.9.2-01
>
>
> org.codehaus.groovy
> groovy-eclipse-batch
> 2.4.3-01
>
>
>
>
> ...
>
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [maven-resolver] cstamas commented on pull request #154: [MRESOLVER-241] Resolver checksum calculation should be driven by layout
cstamas commented on pull request #154: URL: https://github.com/apache/maven-resolver/pull/154#issuecomment-1065985638 @michael-o review last commits pls, much simpler -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Created] (MNG-7430) mark MojoExecutionException as deprecated
Olivier Lamy created MNG-7430:
-
Summary: mark MojoExecutionException as deprecated
Key: MNG-7430
URL: https://issues.apache.org/jira/browse/MNG-7430
Project: Maven
Issue Type: Task
Components: Core
Reporter: Olivier Lamy
since the start of Maven 3.x there is no more difference in the build
result/output between MojoFailureException and MojoExecutionException.
Even the javadoc is wrong as it says
{quote}Throwing this exception causes a "BUILD ERROR" message to be
displayed.{quote}
https://github.com/apache/maven/blob/14ca7234380f81e54a5643082816048f3b6b67cf/maven-plugin-api/src/main/java/org/apache/maven/plugin/MojoExecutionException.java#L24
which definitely never happen see sample here
https://github.com/olamy/maven-exception-plugin
we could mark it as deprecated for 3.9.x onward.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [maven-surefire] Tibor17 edited a comment on pull request #486: [SUREFIRE-2001] Sometimes the plugin prints an internal stack trace on BUILD FAILURE
Tibor17 edited a comment on pull request #486: URL: https://github.com/apache/maven-surefire/pull/486#issuecomment-1065981465 @slawekjaranowski @hboutemy @olamy What's the difference between these constructors? What's the difference between these two exceptions. The purpose of both exceptions (`MojoExecutionException` and `MojoFailureException`) is written with the example of m-compiler-p in the Javadoc. Briefly speaking, the `MojoFailureException` is related to a config error, e.g. user error as for instance you configure the parameter `parallel` on the provider which does not support the `parallel` exec. On the other hand the `MojoExecutionException` is the error of the plugin itself. Basically, this is wrong question and should not be given to me because I did not create this API for Plugins and I am not the author of `SurefireHelper.java`. This code existed here for years. I remember these calls of exceptions maybe 8 years. It means that the author of these exceptions knew that they should be called with purpose. One can be wondering why we alter the constructors even if the second parameter is null. I am wondering about it too, but the most important is the result. I tried to call all constructors but this actually works properly and the message is as expected too. Pls give me a hint if you can, I appreciate it. The fact is that the clients are wondering why there is the stack trace on the console, and some users are asking these questions on the **StackOverlow**. These questions are bad for us especially in case of `BUILD FAILURE` because the stack trace gives a bad impression to the users that the the problem is in the plugin but the problem is not in the plugin in real! And I saw the colleagues of mine in the companies that they are not scrolling up to see the test error, there is no reason to print the stack trace if the `firstForkException` is null. Sometimes the newbies users do not understand that they should scroll higher a bit to see that the bottom is not important, but their practices come from they daily experiences of another tools where only exceptions are important to see and so the people sometimes filter out all relevant messages on the console, so they have this selective read abilities. So the stack trace is annoying if it is irrelevant to see for them. These questions regarding existence of exceptions should not be given to me as I am not the author of the `Maven Plugin API`. These exceptions were here always. I do not see any reason why we should not use them. We have always used them, so I am only preventing showing stack trace when should not be shown on the console. The exceptions have been used for many years, even before when I entered the ASF. It means that the exceptions have certain purpose for the author. The questions could be given to @krosenvold or @agudian as well, who were our colleagues and they are in the same situation as me or you or anybody else, which means that we use the API still the same way for years and we respect the API. I can see another reason why these questions are rised up, and they are not very technical, and I have to say that the same is elaborated in Olivier's PR and Olivier does not want to accept my arguments that the exceptions are two, we have to respect the API and the purpose, and the most imporant argument is that it is very silly to report **BUILD FAILURE if -Dmaven.test.failure.ignore=true** - try to read it because it is really funny to ignore my argument which explains that the users wants to ignore failures in the build but we finish the build with FAILURE. That's the reason why I recommended to Olivier to throw a **specific** exception as an error and not a failure. Why I want to recommend it? Because the developers make mistakes in the future and it is better to show them that `MojoExecutionException` is intended in the particular **IF statement**. Removing the calls of `MojoExecutionException` would be maybe an ego benefit in Olivier's PR but definitelly it would not be the rightest right decision. Mostly if the `firstForkException` is not null the plugin throws `BUILD ERROR` and the stack trace makes sense because it is the real internal error. There is one more situation and it is the timeout. It is not a typical failure due to the JVMs have been timed out and stopped - the JVM was stopped abruptly - with an exit error code. -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Closed] (MCOMPILER-347) Includes and excludes not passed into CompilerConfiguration
[
https://issues.apache.org/jira/browse/MCOMPILER-347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Olivier Lamy closed MCOMPILER-347.
--
Resolution: Fixed
PR merged
Thanks!
> Includes and excludes not passed into CompilerConfiguration
> ---
>
> Key: MCOMPILER-347
> URL: https://issues.apache.org/jira/browse/MCOMPILER-347
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.5
>Reporter: zhangchang
>Assignee: Olivier Lamy
>Priority: Major
> Fix For: 3.11.0
>
>
> Some groovy script is only for runtime excute, other source need compile for
> test.
> So I set exclude in maven-compiler-plugin tag, but it not work.
> {code:java}
>
> ...
>
>
> maven-compiler-plugin
> 3.5
>
> groovy-eclipse-compiler
>
> **/rest/*
>
>
>
>
> org.codehaus.groovy
> groovy-eclipse-compiler
> 2.9.2-01
>
>
> org.codehaus.groovy
> groovy-eclipse-batch
> 2.4.3-01
>
>
>
>
> ...
>
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [maven-compiler-plugin] olamy merged pull request #101: [MCOMPILER-347] Set Xcludes in config passed to actual compiler
olamy merged pull request #101: URL: https://github.com/apache/maven-compiler-plugin/pull/101 -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-surefire] Tibor17 edited a comment on pull request #486: [SUREFIRE-2001] Sometimes the plugin prints an internal stack trace on BUILD FAILURE
Tibor17 edited a comment on pull request #486: URL: https://github.com/apache/maven-surefire/pull/486#issuecomment-1065981465 @slawekjaranowski @hboutemy @olamy What's the difference between these constructors? What's the difference between these two exceptions. The purpose of both exceptions (`MojoExecutionException` and `MojoFailureException`) is written with the example of m-compiler-p in the Javadoc. Briefly speaking, the `MojoFailureException` is related to a config error, e.g. user error as for instance you configure the parameter `parallel` on the provider which does not support the `parallel` exec. On the other hand the `MojoExecutionException` is the error of the plugin itself. Basically, this is wrong question and should not be given to me because I did not create this API for Plugins and I am not the author of `SurefireHelper.java`. This code existed here for years. I remember these calls of exceptions maybe 8 years. It means that the author of these exceptions knew that they should be called with purpose. One can be wondering why we alter the constructors even if the second parameter is null. I am wondering about it too, but the most important is the result. I tried to call all constructors but this actually works properly and the message is as expected too. Pls give me a hint if you can, I appreciate it. The fact is that the clients are wondering why there is the stack trace on the console, and some users are asking these questions on the **StackOverlow**. These questions are bad for us especially in case of `BUILD FAILURE` because the stack trace gives a bad impression to the users that the the problem is in the plugin but the problem is not in the plugin in real! And I saw the colleagues of mine in the companies that they are not scrolling up to see the test error, there is no reason to print the stack trace if the `firstForkException` is null. Sometimes the newbies users do not understand that they should scroll higher a bit to see that the bottom is not important, but their practices come from they daily experiences of another tools where only exceptions are important to see and so the people sometimes filter out all relevant messages on the console, so they have this selective read abilities. So the stack trace is annoying if it is irrelevant to see for them. These questions regarding existence of exceptions should not be given to me as I am not the author of the `Maven Plugin API`. These exceptions were here always. I do not see any reason why we should not use them. We have always used them, so I am only preventing showing stack trace when should not be shown on the console. The exceptions have been used for many years, even before when I entered the ASF. It means that the exceptions have certain purpose for the author. The questions could be given to @krosenvold or @agudian as well, who were our colleagues and they are in the same situation as me or you or anybody else, which means that we use the API still the same way for years and we respect the API. I can see another reason why these questions are rised up, and they are not very technical, and I have to say that the same is elaborated in Olivier's PR and Olivier does not want to accept my arguments that the exceptions are two, we have to respect the API and the purpose, and the most imporant argument is that it is very silly to report **BUILD FAILURE if -Dmaven.test.failure.ignore=true** - try to read it because it is really funny to ignore my argument which explains that the users wants to ignore failures in the build but we finish the build with FAILURE. That's the reason why I recommended to Olivier to throw a **specific** exception as an error and not a failure. Why I want to recommend it? Because the developers make mistakes in the future and it is better to show them that `MojoExecutionException` is intended in the particular **IF statement**. Removing the calls of `MojoExecutionException` would be maybe an ego benefit in Olivier's PR but definitelly it would not be the rightest right decision. Mostly if the `firstForkException` is not null the plugin throws `BUILD ERROR` and the stack trace makes sense because it is the real internal error. There is one more situation and it is the timeout. It is not a typical failure doe to the JVMs have been timedout and stopped - the JVM were stopped abruptly - with exit error code. -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-resolver] cstamas commented on a change in pull request #154: [MRESOLVER-241] Resolver checksum calculation should be driven by layout
cstamas commented on a change in pull request #154: URL: https://github.com/apache/maven-resolver/pull/154#discussion_r825363398 ## File path: maven-resolver-spi/src/main/java/org/eclipse/aether/spi/connector/checksum/ArtifactChecksumFilter.java ## @@ -0,0 +1,44 @@ +package org.eclipse.aether.spi.connector.checksum; + +/* + * Licensed to the Apache Software Foundation (ASF) under one + * or more contributor license agreements. See the NOTICE file + * distributed with this work for additional information + * regarding copyright ownership. The ASF licenses this file + * to you under the Apache License, Version 2.0 (the + * "License"); you may not use this file except in compliance + * with the License. You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, + * software distributed under the License is distributed on an + * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY + * KIND, either express or implied. See the License for the + * specific language governing permissions and limitations + * under the License. + */ + +import org.eclipse.aether.artifact.Artifact; + +/** + * Filter that is able to tell does artifact have expected checksums or not. Most notably, artifacts like + * different kind of signatures will not have checksums. + * + * @since 1.8.0 + */ +public interface ArtifactChecksumFilter Review comment: hm, this needs more refactoring: I just realized, this is internal matter of Maven2RepositoryLayoutFactory. Still, IMO we do want to have it extensible, but as is in this PR, it seems misleading, as it's factory is really neglecting passed in repository completely, while all this applies to maven2 layout only. Also, I don't think a generic factory is right here, hence, I dislike to copy+paste same logic as in maven2 layout factory... Finally, I'd make this part of layout, not checksum package, maybe even just as a method on RepositoryLayout (to expose it) but it would be used internally by maven2 layout to decide... -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-surefire] Tibor17 edited a comment on pull request #486: [SUREFIRE-2001] Sometimes the plugin prints an internal stack trace on BUILD FAILURE
Tibor17 edited a comment on pull request #486: URL: https://github.com/apache/maven-surefire/pull/486#issuecomment-1065981465 @slawekjaranowski @hboutemy @olamy What's the difference between these constructors? What's the difference between these two exceptions. The purpose of both exceptions (`MojoExecutionException` and `MojoFailureException`) is written with the example of m-compiler-p in the Javadoc. Briefly speaking, the `MojoFailureException` is related to a config error, e.g. user error as for instance you configure the parameter `parallel` on the provider which does not support the `parallel` exec. On the other hand the `MojoExecutionException` is the error of the plugin itself. Basically, this is wrong question and should not be given to me because I did not create this API for Plugins and I am not the author of `SurefireHelper.java`. This code existed here for years. I remember these calls of exceptions maybe 8 years. It means that the author of these exceptions knew that they should be called with purpose. One can be wondering why we alter the constructors even if the second parameter is null. I am wondering about it too, but the most important is the result. I tried to call all constructors but this actually works properly and the message is as expected too. Pls give me a hint if you can, I appreciate it. The fact is that the clients are wondering why there is the stack trace on the console, and some users are asking these questions on the **StackOverlow**. These questions are bad for us especially in case of `BUILD FAILURE` because the stack trace gives a bad impression to the users that the the problem is in the plugin but the problem is not in the plugin in real! And I saw the colleagues of mine in the companies that they are not scrolling up to see the test error, there is no reason to print the stack trace if the `firstForkException` is null. Sometimes the newbies users do not understand that they should scroll higher a bit to see that the bottom is not important, but their practices come from they daily experiences of another tools where only exceptions are important to see and so the people sometimes filter out all relevant messages on the console, so they have this selective read abilities. So the stack trace is annoying if it is irrelevant to see for them. These questions regarding existence of exceptions should not be given to me as I am not the author of the `Maven Plugin API`. These exceptions were here always. I do not see any reason why we should not use them. We have always used them, so I am only preventing showing stack trace when should not be shown on the console. The exceptions have been used for many years, even before when I entered the ASF. It means that the exceptions have certain purpose for the author. The questions could be given to @krosenvold or @agudian as well, who were our colleagues and they are in the same situation as me or you or anybody else, which means that we use the API still the same way for years and we respect the API. I can see another reason why these questions are rised up, and they are not very technical, and I have to say that the same is elaborated in Olivier's PR and Olivier does not want to accept my arguments that the exceptions are two, we have to respect the API and the purpose, and the most imporant argument is that it is very silly to report **BUILD FAILURE if -Dmaven.test.failure.ignore=true** - try to read it because it is really funny to ignore my argument which explains that the users wants to ignore failures in the build but we finish the build with FAILURE. That's the reason why I recommended to Olivier to throw a **specific** exception as an error and not a failure. Why I want to recommend it? Because the developers make mistakes in the future and it is better to show them that `MojoExecutionException` is intended in the particular **IF statement**. Removing the calls of `MojoExecutionException` would be maybe a benefit in Olivier's PR but definitelly it would not be the rightest right decision. Mostly if the `firstForkException` is not null the plugin throws `BUILD ERROR` and the stack trace makes sense because it is the real internal error. There is one more situation and it is the timeout. It is not a typical failure doe to the JVMs have been timedout and stopped - the JVM were stopped abruptly - with exit error code. -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-surefire] Tibor17 edited a comment on pull request #486: [SUREFIRE-2001] Sometimes the plugin prints an internal stack trace on BUILD FAILURE
Tibor17 edited a comment on pull request #486: URL: https://github.com/apache/maven-surefire/pull/486#issuecomment-1065981465 @slawekjaranowski @hboutemy @olamy What's the difference between these constructors? What's the difference between these two exceptions. The purpose of both exceptions (`MojoExecutionException` and `MojoFailureException`) is written with the example of m-compiler-p in the Javadoc. Briefly speaking, the `MojoFailureException` is related to a config error, e.g. user error as for instance you configure the parameter `parallel` on the provider which does not support the `parallel` exec. On the other hand the `MojoExecutionException` is the error of the plugin itself. Basically, this is wrong question and should not be given to me because I did not create this API for Plugins and I am not the author of `SurefireHelper.java`. This code existed here for years. I remember these calls of exceptions maybe 8 years. It means that the author of these exceptions knew that they should be called with purpose. One can be wondering why we alter the constructors even if the second parameter is null. I am wondering about it too, but the most important is the result. I tried to call all constructors but this actually works properly and the message is as expected too. Pls give me a hint if you can, I appreciate it. The fact is that the clients are wondering why there is the stack trace on the console, and some users are asking these questions on the **StackOverlow**. These questions are bad for us especially in case of `BUILD FAILURE` because the stack trace gives a bad impression to the users that the the problem is in the plugin and I saw the colleagues of mine in the companies that they are not scrolling up to see the test error, there is no reason to print the stack trace if the `firstForkException` is null. Sometimes the newbies users do not understand that they should scroll higher a bit to see that the bottom is not important, but their practices come from they daily experiences of another tools where only exceptions are important to see and so the people sometimes filter out all relevant messages on the console, so they have this selective read abilities. So the stack trace is annoying if it is irrelevant to see for them. These questions regarding existence of exceptions should not be given to me as I am not the author of the `Maven Plugin API`. These exceptions were here always. I do not see any reason why we should not use them. We have always used them, so I am only preventing showing stack trace when should not be shown on the console. The exceptions have been used for many years, even before when I entered the ASF. It means that the exceptions have certain purpose for the author. The questions could be given to @krosenvold or @agudian as well, who were our colleagues and they are in the same situation as me or you or anybody else, which means that we use the API still the same way for years and we respect the API. I can see another reason why these questions are rised up, and they are not very technical, and I have to say that the same is elaborated in Olivier's PR and Olivier does not want to accept my arguments that the exceptions are two, we have to respect the API and the purpose, and the most imporant argument is that it is very silly to report **BUILD FAILURE if -Dmaven.test.failure.ignore=true** - try to read it because it is really funny to ignore my argument which explains that the users wants to ignore failures in the build but we finish the build with FAILURE. That's the reason why I recommended to Olivier to throw a **specific** exception as an error and not a failure. Why I want to recommend it? Because the developers make mistakes in the future and it is better to show them that `MojoExecutionException` is intended in the particular **IF statement**. Removing the calls of `MojoExecutionException` would be maybe a benefit in Olivier's PR but definitelly it would not be the rightest right decision. Mostly if the `firstForkException` is not null the plugin throws `BUILD ERROR` and the stack trace makes sense because it is the real internal error. There is one more situation and it is the timeout. It is not a typical failure doe to the JVMs have been timedout and stopped - the JVM were stopped abruptly - with exit error code. -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-surefire] Tibor17 edited a comment on pull request #486: [SUREFIRE-2001] Sometimes the plugin prints an internal stack trace on BUILD FAILURE
Tibor17 edited a comment on pull request #486: URL: https://github.com/apache/maven-surefire/pull/486#issuecomment-1065981465 @slawekjaranowski @hboutemy @olamy What's the difference between these constructors? What's the difference between these two exceptions. The purpose of both exceptions (`MojoExecutionException` and `MojoFailureException`) is written with the example of m-compiler-p in the Javadoc. Briefly speaking, the `MojoFailureException` is related to a config error, e.g. user error as for instance you configure the parameter `parallel` on the provider which does not support the `parallel` exec. On the other hand the `MojoExecutionException` is the error of the plugin itself. Basically, this is wrong question and should not be given to me because I did not create this API for Plugins and I am not the author of `SurefireHelper.java`. This code existed here for years. I remember these calls of exceptions maybe 8 years. It means that the author of them knew that it should be called this way. One can be wondering why we alter the constructors even if the second parameter is null. I am wondering about it too, but the most important is the result. I tried to call all constructors but this actually works properly and the message is as expected too. Pls give me a hint if you can, I appreciate it. The fact is that the clients are wondering why there is the stack trace on the console, and some users are asking these questions on the **StackOverlow**. These questions are bad for us especially in case of `BUILD FAILURE` because the stack trace gives a bad impression to the users that the the problem is in the plugin and I saw the colleagues of mine in the companies that they are not scrolling up to see the test error, there is no reason to print the stack trace if the `firstForkException` is null. Sometimes the newbies users do not understand that they should scroll higher a bit to see that the bottom is not important, but their practices come from they daily experiences of another tools where only exceptions are important to see and so the people sometimes filter out all relevant messages on the console, so they have this selective read abilities. So the stack trace is annoying if it is irrelevant to see for them. These questions regarding existence of exceptions should not be given to me as I am not the author of the `Maven Plugin API`. These exceptions were here always. I do not see any reason why we should not use them. We have always used them, so I am only preventing showing stack trace when should not be shown on the console. The exceptions have been used for many years, even before when I entered the ASF. It means that the exceptions have certain purpose for the author. The questions could be given to @krosenvold or @agudian as well, who were our colleagues and they are in the same situation as me or you or anybody else, which means that we use the API still the same way for years and we respect the API. I can see another reason why these questions are rised up, and they are not very technical, and I have to say that the same is elaborated in Olivier's PR and Olivier does not want to accept my arguments that the exceptions are two, we have to respect the API and the purpose, and the most imporant argument is that it is very silly to report **BUILD FAILURE if -Dmaven.test.failure.ignore=true** - try to read it because it is really funny to ignore my argument which explains that the users wants to ignore failures in the build but we finish the build with FAILURE. That's the reason why I recommended to Olivier to throw a **specific** exception as an error and not a failure. Why I want to recommend it? Because the developers make mistakes in the future and it is better to show them that `MojoExecutionException` is intended in the particular **IF statement**. Removing the calls of `MojoExecutionException` would be maybe a benefit in Olivier's PR but definitelly it would not be the rightest right decision. Mostly if the `firstForkException` is not null the plugin throws `BUILD ERROR` and the stack trace makes sense because it is the real internal error. There is one more situation and it is the timeout. It is not a typical failure doe to the JVMs have been timedout and stopped - the JVM were stopped abruptly - with exit error code. -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-surefire] Tibor17 edited a comment on pull request #486: [SUREFIRE-2001] Sometimes the plugin prints an internal stack trace on BUILD FAILURE
Tibor17 edited a comment on pull request #486: URL: https://github.com/apache/maven-surefire/pull/486#issuecomment-1065981465 @slawekjaranowski @hboutemy @olamy What's the difference between these constructors? What's the difference between these two exceptions. The purpose of both exceptions (`MojoExecutionException` and `MojoFailureException`) is written with the example of m-compiler-p in the Javadoc. Briefly speaking, the `MojoFailureException` is related to a config error, e.g. user error as for instance you configure the parameter `parallel` on the provider which does not support the `parallel` exec. On the other hand the `MojoExecutionException` is the error of the plugin itself. Basically, this is wrong question and should not be given to me because I did not create this API for Plugins and I am not the author of `SurefireHelper.java`. This code existed here for years. I remember these calls of exceptions maybe 8 years. It means that the author of them knew that it should be called this way. One can be wondering why we alter the constructors even if the second parameter is null. I am wondering about it too, but the most important is the result. I tried to call all constructors but this actually works properly and the message is as expected too. Pls give me a hint if you can, I appreciate it. The fact is that the clients are wondering why there is the stack trace on the console, and some users are asking these questions on the **StackOverlow**. These questions are bad for us especially in case of `BUILD FAILURE` because the stack trace gives a bad impression to the users that the the problem is in the plugin and I saw the colleagues of mine in the companies that they are not scrolling up to see the test error, there is no reason to print the stack trace if the `firstForkException` is null. Sometimes the newbies users do not understand that they should scroll higher a bit to see that the bottom is not important, but their practices come from they daily experiences of another tools where only exceptions are important to see and so the people sometimes filter our all relevant messages on the console, so they have this selective read abilities. So the stack trace is annoying if it is irrelevant to see for them. These questions regarding existence of exceptions should not be given to me as I am not the author of the `Maven Plugin API`. These exceptions were here always. I do not see any reason why we should not use them. We have always used them, so I am only preventing showing stack trace when should not be shown on the console. The exceptions have been used for many years, even before when I entered the ASF. It means that the exceptions have certain purpose for the author. The questions could be given to @krosenvold or @agudian as well, who were our colleagues and they are in the same situation as me or you or anybody else, which means that we use the API still the same way for years and we respect the API. I can see another reason why these questions are rised up, and they are not very technical, and I have to say that the same is elaborated in Olivier's PR and Olivier does not want to accept my arguments that the exceptions are two, we have to respect the API and the purpose, and the most imporant argument is that it is very silly to report **BUILD FAILURE if -Dmaven.test.failure.ignore=true** - try to read it because it is really funny to ignore my argument which explains that the users wants to ignore failures in the build but we finish the build with FAILURE. That's the reason why I recommended to Olivier to throw a **specific** exception as an error and not a failure. Why I want to recommend it? Because the developers make mistakes in the future and it is better to show them that `MojoExecutionException` is intended in the particular **IF statement**. Removing the calls of `MojoExecutionException` would be maybe a benefit in Olivier's PR but definitelly it would not be the rightest right decision. Mostly if the `firstForkException` is not null the plugin throws `BUILD ERROR` and the stack trace makes sense because it is the real internal error. There is one more situation and it is the timeout. It is not a typical failure doe to the JVMs have been timedout and stopped - the JVM were stopped abruptly - with exit error code. -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-surefire] Tibor17 commented on pull request #486: [SUREFIRE-2001] Sometimes the plugin prints an internal stack trace on BUILD FAILURE
Tibor17 commented on pull request #486: URL: https://github.com/apache/maven-surefire/pull/486#issuecomment-1065981465 @slawekjaranowski @hboutemy @olamy What's the difference between these constructors? What's the difference between these two exceptions. The purpose of both exceptions (`MojoExecutionException` and `MojoFailureException`) is written with the example of m-compiler-p in the Javadoc. Briefly speaking, the `MojoFailureException` is related to a config error, e.g. user error as for instance you configure the parameter `parallel` on the provider which does not support the `parallel` exec. On the other hand the `MojoExecutionException` is the error of the plugin itself. Basically, this is wrong question and should not be given to me because I did not create this API for Plugins and I am not the author of `SurefireHelper.java`. This code existed here for years. I remember I these calls of exceptions maybe 8 years ago. It means that the author of them knew that it should be called this way. One can be wondering why we alter the constructors even if the second parameter is null. I am wondering about it too, but the most important is the result. I tried to call all constructors but this actually works properly and the message is as expected too. Pls give me a hint if you can, I appreciate it. The fact is that the clients are wondering why there is the stack trace on the console, and some users are asking these questions on the **StackOverlow**. These questions are bad for us especially in case of `BUILD FAILURE` because the stack trace gives a bad impression to the users that the the problem is in the plugin and I saw the colleagues of mine in the companies that they are not scrolling up to see the test error, there is no reason to print the stack trace if the `firstForkException` is null. Sometimes the newbies users do not understand that they should scroll higher a bit to see that the bottom is not important, but their practices come from they daily experiences of another tools where only exceptions are important to see and so the people sometimes filter our all relevant messages on the console, so they have this selective read abilities. So the stack trace is annoying if it is irrelevant to see for them. These questions regarding existence of exceptions should not be given to me as I am not the author of the `Maven Plugin API`. These exceptions were here always. I do not see any reason why we should not use them. We have always used them, so I am only preventing showing stack trace when should not be shown on the console. The exceptions have been used for many years, even before when I entered the ASF. It means that the exceptions have certain purpose for the author. The questions could be given to @krosenvold or @agudian as well, who were our colleagues and they are in the same situation as me or you or anybody else, which means that we use the API still the same way for years and we respect the API. I can see another reason why these questions are rised up, and they are not very technical, and I have to say that the same is elaborated in Olivier's PR and Olivier does not want to accept my arguments that the exceptions are two, we have to respect the API and the purpose, and the most imporant argument is that it is very silly to report **BUILD FAILURE if -Dmaven.test.failure.ignore=true** - try to read it because it is really funny to ignore my argument which explains that the users wants to ignore failures in the build but we finish the build with FAILURE. That's the reason why I recommended to Olivier to throw a **specific** exception as an error and not a failure. Why I want to recommend it? Because the developers make mistakes in the future and it is better to show them that `MojoExecutionException` is intended in the particular **IF statement**. Removing the calls of `MojoExecutionException` would be maybe a benefit in Olivier's PR but definitelly it would not be the rightest right decision. Mostly if the `firstForkException` is not null the plugin throws `BUILD ERROR` and the stack trace makes sense because it is the real internal error. There is one more situation and it is the timeout. It is not a typical failure doe to the JVMs have been timedout and stopped - the JVM were stopped abruptly - with exit error code. -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-resolver] michael-o commented on a change in pull request #154: [MRESOLVER-241] Resolver checksum calculation should be driven by layout
michael-o commented on a change in pull request #154: URL: https://github.com/apache/maven-resolver/pull/154#discussion_r825361384 ## File path: maven-resolver-spi/src/main/java/org/eclipse/aether/spi/connector/checksum/ArtifactChecksumFilter.java ## @@ -0,0 +1,44 @@ +package org.eclipse.aether.spi.connector.checksum; + +/* + * Licensed to the Apache Software Foundation (ASF) under one + * or more contributor license agreements. See the NOTICE file + * distributed with this work for additional information + * regarding copyright ownership. The ASF licenses this file + * to you under the Apache License, Version 2.0 (the + * "License"); you may not use this file except in compliance + * with the License. You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, + * software distributed under the License is distributed on an + * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY + * KIND, either express or implied. See the License for the + * specific language governing permissions and limitations + * under the License. + */ + +import org.eclipse.aether.artifact.Artifact; + +/** + * Filter that is able to tell does artifact have expected checksums or not. Most notably, artifacts like + * different kind of signatures will not have checksums. + * + * @since 1.8.0 + */ +public interface ArtifactChecksumFilter Review comment: `ArtifactChecksumDecider`? -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-resolver] cstamas commented on a change in pull request #154: [MRESOLVER-241] Resolver checksum calculation should be driven by layout
cstamas commented on a change in pull request #154: URL: https://github.com/apache/maven-resolver/pull/154#discussion_r825361307 ## File path: maven-resolver-spi/src/main/java/org/eclipse/aether/spi/connector/checksum/ArtifactChecksumFilter.java ## @@ -0,0 +1,44 @@ +package org.eclipse.aether.spi.connector.checksum; + +/* + * Licensed to the Apache Software Foundation (ASF) under one + * or more contributor license agreements. See the NOTICE file + * distributed with this work for additional information + * regarding copyright ownership. The ASF licenses this file + * to you under the Apache License, Version 2.0 (the + * "License"); you may not use this file except in compliance + * with the License. You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, + * software distributed under the License is distributed on an + * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY + * KIND, either express or implied. See the License for the + * specific language governing permissions and limitations + * under the License. + */ + +import org.eclipse.aether.artifact.Artifact; + +/** + * Filter that is able to tell does artifact have expected checksums or not. Most notably, artifacts like + * different kind of signatures will not have checksums. + * + * @since 1.8.0 + */ +public interface ArtifactChecksumFilter Review comment: Another minor thing: am not quite ok with class name `ArtifactChecksumFilter`. This class basically tells does passed in Artifact should have checksums or not... and it does not "filter" per se... -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-resolver] cstamas commented on a change in pull request #154: [MRESOLVER-241] Resolver checksum calculation should be driven by layout
cstamas commented on a change in pull request #154: URL: https://github.com/apache/maven-resolver/pull/154#discussion_r825360764 ## File path: maven-resolver-spi/src/main/java/org/eclipse/aether/spi/connector/checksum/ArtifactChecksumFilter.java ## @@ -0,0 +1,44 @@ +package org.eclipse.aether.spi.connector.checksum; + +/* + * Licensed to the Apache Software Foundation (ASF) under one + * or more contributor license agreements. See the NOTICE file + * distributed with this work for additional information + * regarding copyright ownership. The ASF licenses this file + * to you under the Apache License, Version 2.0 (the + * "License"); you may not use this file except in compliance + * with the License. You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, + * software distributed under the License is distributed on an + * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY + * KIND, either express or implied. See the License for the + * specific language governing permissions and limitations + * under the License. + */ + +import org.eclipse.aether.artifact.Artifact; + +/** + * Filter that is able to tell does artifact have expected checksums or not. Most notably, artifacts like + * different kind of signatures will not have checksums. + * + * @since 1.8.0 + */ +public interface ArtifactChecksumFilter Review comment: fun fact: Central for example (but same stands for Nx2 or Artifactory) does sent checksum header for ANY payload, hence, even checksum for checksum, and resolver in this PR DOES USE IT to validate payload (these are all REMOTE_INCLUDED ones). -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-resolver] cstamas commented on a change in pull request #154: [MRESOLVER-241] Resolver checksum calculation should be driven by layout
cstamas commented on a change in pull request #154: URL: https://github.com/apache/maven-resolver/pull/154#discussion_r825360764 ## File path: maven-resolver-spi/src/main/java/org/eclipse/aether/spi/connector/checksum/ArtifactChecksumFilter.java ## @@ -0,0 +1,44 @@ +package org.eclipse.aether.spi.connector.checksum; + +/* + * Licensed to the Apache Software Foundation (ASF) under one + * or more contributor license agreements. See the NOTICE file + * distributed with this work for additional information + * regarding copyright ownership. The ASF licenses this file + * to you under the Apache License, Version 2.0 (the + * "License"); you may not use this file except in compliance + * with the License. You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, + * software distributed under the License is distributed on an + * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY + * KIND, either express or implied. See the License for the + * specific language governing permissions and limitations + * under the License. + */ + +import org.eclipse.aether.artifact.Artifact; + +/** + * Filter that is able to tell does artifact have expected checksums or not. Most notably, artifacts like + * different kind of signatures will not have checksums. + * + * @since 1.8.0 + */ +public interface ArtifactChecksumFilter Review comment: fun fact: Central for example (but same stands for Nx2 or Artifactory) does sent checksum header for ANY payload, hence, even checksum for checksum, and resolver in this PR DOES USE IT to validate payload. -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-resolver] cstamas commented on a change in pull request #154: [MRESOLVER-241] Resolver checksum calculation should be driven by layout
cstamas commented on a change in pull request #154: URL: https://github.com/apache/maven-resolver/pull/154#discussion_r825360533 ## File path: maven-resolver-spi/src/main/java/org/eclipse/aether/spi/connector/checksum/ArtifactChecksumFilter.java ## @@ -0,0 +1,44 @@ +package org.eclipse.aether.spi.connector.checksum; + +/* + * Licensed to the Apache Software Foundation (ASF) under one + * or more contributor license agreements. See the NOTICE file + * distributed with this work for additional information + * regarding copyright ownership. The ASF licenses this file + * to you under the Apache License, Version 2.0 (the + * "License"); you may not use this file except in compliance + * with the License. You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, + * software distributed under the License is distributed on an + * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY + * KIND, either express or implied. See the License for the + * specific language governing permissions and limitations + * under the License. + */ + +import org.eclipse.aether.artifact.Artifact; + +/** + * Filter that is able to tell does artifact have expected checksums or not. Most notably, artifacts like + * different kind of signatures will not have checksums. + * + * @since 1.8.0 + */ +public interface ArtifactChecksumFilter Review comment: We should clarify here: this is ONLY FOR REMOTE_EXTERNAL checksums. So if this class returns `true`, on deploy checksums will NOT be calculated and deployed, BUT on retrieve, the response payload checksums ARE calculated (to satisfy PROVIDED or REMOTE_INCLUDED), but REMOTE_EXTERNAL ones will NOT be fetched (and hence will not be validated). -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-resolver] cstamas commented on a change in pull request #154: [MRESOLVER-241] Resolver checksum calculation should be driven by layout
cstamas commented on a change in pull request #154: URL: https://github.com/apache/maven-resolver/pull/154#discussion_r825360533 ## File path: maven-resolver-spi/src/main/java/org/eclipse/aether/spi/connector/checksum/ArtifactChecksumFilter.java ## @@ -0,0 +1,44 @@ +package org.eclipse.aether.spi.connector.checksum; + +/* + * Licensed to the Apache Software Foundation (ASF) under one + * or more contributor license agreements. See the NOTICE file + * distributed with this work for additional information + * regarding copyright ownership. The ASF licenses this file + * to you under the Apache License, Version 2.0 (the + * "License"); you may not use this file except in compliance + * with the License. You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, + * software distributed under the License is distributed on an + * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY + * KIND, either express or implied. See the License for the + * specific language governing permissions and limitations + * under the License. + */ + +import org.eclipse.aether.artifact.Artifact; + +/** + * Filter that is able to tell does artifact have expected checksums or not. Most notably, artifacts like + * different kind of signatures will not have checksums. + * + * @since 1.8.0 + */ +public interface ArtifactChecksumFilter Review comment: We should clarify here: this is ONLY FOR REMOTE_EXTERNAL checksums. So if this class returns `true`, on deploy checksums will NOT be calculated and deployed, BUT on retrieve, the stream checksums ARE calculated (to satisfy PROVIDED or REMOTE_INCLUDED), but REMOTE_EXTERNAL ones will NOT be fetched (and hence will not be validated). -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-resolver] cstamas commented on a change in pull request #154: [MRESOLVER-241] Resolver checksum calculation should be driven by layout
cstamas commented on a change in pull request #154: URL: https://github.com/apache/maven-resolver/pull/154#discussion_r825360533 ## File path: maven-resolver-spi/src/main/java/org/eclipse/aether/spi/connector/checksum/ArtifactChecksumFilter.java ## @@ -0,0 +1,44 @@ +package org.eclipse.aether.spi.connector.checksum; + +/* + * Licensed to the Apache Software Foundation (ASF) under one + * or more contributor license agreements. See the NOTICE file + * distributed with this work for additional information + * regarding copyright ownership. The ASF licenses this file + * to you under the Apache License, Version 2.0 (the + * "License"); you may not use this file except in compliance + * with the License. You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, + * software distributed under the License is distributed on an + * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY + * KIND, either express or implied. See the License for the + * specific language governing permissions and limitations + * under the License. + */ + +import org.eclipse.aether.artifact.Artifact; + +/** + * Filter that is able to tell does artifact have expected checksums or not. Most notably, artifacts like + * different kind of signatures will not have checksums. + * + * @since 1.8.0 + */ +public interface ArtifactChecksumFilter Review comment: We should clarify here: this is ONLY FOR REMOTE_EXTERNAL artifacts. So if this class returns `true`, on deploy checksums will NOT be calculated and deployed, BUT on retrieve, the stream checksums ARE calculated (to satisfy PROVIDED or REMOTE_INCLUDED), but REMOTE_EXTERNAL ones will NOT be fetched (and hence will not be validated). -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-resolver] michael-o commented on pull request #154: [MRESOLVER-241] Resolver checksum calculation should be driven by layout
michael-o commented on pull request #154: URL: https://github.com/apache/maven-resolver/pull/154#issuecomment-1065978388 > If you're referring to Sigstore integration, it's up for discussion what the best naming conventions will be. I have x509, SSH, and PGP signing working. So probably want to keep `.asc` as not to interfere with existing PGP sigs, but for x509 maybe `.sig` and for SSH `.sshsig`. Not sure yet really. OK, let's move this to a separate discussion when we have somthing usable. -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-resolver] jvanzyl commented on pull request #154: [MRESOLVER-241] Resolver checksum calculation should be driven by layout
jvanzyl commented on pull request #154: URL: https://github.com/apache/maven-resolver/pull/154#issuecomment-1065978232 If you're referring to Sigstore integration, it's up for discussion what the best naming conventions will be. I have x509, SSH, and PGP signing working. So probably want to keep `.asc` as not to interfere with existing PGP sigs, but for x509 maybe `.sig` and for SSH `.sshsig`. Not sure yet really. -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-resolver] michael-o commented on pull request #154: [MRESOLVER-241] Resolver checksum calculation should be driven by layout
michael-o commented on pull request #154: URL: https://github.com/apache/maven-resolver/pull/154#issuecomment-1065977636 @jvanzyl Should we add `.sig` right away to the default list? -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-resolver] cstamas commented on a change in pull request #154: [MRESOLVER-241] Resolver checksum calculation should be driven by layout
cstamas commented on a change in pull request #154:
URL: https://github.com/apache/maven-resolver/pull/154#discussion_r825359263
##
File path:
maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/checksum/DefaultArtifactChecksumFilterFactory.java
##
@@ -0,0 +1,90 @@
+package org.eclipse.aether.internal.impl.checksum;
+
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+
+import javax.inject.Named;
+import javax.inject.Singleton;
+
+import java.util.Arrays;
+import java.util.Set;
+import java.util.stream.Collectors;
+
+import org.eclipse.aether.RepositorySystemSession;
+import org.eclipse.aether.artifact.Artifact;
+import org.eclipse.aether.repository.RemoteRepository;
+import org.eclipse.aether.spi.connector.checksum.ArtifactChecksumFilter;
+import org.eclipse.aether.spi.connector.checksum.ArtifactChecksumFilterFactory;
+import org.eclipse.aether.util.ConfigUtils;
+
+import static java.util.Objects.requireNonNull;
+
+/**
+ * Default implementation that implements default resolver strategy: filters
by known (user configured) extensions,
+ * or by default only for GPG signature.
+ *
+ * @since 1.8.0
+ */
+@Singleton
+@Named
+public class DefaultArtifactChecksumFilterFactory
+implements ArtifactChecksumFilterFactory
+{
+public static final String CONFIG_PROP_OMIT_CHECKSUMS_FOR_EXTENSIONS =
+"aether.checksums.omitChecksumsForExtensions";
+
+private static final String DEFAULT_OMIT_CHECKSUMS_FOR_EXTENSIONS = ".asc";
+
+@Override
+public ArtifactChecksumFilter newInstance( RepositorySystemSession
session, RemoteRepository repository )
+{
+// ensure uniqueness of (potentially user set) extension list
+Set omitChecksumsForExtensions = Arrays.stream(
ConfigUtils.getString(
+session, DEFAULT_OMIT_CHECKSUMS_FOR_EXTENSIONS,
CONFIG_PROP_OMIT_CHECKSUMS_FOR_EXTENSIONS )
+.split( "," )
+).filter( s -> s != null && !s.trim().isEmpty() ).collect(
Collectors.toSet() );
+
+return new ExtensionArtifactChecksumFilter( omitChecksumsForExtensions
);
+}
+
+private static class ExtensionArtifactChecksumFilter
+implements ArtifactChecksumFilter
+{
+private final Set extensionsWithoutChecksums;
+
+private ExtensionArtifactChecksumFilter( Set
extensionsWithoutChecksums )
+{
+this.extensionsWithoutChecksums = requireNonNull(
extensionsWithoutChecksums );
+}
+
+@Override
+public boolean omitChecksumsFor( Artifact artifact )
+{
+String artifactExtension = artifact.getExtension(); // ie. pom.asc
+for ( String extensionWithoutChecksums :
extensionsWithoutChecksums )
+{
+if ( artifactExtension.endsWith( extensionWithoutChecksums ) )
Review comment:
See
https://github.com/apache/maven-resolver/pull/154#discussion_r825358528
--
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.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [maven-resolver] michael-o commented on a change in pull request #154: [MRESOLVER-241] Resolver checksum calculation should be driven by layout
michael-o commented on a change in pull request #154:
URL: https://github.com/apache/maven-resolver/pull/154#discussion_r825359150
##
File path:
maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/checksum/DefaultArtifactChecksumFilterFactory.java
##
@@ -0,0 +1,90 @@
+package org.eclipse.aether.internal.impl.checksum;
+
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+
+import javax.inject.Named;
+import javax.inject.Singleton;
+
+import java.util.Arrays;
+import java.util.Set;
+import java.util.stream.Collectors;
+
+import org.eclipse.aether.RepositorySystemSession;
+import org.eclipse.aether.artifact.Artifact;
+import org.eclipse.aether.repository.RemoteRepository;
+import org.eclipse.aether.spi.connector.checksum.ArtifactChecksumFilter;
+import org.eclipse.aether.spi.connector.checksum.ArtifactChecksumFilterFactory;
+import org.eclipse.aether.util.ConfigUtils;
+
+import static java.util.Objects.requireNonNull;
+
+/**
+ * Default implementation that implements default resolver strategy: filters
by known (user configured) extensions,
+ * or by default only for GPG signature.
+ *
+ * @since 1.8.0
+ */
+@Singleton
+@Named
+public class DefaultArtifactChecksumFilterFactory
+implements ArtifactChecksumFilterFactory
+{
+public static final String CONFIG_PROP_OMIT_CHECKSUMS_FOR_EXTENSIONS =
+"aether.checksums.omitChecksumsForExtensions";
+
+private static final String DEFAULT_OMIT_CHECKSUMS_FOR_EXTENSIONS = ".asc";
Review comment:
Agreed.
--
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.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [maven-resolver] cstamas commented on a change in pull request #154: [MRESOLVER-241] Resolver checksum calculation should be driven by layout
cstamas commented on a change in pull request #154:
URL: https://github.com/apache/maven-resolver/pull/154#discussion_r825358956
##
File path:
maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/checksum/DefaultArtifactChecksumFilterFactory.java
##
@@ -0,0 +1,90 @@
+package org.eclipse.aether.internal.impl.checksum;
+
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+
+import javax.inject.Named;
+import javax.inject.Singleton;
+
+import java.util.Arrays;
+import java.util.Set;
+import java.util.stream.Collectors;
+
+import org.eclipse.aether.RepositorySystemSession;
+import org.eclipse.aether.artifact.Artifact;
+import org.eclipse.aether.repository.RemoteRepository;
+import org.eclipse.aether.spi.connector.checksum.ArtifactChecksumFilter;
+import org.eclipse.aether.spi.connector.checksum.ArtifactChecksumFilterFactory;
+import org.eclipse.aether.util.ConfigUtils;
+
+import static java.util.Objects.requireNonNull;
+
+/**
+ * Default implementation that implements default resolver strategy: filters
by known (user configured) extensions,
+ * or by default only for GPG signature.
+ *
+ * @since 1.8.0
+ */
+@Singleton
+@Named
+public class DefaultArtifactChecksumFilterFactory
+implements ArtifactChecksumFilterFactory
+{
+public static final String CONFIG_PROP_OMIT_CHECKSUMS_FOR_EXTENSIONS =
+"aether.checksums.omitChecksumsForExtensions";
+
+private static final String DEFAULT_OMIT_CHECKSUMS_FOR_EXTENSIONS = ".asc";
Review comment:
But let's not complicate, let's agree that:
* this PR w/o any custom config (in this area) behaves as master resolver
w/o any custom config (jn this area)
* this PR w/ `aether.checksums.omitChecksumsForExtensions=""` (empty string)
behaves the same as master does with `aether.checksums.forSignatures=true`
* for start, let's document these are for sub-artifacts only (signatures)
and MUST use leading period.
--
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.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [maven-resolver] michael-o commented on a change in pull request #154: [MRESOLVER-241] Resolver checksum calculation should be driven by layout
michael-o commented on a change in pull request #154:
URL: https://github.com/apache/maven-resolver/pull/154#discussion_r825358752
##
File path:
maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/checksum/DefaultArtifactChecksumFilterFactory.java
##
@@ -0,0 +1,90 @@
+package org.eclipse.aether.internal.impl.checksum;
+
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+
+import javax.inject.Named;
+import javax.inject.Singleton;
+
+import java.util.Arrays;
+import java.util.Set;
+import java.util.stream.Collectors;
+
+import org.eclipse.aether.RepositorySystemSession;
+import org.eclipse.aether.artifact.Artifact;
+import org.eclipse.aether.repository.RemoteRepository;
+import org.eclipse.aether.spi.connector.checksum.ArtifactChecksumFilter;
+import org.eclipse.aether.spi.connector.checksum.ArtifactChecksumFilterFactory;
+import org.eclipse.aether.util.ConfigUtils;
+
+import static java.util.Objects.requireNonNull;
+
+/**
+ * Default implementation that implements default resolver strategy: filters
by known (user configured) extensions,
+ * or by default only for GPG signature.
+ *
+ * @since 1.8.0
+ */
+@Singleton
+@Named
+public class DefaultArtifactChecksumFilterFactory
+implements ArtifactChecksumFilterFactory
+{
+public static final String CONFIG_PROP_OMIT_CHECKSUMS_FOR_EXTENSIONS =
+"aether.checksums.omitChecksumsForExtensions";
+
+private static final String DEFAULT_OMIT_CHECKSUMS_FOR_EXTENSIONS = ".asc";
Review comment:
OK, then I did understand your intention correctly. Yes, you proposal
makes sense and you clearly convey the difference. Please also document it in
the config.md file.
--
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.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [maven-resolver] cstamas commented on a change in pull request #154: [MRESOLVER-241] Resolver checksum calculation should be driven by layout
cstamas commented on a change in pull request #154:
URL: https://github.com/apache/maven-resolver/pull/154#discussion_r825358528
##
File path:
maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/checksum/DefaultArtifactChecksumFilterFactory.java
##
@@ -0,0 +1,90 @@
+package org.eclipse.aether.internal.impl.checksum;
+
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+
+import javax.inject.Named;
+import javax.inject.Singleton;
+
+import java.util.Arrays;
+import java.util.Set;
+import java.util.stream.Collectors;
+
+import org.eclipse.aether.RepositorySystemSession;
+import org.eclipse.aether.artifact.Artifact;
+import org.eclipse.aether.repository.RemoteRepository;
+import org.eclipse.aether.spi.connector.checksum.ArtifactChecksumFilter;
+import org.eclipse.aether.spi.connector.checksum.ArtifactChecksumFilterFactory;
+import org.eclipse.aether.util.ConfigUtils;
+
+import static java.util.Objects.requireNonNull;
+
+/**
+ * Default implementation that implements default resolver strategy: filters
by known (user configured) extensions,
+ * or by default only for GPG signature.
+ *
+ * @since 1.8.0
+ */
+@Singleton
+@Named
+public class DefaultArtifactChecksumFilterFactory
+implements ArtifactChecksumFilterFactory
+{
+public static final String CONFIG_PROP_OMIT_CHECKSUMS_FOR_EXTENSIONS =
+"aether.checksums.omitChecksumsForExtensions";
+
+private static final String DEFAULT_OMIT_CHECKSUMS_FOR_EXTENSIONS = ".asc";
Review comment:
Having or not having leading period is important:
| input | `artifact-1.0.foo` | `artifact-1.0.jar.foo` |
|---|--|-|
|`.foo` | not matches | matches |
|`foo`| matches | matches |
Some extensions (like PGP signature `asc`) may be only subartifact, so
extension is actually `jar.asc` or `pom.asc`. Still, if we'd want to generalize
this, we may do:
* if `extensionWithoutChecksums` starts with period => check with `endsWith`
* if `extensionWithoutChecksums` not starts with period => check with
`equals`
WDYT?
--
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.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [maven-resolver] cstamas commented on a change in pull request #154: [MRESOLVER-241] Resolver checksum calculation should be driven by layout
cstamas commented on a change in pull request #154:
URL: https://github.com/apache/maven-resolver/pull/154#discussion_r825358528
##
File path:
maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/checksum/DefaultArtifactChecksumFilterFactory.java
##
@@ -0,0 +1,90 @@
+package org.eclipse.aether.internal.impl.checksum;
+
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+
+import javax.inject.Named;
+import javax.inject.Singleton;
+
+import java.util.Arrays;
+import java.util.Set;
+import java.util.stream.Collectors;
+
+import org.eclipse.aether.RepositorySystemSession;
+import org.eclipse.aether.artifact.Artifact;
+import org.eclipse.aether.repository.RemoteRepository;
+import org.eclipse.aether.spi.connector.checksum.ArtifactChecksumFilter;
+import org.eclipse.aether.spi.connector.checksum.ArtifactChecksumFilterFactory;
+import org.eclipse.aether.util.ConfigUtils;
+
+import static java.util.Objects.requireNonNull;
+
+/**
+ * Default implementation that implements default resolver strategy: filters
by known (user configured) extensions,
+ * or by default only for GPG signature.
+ *
+ * @since 1.8.0
+ */
+@Singleton
+@Named
+public class DefaultArtifactChecksumFilterFactory
+implements ArtifactChecksumFilterFactory
+{
+public static final String CONFIG_PROP_OMIT_CHECKSUMS_FOR_EXTENSIONS =
+"aether.checksums.omitChecksumsForExtensions";
+
+private static final String DEFAULT_OMIT_CHECKSUMS_FOR_EXTENSIONS = ".asc";
Review comment:
Having or not having leading period is important:
| inout | `artifact-1.0.foo` | `artifact-1.0.jar.foo` |
|---|--|-|
|`.foo` | not matches | matches |
|`foo`| metches | matches |
Some extensions (like PGP signature `asc`) may be only subartifact, so
extension is actually `jar.asc` or `pom.asc`. Still, if we'd want to generalize
this, we may do:
* if `extensionWithoutChecksums` starts with period => check with `endsWith`
* if `extensionWithoutChecksums` not starts with period => check with
`equals`
WDYT?
--
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.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [maven-resolver] michael-o commented on a change in pull request #154: [MRESOLVER-241] Resolver checksum calculation should be driven by layout
michael-o commented on a change in pull request #154:
URL: https://github.com/apache/maven-resolver/pull/154#discussion_r825358352
##
File path:
maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/checksum/DefaultArtifactChecksumFilterFactory.java
##
@@ -0,0 +1,90 @@
+package org.eclipse.aether.internal.impl.checksum;
+
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+
+import javax.inject.Named;
+import javax.inject.Singleton;
+
+import java.util.Arrays;
+import java.util.Set;
+import java.util.stream.Collectors;
+
+import org.eclipse.aether.RepositorySystemSession;
+import org.eclipse.aether.artifact.Artifact;
+import org.eclipse.aether.repository.RemoteRepository;
+import org.eclipse.aether.spi.connector.checksum.ArtifactChecksumFilter;
+import org.eclipse.aether.spi.connector.checksum.ArtifactChecksumFilterFactory;
+import org.eclipse.aether.util.ConfigUtils;
+
+import static java.util.Objects.requireNonNull;
+
+/**
+ * Default implementation that implements default resolver strategy: filters
by known (user configured) extensions,
+ * or by default only for GPG signature.
+ *
+ * @since 1.8.0
+ */
+@Singleton
+@Named
+public class DefaultArtifactChecksumFilterFactory
+implements ArtifactChecksumFilterFactory
+{
+public static final String CONFIG_PROP_OMIT_CHECKSUMS_FOR_EXTENSIONS =
+"aether.checksums.omitChecksumsForExtensions";
+
+private static final String DEFAULT_OMIT_CHECKSUMS_FOR_EXTENSIONS = ".asc";
+
+@Override
+public ArtifactChecksumFilter newInstance( RepositorySystemSession
session, RemoteRepository repository )
+{
+// ensure uniqueness of (potentially user set) extension list
+Set omitChecksumsForExtensions = Arrays.stream(
ConfigUtils.getString(
+session, DEFAULT_OMIT_CHECKSUMS_FOR_EXTENSIONS,
CONFIG_PROP_OMIT_CHECKSUMS_FOR_EXTENSIONS )
+.split( "," )
+).filter( s -> s != null && !s.trim().isEmpty() ).collect(
Collectors.toSet() );
+
+return new ExtensionArtifactChecksumFilter( omitChecksumsForExtensions
);
+}
+
+private static class ExtensionArtifactChecksumFilter
+implements ArtifactChecksumFilter
+{
+private final Set extensionsWithoutChecksums;
+
+private ExtensionArtifactChecksumFilter( Set
extensionsWithoutChecksums )
+{
+this.extensionsWithoutChecksums = requireNonNull(
extensionsWithoutChecksums );
+}
+
+@Override
+public boolean omitChecksumsFor( Artifact artifact )
+{
+String artifactExtension = artifact.getExtension(); // ie. pom.asc
+for ( String extensionWithoutChecksums :
extensionsWithoutChecksums )
+{
+if ( artifactExtension.endsWith( extensionWithoutChecksums ) )
Review comment:
I don't fully understand your second comment. Does this mean that:
* Artifact Ext `X` should not be subject for checksum (without dot)
* Subartifact Ext `X.asc` needs the dot be differentiate between artifact
and subartifact?
--
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.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Updated] (JXR-168) Dependency upgrade and cleanup
[ https://issues.apache.org/jira/browse/JXR-168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Slawomir Jaranowski updated JXR-168: Description: - plexus-utils from 3.3.0 to 3.4.1 - plexus-java from 1.1.0 to 1.1.1 Transitive dependency with security issues: - commons-beanutils 1.9.4 was: - plexus-utils from 3.3.0 to 3.4.1 - plexus-java from 1.1.0 to 1.1.1 > Dependency upgrade and cleanup > -- > > Key: JXR-168 > URL: https://issues.apache.org/jira/browse/JXR-168 > Project: Maven JXR > Issue Type: Dependency upgrade >Reporter: Slawomir Jaranowski >Assignee: Slawomir Jaranowski >Priority: Major > Fix For: 3.2.0 > > > - plexus-utils from 3.3.0 to 3.4.1 > - plexus-java from 1.1.0 to 1.1.1 > Transitive dependency with security issues: > - commons-beanutils 1.9.4 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[GitHub] [maven-resolver] cstamas commented on a change in pull request #154: [MRESOLVER-241] Resolver checksum calculation should be driven by layout
cstamas commented on a change in pull request #154:
URL: https://github.com/apache/maven-resolver/pull/154#discussion_r825358035
##
File path:
maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/checksum/DefaultArtifactChecksumFilterFactory.java
##
@@ -0,0 +1,90 @@
+package org.eclipse.aether.internal.impl.checksum;
+
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+
+import javax.inject.Named;
+import javax.inject.Singleton;
+
+import java.util.Arrays;
+import java.util.Set;
+import java.util.stream.Collectors;
+
+import org.eclipse.aether.RepositorySystemSession;
+import org.eclipse.aether.artifact.Artifact;
+import org.eclipse.aether.repository.RemoteRepository;
+import org.eclipse.aether.spi.connector.checksum.ArtifactChecksumFilter;
+import org.eclipse.aether.spi.connector.checksum.ArtifactChecksumFilterFactory;
+import org.eclipse.aether.util.ConfigUtils;
+
+import static java.util.Objects.requireNonNull;
+
+/**
+ * Default implementation that implements default resolver strategy: filters
by known (user configured) extensions,
+ * or by default only for GPG signature.
+ *
+ * @since 1.8.0
+ */
+@Singleton
+@Named
+public class DefaultArtifactChecksumFilterFactory
+implements ArtifactChecksumFilterFactory
+{
+public static final String CONFIG_PROP_OMIT_CHECKSUMS_FOR_EXTENSIONS =
+"aether.checksums.omitChecksumsForExtensions";
+
+private static final String DEFAULT_OMIT_CHECKSUMS_FOR_EXTENSIONS = ".asc";
+
+@Override
+public ArtifactChecksumFilter newInstance( RepositorySystemSession
session, RemoteRepository repository )
+{
+// ensure uniqueness of (potentially user set) extension list
+Set omitChecksumsForExtensions = Arrays.stream(
ConfigUtils.getString(
+session, DEFAULT_OMIT_CHECKSUMS_FOR_EXTENSIONS,
CONFIG_PROP_OMIT_CHECKSUMS_FOR_EXTENSIONS )
+.split( "," )
+).filter( s -> s != null && !s.trim().isEmpty() ).collect(
Collectors.toSet() );
+
+return new ExtensionArtifactChecksumFilter( omitChecksumsForExtensions
);
+}
+
+private static class ExtensionArtifactChecksumFilter
+implements ArtifactChecksumFilter
+{
+private final Set extensionsWithoutChecksums;
+
+private ExtensionArtifactChecksumFilter( Set
extensionsWithoutChecksums )
+{
+this.extensionsWithoutChecksums = requireNonNull(
extensionsWithoutChecksums );
+}
+
+@Override
+public boolean omitChecksumsFor( Artifact artifact )
+{
+String artifactExtension = artifact.getExtension(); // ie. pom.asc
+for ( String extensionWithoutChecksums :
extensionsWithoutChecksums )
+{
+if ( artifactExtension.endsWith( extensionWithoutChecksums ) )
Review comment:
I think is ok: in my case of extension foo, I'd use value ".asc,foo" (so
no leading dot before foo), while for sub-artifact like signature, value to be
used is `.asc` (w/ leading dot).
--
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.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [maven-resolver] cstamas commented on a change in pull request #154: [MRESOLVER-241] Resolver checksum calculation should be driven by layout
cstamas commented on a change in pull request #154:
URL: https://github.com/apache/maven-resolver/pull/154#discussion_r825357737
##
File path:
maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/checksum/DefaultArtifactChecksumFilterFactory.java
##
@@ -0,0 +1,90 @@
+package org.eclipse.aether.internal.impl.checksum;
+
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+
+import javax.inject.Named;
+import javax.inject.Singleton;
+
+import java.util.Arrays;
+import java.util.Set;
+import java.util.stream.Collectors;
+
+import org.eclipse.aether.RepositorySystemSession;
+import org.eclipse.aether.artifact.Artifact;
+import org.eclipse.aether.repository.RemoteRepository;
+import org.eclipse.aether.spi.connector.checksum.ArtifactChecksumFilter;
+import org.eclipse.aether.spi.connector.checksum.ArtifactChecksumFilterFactory;
+import org.eclipse.aether.util.ConfigUtils;
+
+import static java.util.Objects.requireNonNull;
+
+/**
+ * Default implementation that implements default resolver strategy: filters
by known (user configured) extensions,
+ * or by default only for GPG signature.
+ *
+ * @since 1.8.0
+ */
+@Singleton
+@Named
+public class DefaultArtifactChecksumFilterFactory
+implements ArtifactChecksumFilterFactory
+{
+public static final String CONFIG_PROP_OMIT_CHECKSUMS_FOR_EXTENSIONS =
+"aether.checksums.omitChecksumsForExtensions";
+
+private static final String DEFAULT_OMIT_CHECKSUMS_FOR_EXTENSIONS = ".asc";
+
+@Override
+public ArtifactChecksumFilter newInstance( RepositorySystemSession
session, RemoteRepository repository )
+{
+// ensure uniqueness of (potentially user set) extension list
+Set omitChecksumsForExtensions = Arrays.stream(
ConfigUtils.getString(
+session, DEFAULT_OMIT_CHECKSUMS_FOR_EXTENSIONS,
CONFIG_PROP_OMIT_CHECKSUMS_FOR_EXTENSIONS )
+.split( "," )
+).filter( s -> s != null && !s.trim().isEmpty() ).collect(
Collectors.toSet() );
+
+return new ExtensionArtifactChecksumFilter( omitChecksumsForExtensions
);
+}
+
+private static class ExtensionArtifactChecksumFilter
+implements ArtifactChecksumFilter
+{
+private final Set extensionsWithoutChecksums;
+
+private ExtensionArtifactChecksumFilter( Set
extensionsWithoutChecksums )
+{
+this.extensionsWithoutChecksums = requireNonNull(
extensionsWithoutChecksums );
+}
+
+@Override
+public boolean omitChecksumsFor( Artifact artifact )
+{
+String artifactExtension = artifact.getExtension(); // ie. pom.asc
+for ( String extensionWithoutChecksums :
extensionsWithoutChecksums )
+{
+if ( artifactExtension.endsWith( extensionWithoutChecksums ) )
Review comment:
See doco and default value: `.asc`, period is there. But right, if I
introduce new packaging type "foo" (so extension is ".foo"), I'd be unable to
make it filtered out...
--
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.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [maven-resolver] michael-o commented on a change in pull request #154: [MRESOLVER-241] Resolver checksum calculation should be driven by layout
michael-o commented on a change in pull request #154:
URL: https://github.com/apache/maven-resolver/pull/154#discussion_r825357666
##
File path:
maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/Maven2RepositoryLayoutFactory.java
##
@@ -225,32 +239,9 @@ public URI getLocation( Metadata metadata, boolean upload )
return checksumLocations;
}
-}
-
-private static class Maven2RepositoryLayoutEx
-extends Maven2RepositoryLayout
-{
-
-protected Maven2RepositoryLayoutEx( List
checksumAlgorithms )
+private boolean isChecksum( String extension )
{
-super( checksumAlgorithms );
+return checksumAlgorithms.stream().anyMatch( a ->
extension.endsWith( "." + a.getFileExtension() ) );
Review comment:
True, the `a` provides only `md5`, etc. and as you noticed it is
`XXX.md5`. This makes sense.
--
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.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [maven-resolver] michael-o commented on a change in pull request #154: [MRESOLVER-241] Resolver checksum calculation should be driven by layout
michael-o commented on a change in pull request #154:
URL: https://github.com/apache/maven-resolver/pull/154#discussion_r825357467
##
File path:
maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/checksum/DefaultArtifactChecksumFilterFactory.java
##
@@ -0,0 +1,90 @@
+package org.eclipse.aether.internal.impl.checksum;
+
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+
+import javax.inject.Named;
+import javax.inject.Singleton;
+
+import java.util.Arrays;
+import java.util.Set;
+import java.util.stream.Collectors;
+
+import org.eclipse.aether.RepositorySystemSession;
+import org.eclipse.aether.artifact.Artifact;
+import org.eclipse.aether.repository.RemoteRepository;
+import org.eclipse.aether.spi.connector.checksum.ArtifactChecksumFilter;
+import org.eclipse.aether.spi.connector.checksum.ArtifactChecksumFilterFactory;
+import org.eclipse.aether.util.ConfigUtils;
+
+import static java.util.Objects.requireNonNull;
+
+/**
+ * Default implementation that implements default resolver strategy: filters
by known (user configured) extensions,
+ * or by default only for GPG signature.
+ *
+ * @since 1.8.0
+ */
+@Singleton
+@Named
+public class DefaultArtifactChecksumFilterFactory
+implements ArtifactChecksumFilterFactory
+{
+public static final String CONFIG_PROP_OMIT_CHECKSUMS_FOR_EXTENSIONS =
+"aether.checksums.omitChecksumsForExtensions";
+
+private static final String DEFAULT_OMIT_CHECKSUMS_FOR_EXTENSIONS = ".asc";
Review comment:
Since you have have basically replaced the old property I would strive
for a cleanup and consistency with `#getExtension()`.
--
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.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [maven-resolver] cstamas commented on a change in pull request #154: [MRESOLVER-241] Resolver checksum calculation should be driven by layout
cstamas commented on a change in pull request #154:
URL: https://github.com/apache/maven-resolver/pull/154#discussion_r825357214
##
File path:
maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/checksum/DefaultArtifactChecksumFilterFactory.java
##
@@ -0,0 +1,90 @@
+package org.eclipse.aether.internal.impl.checksum;
+
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+
+import javax.inject.Named;
+import javax.inject.Singleton;
+
+import java.util.Arrays;
+import java.util.Set;
+import java.util.stream.Collectors;
+
+import org.eclipse.aether.RepositorySystemSession;
+import org.eclipse.aether.artifact.Artifact;
+import org.eclipse.aether.repository.RemoteRepository;
+import org.eclipse.aether.spi.connector.checksum.ArtifactChecksumFilter;
+import org.eclipse.aether.spi.connector.checksum.ArtifactChecksumFilterFactory;
+import org.eclipse.aether.util.ConfigUtils;
+
+import static java.util.Objects.requireNonNull;
+
+/**
+ * Default implementation that implements default resolver strategy: filters
by known (user configured) extensions,
+ * or by default only for GPG signature.
+ *
+ * @since 1.8.0
+ */
+@Singleton
+@Named
+public class DefaultArtifactChecksumFilterFactory
+implements ArtifactChecksumFilterFactory
+{
+public static final String CONFIG_PROP_OMIT_CHECKSUMS_FOR_EXTENSIONS =
+"aether.checksums.omitChecksumsForExtensions";
+
+private static final String DEFAULT_OMIT_CHECKSUMS_FOR_EXTENSIONS = ".asc";
Review comment:
The signature artifact.getExtension returns "jar.asc", and we used
`endsWith(.asc)` for same reason. Basically I did not change what happens in
old code, just shuffled it around.
--
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.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [maven-resolver] cstamas commented on a change in pull request #154: [MRESOLVER-241] Resolver checksum calculation should be driven by layout
cstamas commented on a change in pull request #154:
URL: https://github.com/apache/maven-resolver/pull/154#discussion_r825357135
##
File path:
maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/Maven2RepositoryLayoutFactory.java
##
@@ -206,6 +216,10 @@ public URI getLocation( Metadata metadata, boolean upload )
@Override
public List getChecksumLocations( Artifact artifact,
boolean upload, URI location )
{
+if ( artifactChecksumFilter.omitChecksumsFor( artifact ) ||
isChecksum( artifact.getExtension() ) )
Review comment:
artifact.getExtension returns values like "pom", "pom.sha1", "pom.asc"
etc
--
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.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [maven-resolver] michael-o commented on a change in pull request #154: [MRESOLVER-241] Resolver checksum calculation should be driven by layout
michael-o commented on a change in pull request #154:
URL: https://github.com/apache/maven-resolver/pull/154#discussion_r825356991
##
File path:
maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/checksum/DefaultArtifactChecksumFilterFactory.java
##
@@ -0,0 +1,90 @@
+package org.eclipse.aether.internal.impl.checksum;
+
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+
+import javax.inject.Named;
+import javax.inject.Singleton;
+
+import java.util.Arrays;
+import java.util.Set;
+import java.util.stream.Collectors;
+
+import org.eclipse.aether.RepositorySystemSession;
+import org.eclipse.aether.artifact.Artifact;
+import org.eclipse.aether.repository.RemoteRepository;
+import org.eclipse.aether.spi.connector.checksum.ArtifactChecksumFilter;
+import org.eclipse.aether.spi.connector.checksum.ArtifactChecksumFilterFactory;
+import org.eclipse.aether.util.ConfigUtils;
+
+import static java.util.Objects.requireNonNull;
+
+/**
+ * Default implementation that implements default resolver strategy: filters
by known (user configured) extensions,
+ * or by default only for GPG signature.
+ *
+ * @since 1.8.0
+ */
+@Singleton
+@Named
+public class DefaultArtifactChecksumFilterFactory
+implements ArtifactChecksumFilterFactory
+{
+public static final String CONFIG_PROP_OMIT_CHECKSUMS_FOR_EXTENSIONS =
+"aether.checksums.omitChecksumsForExtensions";
+
+private static final String DEFAULT_OMIT_CHECKSUMS_FOR_EXTENSIONS = ".asc";
+
+@Override
+public ArtifactChecksumFilter newInstance( RepositorySystemSession
session, RemoteRepository repository )
+{
+// ensure uniqueness of (potentially user set) extension list
+Set omitChecksumsForExtensions = Arrays.stream(
ConfigUtils.getString(
+session, DEFAULT_OMIT_CHECKSUMS_FOR_EXTENSIONS,
CONFIG_PROP_OMIT_CHECKSUMS_FOR_EXTENSIONS )
+.split( "," )
+).filter( s -> s != null && !s.trim().isEmpty() ).collect(
Collectors.toSet() );
+
+return new ExtensionArtifactChecksumFilter( omitChecksumsForExtensions
);
+}
+
+private static class ExtensionArtifactChecksumFilter
+implements ArtifactChecksumFilter
+{
+private final Set extensionsWithoutChecksums;
+
+private ExtensionArtifactChecksumFilter( Set
extensionsWithoutChecksums )
+{
+this.extensionsWithoutChecksums = requireNonNull(
extensionsWithoutChecksums );
+}
+
+@Override
+public boolean omitChecksumsFor( Artifact artifact )
+{
+String artifactExtension = artifact.getExtension(); // ie. pom.asc
+for ( String extensionWithoutChecksums :
extensionsWithoutChecksums )
+{
+if ( artifactExtension.endsWith( extensionWithoutChecksums ) )
Review comment:
The period should be added for testing here
##
File path:
maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/Maven2RepositoryLayoutFactory.java
##
@@ -206,6 +216,10 @@ public URI getLocation( Metadata metadata, boolean upload )
@Override
public List getChecksumLocations( Artifact artifact,
boolean upload, URI location )
{
+if ( artifactChecksumFilter.omitChecksumsFor( artifact ) ||
isChecksum( artifact.getExtension() ) )
Review comment:
Does this `getExtension()` really contain a dot?
##
File path:
maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/checksum/DefaultArtifactChecksumFilterFactory.java
##
@@ -0,0 +1,90 @@
+package org.eclipse.aether.internal.impl.checksum;
+
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ *
[GitHub] [maven-resolver] cstamas commented on a change in pull request #154: [MRESOLVER-241] Resolver checksum calculation should be driven by layout
cstamas commented on a change in pull request #154:
URL: https://github.com/apache/maven-resolver/pull/154#discussion_r825356843
##
File path:
maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/Maven2RepositoryLayoutFactory.java
##
@@ -225,32 +239,9 @@ public URI getLocation( Metadata metadata, boolean upload )
return checksumLocations;
}
-}
-
-private static class Maven2RepositoryLayoutEx
-extends Maven2RepositoryLayout
-{
-
-protected Maven2RepositoryLayoutEx( List
checksumAlgorithms )
+private boolean isChecksum( String extension )
{
-super( checksumAlgorithms );
+return checksumAlgorithms.stream().anyMatch( a ->
extension.endsWith( "." + a.getFileExtension() ) );
Review comment:
as extension of POM ~signature~ hash is ~`pom.asc`~ `pom.sha1`, also if
you look at old code, it was doing same thing for same reason.
--
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.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [maven-resolver] cstamas commented on a change in pull request #154: [MRESOLVER-241] Resolver checksum calculation should be driven by layout
cstamas commented on a change in pull request #154:
URL: https://github.com/apache/maven-resolver/pull/154#discussion_r825356843
##
File path:
maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/Maven2RepositoryLayoutFactory.java
##
@@ -225,32 +239,9 @@ public URI getLocation( Metadata metadata, boolean upload )
return checksumLocations;
}
-}
-
-private static class Maven2RepositoryLayoutEx
-extends Maven2RepositoryLayout
-{
-
-protected Maven2RepositoryLayoutEx( List
checksumAlgorithms )
+private boolean isChecksum( String extension )
{
-super( checksumAlgorithms );
+return checksumAlgorithms.stream().anyMatch( a ->
extension.endsWith( "." + a.getFileExtension() ) );
Review comment:
as extension of POM signature is `pom.asc`, also if you look at old
code, it was doing same thing for same reason.
--
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.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [maven-resolver] michael-o commented on a change in pull request #154: [MRESOLVER-241] Resolver checksum calculation should be driven by layout
michael-o commented on a change in pull request #154:
URL: https://github.com/apache/maven-resolver/pull/154#discussion_r825355964
##
File path:
maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/Maven2RepositoryLayoutFactory.java
##
@@ -225,32 +239,9 @@ public URI getLocation( Metadata metadata, boolean upload )
return checksumLocations;
}
-}
-
-private static class Maven2RepositoryLayoutEx
-extends Maven2RepositoryLayout
-{
-
-protected Maven2RepositoryLayoutEx( List
checksumAlgorithms )
+private boolean isChecksum( String extension )
{
-super( checksumAlgorithms );
+return checksumAlgorithms.stream().anyMatch( a ->
extension.endsWith( "." + a.getFileExtension() ) );
Review comment:
Why `endsWith()` and not `equals()`?
--
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.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Commented] (MRESOLVER-242) When no remote checksums provided by layout, transfer inevitably fails/warns
[
https://issues.apache.org/jira/browse/MRESOLVER-242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17505363#comment-17505363
]
Michael Osipov commented on MRESOLVER-242:
--
This makes logically sense.
> When no remote checksums provided by layout, transfer inevitably fails/warns
>
>
> Key: MRESOLVER-242
> URL: https://issues.apache.org/jira/browse/MRESOLVER-242
> Project: Maven Resolver
> Issue Type: Bug
>Reporter: Tamás Cservenák
>Assignee: Tamás Cservenák
>Priority: Major
> Fix For: 1.8.0
>
>
> On remote transfer, if layout does not provide remote checksums (as Javadoc
> states: it MAY return empty collection), remote transfer either WARNs or
> fails (if repository policy is WARN of FAIL respectively) always. This is
> wrong IMHO.
> OTOH, layout intentionally does not return remote checksums in some cases,
> like GPG signature is, if the default Maven2RepositoryLayoutEx is used.
> Hence, this causes that (sub)artifacts like checksums and signatures are NOT
> resolvable using resolver, due that above (they are deemed to always fail).
> Hence, a proposed solution is:
> * change of semantics: when layout does not provide remote checksums, skip
> checksum validation of remote checksums (as there is no such thing as
> "checksum of a checksum" or in many cases "checksum of a signature").
> * make resolver layout extensible re "artifacts with omitted checksums"
> instead to have baked in only one extension: {{.asc}}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (MRELEASE-899) release:prepare should not change the line separator but detect effective line separator from pom.xml
[
https://issues.apache.org/jira/browse/MRELEASE-899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17505361#comment-17505361
]
Hudson commented on MRELEASE-899:
-
Build succeeded in Jenkins: Maven » Maven TLP » maven-release » master #4
See
https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven-release/job/master/4/
> release:prepare should not change the line separator but detect effective
> line separator from pom.xml
> -
>
> Key: MRELEASE-899
> URL: https://issues.apache.org/jira/browse/MRELEASE-899
> Project: Maven Release Plugin
> Issue Type: New Feature
>Reporter: Ralph van Etten
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.0.0-M6
>
>
> Currently the plugin use the system property {{line.separator}} when it
> rewrites the pom.xml.
> This causes trouble, because every line in changed, when a project is
> released sometimes under Windows and sometimes under Linux (because of its
> different line separators).
> (http://stackoverflow.com/questions/11868590/maven-release-plugin-and-windows-line-breaks)
> Therefore it would be a nice feature when the plugin would not use the
> systems line separator but the line separator that is already used in the
> pom.xml.
> On the other hand, changing the existing behaviour would maybe, also harm
> someone else.
> Therefore it would be an great feature when there would be an property that
> define the expected behaviour, maybe in the same way it is done by the
> maven-assembly-plugin's property fileSet.lineEnding
> (http://maven.apache.org/plugins/maven-assembly-plugin/component.html#class_fileSet)
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [maven-jxr] slawekjaranowski merged pull request #46: Bump plexus-java from 1.1.0 to 1.1.1
slawekjaranowski merged pull request #46: URL: https://github.com/apache/maven-jxr/pull/46 -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-release] asfgit closed pull request #62: [MRELEASE-899] Feature/lineseparator
asfgit closed pull request #62: URL: https://github.com/apache/maven-release/pull/62 -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Closed] (MRELEASE-899) release:prepare should not change the line separator but detect effective line separator from pom.xml
[
https://issues.apache.org/jira/browse/MRELEASE-899?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed MRELEASE-899.
---
Resolution: Fixed
Fixed with
[93920737d07f9ab3eccb23a720f3f39789c3edb1|https://gitbox.apache.org/repos/asf?p=maven-release.git;a=commit;h=93920737d07f9ab3eccb23a720f3f39789c3edb1].
> release:prepare should not change the line separator but detect effective
> line separator from pom.xml
> -
>
> Key: MRELEASE-899
> URL: https://issues.apache.org/jira/browse/MRELEASE-899
> Project: Maven Release Plugin
> Issue Type: New Feature
>Reporter: Ralph van Etten
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.0.0-M6
>
>
> Currently the plugin use the system property {{line.separator}} when it
> rewrites the pom.xml.
> This causes trouble, because every line in changed, when a project is
> released sometimes under Windows and sometimes under Linux (because of its
> different line separators).
> (http://stackoverflow.com/questions/11868590/maven-release-plugin-and-windows-line-breaks)
> Therefore it would be a nice feature when the plugin would not use the
> systems line separator but the line separator that is already used in the
> pom.xml.
> On the other hand, changing the existing behaviour would maybe, also harm
> someone else.
> Therefore it would be an great feature when there would be an property that
> define the expected behaviour, maybe in the same way it is done by the
> maven-assembly-plugin's property fileSet.lineEnding
> (http://maven.apache.org/plugins/maven-assembly-plugin/component.html#class_fileSet)
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Comment Edited] (MRELEASE-899) release:prepare should not change the line separator but detect effective line separator from pom.xml
[
https://issues.apache.org/jira/browse/MRELEASE-899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17505360#comment-17505360
]
Michael Osipov edited comment on MRELEASE-899 at 3/12/22, 9:19 PM:
---
Fixed with
[8675bebad3342b0b2d4573e3e337a39225d110cf|https://gitbox.apache.org/repos/asf?p=maven-release.git;a=commit;h=8675bebad3342b0b2d4573e3e337a39225d110cf].
was (Author: michael-o):
Fixed with
[93920737d07f9ab3eccb23a720f3f39789c3edb1|https://gitbox.apache.org/repos/asf?p=maven-release.git;a=commit;h=93920737d07f9ab3eccb23a720f3f39789c3edb1].
> release:prepare should not change the line separator but detect effective
> line separator from pom.xml
> -
>
> Key: MRELEASE-899
> URL: https://issues.apache.org/jira/browse/MRELEASE-899
> Project: Maven Release Plugin
> Issue Type: New Feature
>Reporter: Ralph van Etten
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.0.0-M6
>
>
> Currently the plugin use the system property {{line.separator}} when it
> rewrites the pom.xml.
> This causes trouble, because every line in changed, when a project is
> released sometimes under Windows and sometimes under Linux (because of its
> different line separators).
> (http://stackoverflow.com/questions/11868590/maven-release-plugin-and-windows-line-breaks)
> Therefore it would be a nice feature when the plugin would not use the
> systems line separator but the line separator that is already used in the
> pom.xml.
> On the other hand, changing the existing behaviour would maybe, also harm
> someone else.
> Therefore it would be an great feature when there would be an property that
> define the expected behaviour, maybe in the same way it is done by the
> maven-assembly-plugin's property fileSet.lineEnding
> (http://maven.apache.org/plugins/maven-assembly-plugin/component.html#class_fileSet)
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (JXR-168) Dependency upgrade and cleanup
[ https://issues.apache.org/jira/browse/JXR-168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Slawomir Jaranowski updated JXR-168: Description: - plexus-utils from 3.3.0 to 3.4.1 - plexus-java from 1.1.0 to 1.1.1 > Dependency upgrade and cleanup > -- > > Key: JXR-168 > URL: https://issues.apache.org/jira/browse/JXR-168 > Project: Maven JXR > Issue Type: Dependency upgrade >Reporter: Slawomir Jaranowski >Assignee: Slawomir Jaranowski >Priority: Major > Fix For: 3.2.0 > > > - plexus-utils from 3.3.0 to 3.4.1 > - plexus-java from 1.1.0 to 1.1.1 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[GitHub] [maven-jxr] slawekjaranowski merged pull request #43: Bump plexus-utils from 3.3.0 to 3.4.1
slawekjaranowski merged pull request #43: URL: https://github.com/apache/maven-jxr/pull/43 -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Updated] (MRELEASE-899) release:prepare should not change the line separator but detect effective line separator from pom.xml
[
https://issues.apache.org/jira/browse/MRELEASE-899?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MRELEASE-899:
Issue Type: New Feature (was: Improvement)
> release:prepare should not change the line separator but detect effective
> line separator from pom.xml
> -
>
> Key: MRELEASE-899
> URL: https://issues.apache.org/jira/browse/MRELEASE-899
> Project: Maven Release Plugin
> Issue Type: New Feature
>Reporter: Ralph van Etten
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.0.0-M6
>
>
> Currently the plugin use the system property {{line.separator}} when it
> rewrites the pom.xml.
> This causes trouble, because every line in changed, when a project is
> released sometimes under Windows and sometimes under Linux (because of its
> different line separators).
> (http://stackoverflow.com/questions/11868590/maven-release-plugin-and-windows-line-breaks)
> Therefore it would be a nice feature when the plugin would not use the
> systems line separator but the line separator that is already used in the
> pom.xml.
> On the other hand, changing the existing behaviour would maybe, also harm
> someone else.
> Therefore it would be an great feature when there would be an property that
> define the expected behaviour, maybe in the same way it is done by the
> maven-assembly-plugin's property fileSet.lineEnding
> (http://maven.apache.org/plugins/maven-assembly-plugin/component.html#class_fileSet)
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [maven-release] michael-o merged pull request #102: Fix xsd NS
michael-o merged pull request #102: URL: https://github.com/apache/maven-release/pull/102 -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Updated] (MRELEASE-1080) Maven 3.8.4 exits with non-zero status from release:perform or :prepare even when successful
[ https://issues.apache.org/jira/browse/MRELEASE-1080?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MRELEASE-1080: - Summary: Maven 3.8.4 exits with non-zero status from release:perform or :prepare even when successful (was: Maven v3.8.4 exits with non-zero status from release:perform or :prepare even when successful) > Maven 3.8.4 exits with non-zero status from release:perform or :prepare even > when successful > > > Key: MRELEASE-1080 > URL: https://issues.apache.org/jira/browse/MRELEASE-1080 > Project: Maven Release Plugin > Issue Type: Bug > Components: perform, prepare >Affects Versions: 3.0.0-M5 > Environment: Windows 10, Git for Windows Bourne Again Shell, Maven > 3.8.4 >Reporter: Mirko Klemm >Priority: Major > Labels: exit, shell > Fix For: waiting-for-feedback > > > When doing a "release:prepare" or "release:perform", the maven process always > exits with a shell exit status of 1, even when the goal has finished with a > "BUILD SUCCESS" message, where it actually should return 0. > This doesn't seem to have been the case with 2.x versions of the plugin. > This is an important bug since it messes up using maven and the release > plugin in shell scripts. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (JXR-164) Full path to local code sources in page title
[ https://issues.apache.org/jira/browse/JXR-164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Slawomir Jaranowski updated JXR-164: Priority: Critical (was: Major) > Full path to local code sources in page title > - > > Key: JXR-164 > URL: https://issues.apache.org/jira/browse/JXR-164 > Project: Maven JXR > Issue Type: Bug >Reporter: Slawomir Jaranowski >Assignee: Slawomir Jaranowski >Priority: Critical > Fix For: 3.2.0 > > > If class name can not be discovered full path to local code sources is placed > in page title. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (JXR-168) Dependency upgrade and cleanup
Slawomir Jaranowski created JXR-168: --- Summary: Dependency upgrade and cleanup Key: JXR-168 URL: https://issues.apache.org/jira/browse/JXR-168 Project: Maven JXR Issue Type: Dependency upgrade Reporter: Slawomir Jaranowski Assignee: Slawomir Jaranowski Fix For: 3.2.0 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[GitHub] [maven-gh-actions-shared] slawekjaranowski merged pull request #39: Bump release-drafter/release-drafter from 5.18.1 to 5.19.0
slawekjaranowski merged pull request #39: URL: https://github.com/apache/maven-gh-actions-shared/pull/39 -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-gh-actions-shared] slawekjaranowski opened a new pull request #40: Stage site output
slawekjaranowski opened a new pull request #40: URL: https://github.com/apache/maven-gh-actions-shared/pull/40 Improvement for multi module projects -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven] michael-o commented on pull request #690: [MNG-7429] The classloader containing build extension should be used throughout the build
michael-o commented on pull request #690: URL: https://github.com/apache/maven/pull/690#issuecomment-1065924294 > @michael-o maybe you want to take over here or suggest others more familiar with how maven is supposed to work here. Honestly, you both are much deeper in this issue, I very little clue about CL hierarchies. I will leave the decision upto to you both. -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Closed] (JXR-167) Upgrade Parent to 35
[ https://issues.apache.org/jira/browse/JXR-167?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Slawomir Jaranowski closed JXR-167. --- Assignee: Slawomir Jaranowski Resolution: Fixed > Upgrade Parent to 35 > > > Key: JXR-167 > URL: https://issues.apache.org/jira/browse/JXR-167 > Project: Maven JXR > Issue Type: Dependency upgrade >Reporter: Slawomir Jaranowski >Assignee: Slawomir Jaranowski >Priority: Major > Fix For: 3.2.0 > > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[GitHub] [maven-jxr] dependabot[bot] commented on pull request #50: Bump maven-project-info-reports-plugin from 3.1.2 to 3.2.2
dependabot[bot] commented on pull request #50: URL: https://github.com/apache/maven-jxr/pull/50#issuecomment-1065921873 Looks like org.apache.maven.plugins:maven-project-info-reports-plugin is no longer a dependency, so this is no longer 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-jxr] dependabot[bot] closed pull request #50: Bump maven-project-info-reports-plugin from 3.1.2 to 3.2.2
dependabot[bot] closed pull request #50: URL: https://github.com/apache/maven-jxr/pull/50 -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-jxr] slawekjaranowski merged pull request #53: [JXR-167] Upgrade Parent to 35
slawekjaranowski merged pull request #53: URL: https://github.com/apache/maven-jxr/pull/53 -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (SUREFIRE-2033) Regression: 3.0.0-M5 misidentifies JUnit 5 configuration as JUnit 4
[
https://issues.apache.org/jira/browse/SUREFIRE-2033?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17505304#comment-17505304
]
Slawomir Jaranowski commented on SUREFIRE-2033:
---
Surefire code for detecting providers is too complicated for my. IMHO Surefire
should only detect simple cases .. when we want to make happy everyone and
cover all cases we will have such issue everytime and for every new release
So we should have good and clear documentation for automatic providers
detection with instruction how to solve special corner cases by configuration.
> Regression: 3.0.0-M5 misidentifies JUnit 5 configuration as JUnit 4
> ---
>
> Key: SUREFIRE-2033
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2033
> Project: Maven Surefire
> Issue Type: Bug
> Components: JUnit 5.x support
>Affects Versions: 3.0.0-M5
>Reporter: Robert James Oxspring
>Priority: Major
> Attachments: example.zip
>
>
> 3.0.0-M5 misidentifies a clearly JUnit 5 configuration and attempts to run
> using JUnit 4.
> In particular the attached project only has JUnit 5 dependencies:
> {code:java}
>
>
> org.junit.jupiter
> junit-jupiter-engine
> 5.6.2
> test
>
>
> org.junit.platform
> junit-platform-runner
> 1.6.2
> test
>
> {code}
> and a JUnit 5 test:
> {code:java}
> package pkg;
> import org.junit.jupiter.api.Test;
> class JUnit5Test {
> @Test
> public void test() {
> }
> }{code}
> When the project is run with with older version (as far back as 2.22.0) the
> test is found and run, but 3.0.0-M5 fails to run any test:
> {code:java}
> % mvn test -Dsurefire.version=2.22.0 | tail
> [INFO] Results:
> [INFO]
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
> [INFO]
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> [INFO] Total time: 1.337 s
> [INFO] Finished at: 2022-03-03T09:42:27Z
> [INFO]
>
> {code}
>
> {code:java}
> % mvn test -Dsurefire.version=3.0.0-M1 | tail
> [INFO] Results:
> [INFO]
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
> [INFO]
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> [INFO] Total time: 1.708 s
> [INFO] Finished at: 2022-03-03T09:34:58Z
> [INFO]
>
> % mvn test -Dsurefire.version=3.0.0-M2 | tail
> [INFO] Results:
> [INFO]
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
> [INFO]
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> [INFO] Total time: 1.701 s
> [INFO] Finished at: 2022-03-03T09:36:26Z
> [INFO]
>
> % mvn test -Dsurefire.version=3.0.0-M3 | tail
> [INFO] Results:
> [INFO]
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
> [INFO]
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> [INFO] Total time: 1.612 s
> [INFO] Finished at: 2022-03-03T09:37:02Z
> [INFO]
>
> % mvn test -Dsurefire.version=3.0.0-M4 | tail
> [INFO] Results:
> [INFO]
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
> [INFO]
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> [INFO] Total time: 1.619 s
> [INFO] Finished at: 2022-03-03T09:37:37Z
> [INFO]
>
> % mvn test -Dsurefire.version=3.0.0-M5 | tail
> [INFO] Results:
> [INFO]
> [INFO] Tests run: 0, Failures: 0, Errors: 0, Skipped: 0
> [INFO]
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> [INFO] Total time: 1.344 s
> [INFO] Finished at: 2022-03-03T09:38:01Z
> [INFO]
> {code}
> Note the final run above using 3.0.0-M5 and logging: {{Tests run: 0}}
--
This message was sent by Atlassian Jira
[jira] (SUREFIRE-2033) Regression: 3.0.0-M5 misidentifies JUnit 5 configuration as JUnit 4
[ https://issues.apache.org/jira/browse/SUREFIRE-2033 ]
Dan Tran deleted comment on SUREFIRE-2033:
was (Author: dantran):
I do agree with [~roxspring] this is a regression compared with M4. with M6, i
now have to manually add provider ( in my case testing, junit4, junit5) to
surefire plugin's dependencies
In M4 it works out of the box [1]
https://maven.apache.org/surefire/maven-surefire-plugin/examples/providers.html
> Regression: 3.0.0-M5 misidentifies JUnit 5 configuration as JUnit 4
> ---
>
> Key: SUREFIRE-2033
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2033
> Project: Maven Surefire
> Issue Type: Bug
> Components: JUnit 5.x support
>Affects Versions: 3.0.0-M5
>Reporter: Robert James Oxspring
>Priority: Major
> Attachments: example.zip
>
>
> 3.0.0-M5 misidentifies a clearly JUnit 5 configuration and attempts to run
> using JUnit 4.
> In particular the attached project only has JUnit 5 dependencies:
> {code:java}
>
>
> org.junit.jupiter
> junit-jupiter-engine
> 5.6.2
> test
>
>
> org.junit.platform
> junit-platform-runner
> 1.6.2
> test
>
> {code}
> and a JUnit 5 test:
> {code:java}
> package pkg;
> import org.junit.jupiter.api.Test;
> class JUnit5Test {
> @Test
> public void test() {
> }
> }{code}
> When the project is run with with older version (as far back as 2.22.0) the
> test is found and run, but 3.0.0-M5 fails to run any test:
> {code:java}
> % mvn test -Dsurefire.version=2.22.0 | tail
> [INFO] Results:
> [INFO]
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
> [INFO]
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> [INFO] Total time: 1.337 s
> [INFO] Finished at: 2022-03-03T09:42:27Z
> [INFO]
>
> {code}
>
> {code:java}
> % mvn test -Dsurefire.version=3.0.0-M1 | tail
> [INFO] Results:
> [INFO]
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
> [INFO]
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> [INFO] Total time: 1.708 s
> [INFO] Finished at: 2022-03-03T09:34:58Z
> [INFO]
>
> % mvn test -Dsurefire.version=3.0.0-M2 | tail
> [INFO] Results:
> [INFO]
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
> [INFO]
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> [INFO] Total time: 1.701 s
> [INFO] Finished at: 2022-03-03T09:36:26Z
> [INFO]
>
> % mvn test -Dsurefire.version=3.0.0-M3 | tail
> [INFO] Results:
> [INFO]
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
> [INFO]
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> [INFO] Total time: 1.612 s
> [INFO] Finished at: 2022-03-03T09:37:02Z
> [INFO]
>
> % mvn test -Dsurefire.version=3.0.0-M4 | tail
> [INFO] Results:
> [INFO]
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
> [INFO]
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> [INFO] Total time: 1.619 s
> [INFO] Finished at: 2022-03-03T09:37:37Z
> [INFO]
>
> % mvn test -Dsurefire.version=3.0.0-M5 | tail
> [INFO] Results:
> [INFO]
> [INFO] Tests run: 0, Failures: 0, Errors: 0, Skipped: 0
> [INFO]
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> [INFO] Total time: 1.344 s
> [INFO] Finished at: 2022-03-03T09:38:01Z
> [INFO]
> {code}
> Note the final run above using 3.0.0-M5 and logging: {{Tests run: 0}}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (SUREFIRE-2033) Regression: 3.0.0-M5 misidentifies JUnit 5 configuration as JUnit 4
[
https://issues.apache.org/jira/browse/SUREFIRE-2033?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17505302#comment-17505302
]
Dan Tran commented on SUREFIRE-2033:
I do agree with [~roxspring] this is a regression compared with M4. with M6, i
now have to manually add provider ( in my case testing, junit4, junit5) to
surefire plugin's dependencies
In M4 it works out of the box [1]
https://maven.apache.org/surefire/maven-surefire-plugin/examples/providers.html
> Regression: 3.0.0-M5 misidentifies JUnit 5 configuration as JUnit 4
> ---
>
> Key: SUREFIRE-2033
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2033
> Project: Maven Surefire
> Issue Type: Bug
> Components: JUnit 5.x support
>Affects Versions: 3.0.0-M5
>Reporter: Robert James Oxspring
>Priority: Major
> Attachments: example.zip
>
>
> 3.0.0-M5 misidentifies a clearly JUnit 5 configuration and attempts to run
> using JUnit 4.
> In particular the attached project only has JUnit 5 dependencies:
> {code:java}
>
>
> org.junit.jupiter
> junit-jupiter-engine
> 5.6.2
> test
>
>
> org.junit.platform
> junit-platform-runner
> 1.6.2
> test
>
> {code}
> and a JUnit 5 test:
> {code:java}
> package pkg;
> import org.junit.jupiter.api.Test;
> class JUnit5Test {
> @Test
> public void test() {
> }
> }{code}
> When the project is run with with older version (as far back as 2.22.0) the
> test is found and run, but 3.0.0-M5 fails to run any test:
> {code:java}
> % mvn test -Dsurefire.version=2.22.0 | tail
> [INFO] Results:
> [INFO]
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
> [INFO]
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> [INFO] Total time: 1.337 s
> [INFO] Finished at: 2022-03-03T09:42:27Z
> [INFO]
>
> {code}
>
> {code:java}
> % mvn test -Dsurefire.version=3.0.0-M1 | tail
> [INFO] Results:
> [INFO]
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
> [INFO]
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> [INFO] Total time: 1.708 s
> [INFO] Finished at: 2022-03-03T09:34:58Z
> [INFO]
>
> % mvn test -Dsurefire.version=3.0.0-M2 | tail
> [INFO] Results:
> [INFO]
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
> [INFO]
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> [INFO] Total time: 1.701 s
> [INFO] Finished at: 2022-03-03T09:36:26Z
> [INFO]
>
> % mvn test -Dsurefire.version=3.0.0-M3 | tail
> [INFO] Results:
> [INFO]
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
> [INFO]
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> [INFO] Total time: 1.612 s
> [INFO] Finished at: 2022-03-03T09:37:02Z
> [INFO]
>
> % mvn test -Dsurefire.version=3.0.0-M4 | tail
> [INFO] Results:
> [INFO]
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
> [INFO]
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> [INFO] Total time: 1.619 s
> [INFO] Finished at: 2022-03-03T09:37:37Z
> [INFO]
>
> % mvn test -Dsurefire.version=3.0.0-M5 | tail
> [INFO] Results:
> [INFO]
> [INFO] Tests run: 0, Failures: 0, Errors: 0, Skipped: 0
> [INFO]
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> [INFO] Total time: 1.344 s
> [INFO] Finished at: 2022-03-03T09:38:01Z
> [INFO]
> {code}
> Note the final run above using 3.0.0-M5 and logging: {{Tests run: 0}}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [maven-jxr] slawekjaranowski opened a new pull request #53: [JXR-167] Upgrade Parent to 35
slawekjaranowski opened a new pull request #53: URL: https://github.com/apache/maven-jxr/pull/53 Following this checklist to help us incorporate your contribution quickly and easily: - [x] Make sure there is a [JIRA issue](https://issues.apache.org/jira/browse/JXR) 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. - [x] Format the pull request title like `[JXR-XXX] - Fixes bug in ApproximateQuantiles`, where you replace `JXR-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. - [x] Run `mvn clean verify` to make sure basic checks pass. A more thorough check will be performed on your pull request automatically. - [x] You have run the integration tests successfully (`mvn -Prun-its clean verify`). 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. - [x] 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) - [x] In any other case, please file an [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf). -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven] gnodet commented on pull request #690: [MNG-7429] The classloader containing build extension should be used throughout the build
gnodet commented on pull request #690: URL: https://github.com/apache/maven/pull/690#issuecomment-1065909731 > I'm not sure if I can give more input on this, but only quote this > > > it really depends on the use case > > `WorkspaceReader` and `AbstractMavenLifecycleParticipant` are special because they are a mean of bootstrap and/or add additional look-ups on a global level, but at the same time they are very limited and require special care, e.g. as noted above depending on how an `AbstractMavenLifecycleParticipant` is provided not all methods are called and `WorkspaceReader` for example has no access to any project or session context. Anyways I don't think one could assume that one _always_ wan't to lookup everything from all project extensions, similar to when I define a mirror in a pom.xml I for sure don't want it to be used in other (unrelated) modules just because they are part of the same reactor, if I want this then I define it on the settings.xml ... Well, I'd like to be sure about that. All the use cases I've seen so far rather indicate extensions are global to the build. The primary use case was for wagon providers afaik and those are global. Also given, they were currently mostly global (i.e. the extensions classloader is set until another project also define extensions), I'd rather assume users expects them to be global. I'd rather go for a behavior than suits most use cases so far (lifecycle, workspace readers, wagon providers, build cache), rather than changing the behavior and have to rely on specific hacks for each kind of extension, it kinda defeat the purpose. Do you have any actual use case of build extensions that should have a limited scope (which again, is not how they were working)... ? > > So for your case, if you really thing your extension should be defined on the project level, then for me it makes totally sense that this is only available in the projects where it is defined (either explicit or implicit e.g. though parent reference) and then your extension would not be looked up globally. If you want ti to act globally independent of defined in a project and you want to have much more control I think it should be a core-extension even if others not so involved in the details think "it might be useful" to define it on the project level. > > @michael-o maybe you want to take over here or suggest others more familiar with how maven is supposed to work here. -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Created] (JXR-167) Upgrade Parent to 35
Slawomir Jaranowski created JXR-167: --- Summary: Upgrade Parent to 35 Key: JXR-167 URL: https://issues.apache.org/jira/browse/JXR-167 Project: Maven JXR Issue Type: Dependency upgrade Reporter: Slawomir Jaranowski Fix For: 3.2.0 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[GitHub] [maven-verifier] slawekjaranowski commented on pull request #9: [MSHARED-1043] Deprecate methods leveraging JUnit4 assertions
slawekjaranowski commented on pull request #9: URL: https://github.com/apache/maven-verifier/pull/9#issuecomment-1065897499 @kwin - what with open conversations with @elharo -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-jxr] slawekjaranowski commented on pull request #43: Bump plexus-utils from 3.3.0 to 3.4.1
slawekjaranowski commented on pull request #43: URL: https://github.com/apache/maven-jxr/pull/43#issuecomment-1065894427 @dependabot rebase -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-jxr] slawekjaranowski commented on pull request #46: Bump plexus-java from 1.1.0 to 1.1.1
slawekjaranowski commented on pull request #46: URL: https://github.com/apache/maven-jxr/pull/46#issuecomment-1065894391 @dependabot rebase -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-verifier] slawekjaranowski commented on a change in pull request #9: [MSHARED-1043] Deprecate methods leveraging JUnit4 assertions
slawekjaranowski commented on a change in pull request #9:
URL: https://github.com/apache/maven-verifier/pull/9#discussion_r825309513
##
File path: src/main/java/org/apache/maven/it/Verifier.java
##
@@ -1768,6 +1869,30 @@ private static void runIntegrationTest( Verifier
verifier )
System.out.println( "OK" );
}
+/**
+ * Verifies that the artifact given by its Maven coordinates exists and
contains the given content.
+ *
+ * @param groupId the groupId of the artifact (must not be null)
+ * @param artifactId the artifactId of the artifact (must not be null)
+ * @param version the version of the artifact (must not be null)
+ * @param ext the extension of the artifact (must not be null)
+ * @param content the expected content
+ * @throws IOException in case reading from the artifact fails
+ * @throws VerificationException if the content of the artifact differs
+ */
+public void verifyArtifactContent( String groupId, String artifactId,
String version, String ext, String content )
+throws IOException, VerificationException
+{
+String fileName = getArtifactPath( groupId, artifactId, version, ext );
+if ( content.equals( FileUtils.fileRead( fileName ) ) )
+{
+throw new VerificationException( "Content of " + fileName + " does
not equal " + content );
+}
+}
+
+/**
+ * @deprecated Use {@link #verifyArtifactContent(String, String, String,
String, String)} instead.
+ */
Review comment:
missing deprecated annotation
--
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.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Commented] (MPOM-310) Replace Google Analytics with ASF Matomo in documentation
[ https://issues.apache.org/jira/browse/MPOM-310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17505280#comment-17505280 ] Benjamin Marwell commented on MPOM-310: --- No. This is the Maven POM. The Apache pom is a different project. > Replace Google Analytics with ASF Matomo in documentation > - > > Key: MPOM-310 > URL: https://issues.apache.org/jira/browse/MPOM-310 > Project: Maven POMs > Issue Type: Improvement > Components: asf >Affects Versions: ASF-25 >Reporter: Herve Boutemy >Assignee: Herve Boutemy >Priority: Major > Fix For: ASF-26 > > > ASF Parent POM documentation is published to Maven site: it need to follow > Maven's tracking practice that is changing with MPOM-300 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[GitHub] [maven-compiler-plugin] pzygielo commented on a change in pull request #101: [MCOMPILER-347] Set Xcludes in config passed to actual compiler
pzygielo commented on a change in pull request #101: URL: https://github.com/apache/maven-compiler-plugin/pull/101#discussion_r825296805 ## File path: src/main/java/org/apache/maven/plugin/compiler/CompilerMojo.java ## @@ -203,6 +203,18 @@ public void execute() } } +@Override +final Set getIncludes() Review comment: pattern followed -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-verifier] slawekjaranowski commented on pull request #11: [MSHARED-871] add basic documentation
slawekjaranowski commented on pull request #11: URL: https://github.com/apache/maven-verifier/pull/11#issuecomment-1065870381 pleas also add menu item under `OVERVIEW` section. -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-jenkins-lib] olamy merged pull request #5: notify only for master or main per default (no need to notify for every branches)
olamy merged pull request #5: URL: https://github.com/apache/maven-jenkins-lib/pull/5 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Updated] (MCOMPILER-347) Includes and excludes not passed into CompilerConfiguration
[
https://issues.apache.org/jira/browse/MCOMPILER-347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Olivier Lamy updated MCOMPILER-347:
---
Fix Version/s: 3.11.0
> Includes and excludes not passed into CompilerConfiguration
> ---
>
> Key: MCOMPILER-347
> URL: https://issues.apache.org/jira/browse/MCOMPILER-347
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.5
>Reporter: zhangchang
>Assignee: Olivier Lamy
>Priority: Major
> Fix For: 3.11.0
>
>
> Some groovy script is only for runtime excute, other source need compile for
> test.
> So I set exclude in maven-compiler-plugin tag, but it not work.
> {code:java}
>
> ...
>
>
> maven-compiler-plugin
> 3.5
>
> groovy-eclipse-compiler
>
> **/rest/*
>
>
>
>
> org.codehaus.groovy
> groovy-eclipse-compiler
> 2.9.2-01
>
>
> org.codehaus.groovy
> groovy-eclipse-batch
> 2.4.3-01
>
>
>
>
> ...
>
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Reopened] (MCOMPILER-347) Includes and excludes not passed into CompilerConfiguration
[
https://issues.apache.org/jira/browse/MCOMPILER-347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Olivier Lamy reopened MCOMPILER-347:
> Includes and excludes not passed into CompilerConfiguration
> ---
>
> Key: MCOMPILER-347
> URL: https://issues.apache.org/jira/browse/MCOMPILER-347
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.5
>Reporter: zhangchang
>Assignee: Olivier Lamy
>Priority: Major
>
> Some groovy script is only for runtime excute, other source need compile for
> test.
> So I set exclude in maven-compiler-plugin tag, but it not work.
> {code:java}
>
> ...
>
>
> maven-compiler-plugin
> 3.5
>
> groovy-eclipse-compiler
>
> **/rest/*
>
>
>
>
> org.codehaus.groovy
> groovy-eclipse-compiler
> 2.9.2-01
>
>
> org.codehaus.groovy
> groovy-eclipse-batch
> 2.4.3-01
>
>
>
>
> ...
>
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [maven-compiler-plugin] olamy commented on a change in pull request #101: [MCOMPILER-347] Set Xcludes in config passed to actual compiler
olamy commented on a change in pull request #101: URL: https://github.com/apache/maven-compiler-plugin/pull/101#discussion_r825289285 ## File path: src/main/java/org/apache/maven/plugin/compiler/CompilerMojo.java ## @@ -203,6 +203,18 @@ public void execute() } } +@Override +final Set getIncludes() Review comment: the usual pattern in the class is to make this open with `protected` and not `final` ## File path: src/main/java/org/apache/maven/plugin/compiler/TestCompilerMojo.java ## @@ -497,4 +497,16 @@ protected boolean isTestCompile() return true; } +@Override +final Set getIncludes() Review comment: same `protected` and not `final` -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MPOM-310) Replace Google Analytics with ASF Matomo in documentation
[ https://issues.apache.org/jira/browse/MPOM-310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17505257#comment-17505257 ] Slawomir Jaranowski commented on MPOM-310: -- [~hboutemy] , [~bmarwell] Do all children of ASF should have the same tracking id? > Replace Google Analytics with ASF Matomo in documentation > - > > Key: MPOM-310 > URL: https://issues.apache.org/jira/browse/MPOM-310 > Project: Maven POMs > Issue Type: Improvement > Components: asf >Affects Versions: ASF-25 >Reporter: Herve Boutemy >Assignee: Herve Boutemy >Priority: Major > Fix For: ASF-26 > > > ASF Parent POM documentation is published to Maven site: it need to follow > Maven's tracking practice that is changing with MPOM-300 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[GitHub] [maven-jenkins-lib] olamy commented on a change in pull request #5: notify only for master or main per default (no need to notify for every branches)
olamy commented on a change in pull request #5: URL: https://github.com/apache/maven-jenkins-lib/pull/5#discussion_r825289006 ## File path: README.adoc ## @@ -2,13 +2,32 @@ This repository contains the Jenkins shared libraries that define the standard build process for Apache Maven subprojects. -The shared libraries rely on a definition of the per-Jenkins instance specific configuration details. -The definition of those instance specific configuration details as customized for the Apache build server is hosted in https://gitbox.apache.org/repos/asf?p=maven-jenkins-env.git[maven-jenkins-env] +== asfMavenTlpStdBuild() (building Maven plugins) Review comment: oops bad copy/paste thanks! ## File path: README.adoc ## @@ -2,13 +2,32 @@ This repository contains the Jenkins shared libraries that define the standard build process for Apache Maven subprojects. -The shared libraries rely on a definition of the per-Jenkins instance specific configuration details. -The definition of those instance specific configuration details as customized for the Apache build server is hosted in https://gitbox.apache.org/repos/asf?p=maven-jenkins-env.git[maven-jenkins-env] +== asfMavenTlpStdBuild() (building Maven plugins) -If you want to build the Apache Maven repositories on your own Jenkins infrastructure you will need to define two shared libraries: + Accepted parameters: +- `os`: array of possible os to build projects (default: `['linux', 'windows']`) +- `jdks`: array of jdks used for the build (default: `['8','11','17']`) +- `mavens`: array of maven versions used for build (default: `['3.2.x','3.6.x', '3.8.x']`) +- `siteJdks`: array of jdks used for the site build (default: `[11']`) +- `siteMvn`: jdk used to build the site (default: `3.8.x`) +- `tmpWs`: boolean to shorten working directory on windows platform +- `branchesToNofify`: array of branches to send notifications of the build (default: `['master', 'main']`) -. The first shared library should be a clone of https://gitbox.apache.org/repos/asf?p=maven-jenkins-env.git[maven-jenkins-env.git] with the environment specifics modified to match your own Jenkins environment -. The second shared library should be this shared library which defines the standard Apache Maven build process +Example to use a specific set of jdks and maven core +``` +asfMavenTlpStdBuild(jdks:[ "8", "11" ], mavens: ["3.8.x"]) Review comment: oops bad copy/paste thanks! -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-jenkins-lib] slawekjaranowski commented on a change in pull request #5: notify only for master or main per default (no need to notify for every branches)
slawekjaranowski commented on a change in pull request #5: URL: https://github.com/apache/maven-jenkins-lib/pull/5#discussion_r825288028 ## File path: README.adoc ## @@ -2,13 +2,32 @@ This repository contains the Jenkins shared libraries that define the standard build process for Apache Maven subprojects. -The shared libraries rely on a definition of the per-Jenkins instance specific configuration details. -The definition of those instance specific configuration details as customized for the Apache build server is hosted in https://gitbox.apache.org/repos/asf?p=maven-jenkins-env.git[maven-jenkins-env] +== asfMavenTlpStdBuild() (building Maven plugins) -If you want to build the Apache Maven repositories on your own Jenkins infrastructure you will need to define two shared libraries: + Accepted parameters: +- `os`: array of possible os to build projects (default: `['linux', 'windows']`) +- `jdks`: array of jdks used for the build (default: `['8','11','17']`) +- `mavens`: array of maven versions used for build (default: `['3.2.x','3.6.x', '3.8.x']`) +- `siteJdks`: array of jdks used for the site build (default: `[11']`) +- `siteMvn`: jdk used to build the site (default: `3.8.x`) +- `tmpWs`: boolean to shorten working directory on windows platform +- `branchesToNofify`: array of branches to send notifications of the build (default: `['master', 'main']`) -. The first shared library should be a clone of https://gitbox.apache.org/repos/asf?p=maven-jenkins-env.git[maven-jenkins-env.git] with the environment specifics modified to match your own Jenkins environment -. The second shared library should be this shared library which defines the standard Apache Maven build process +Example to use a specific set of jdks and maven core +``` +asfMavenTlpStdBuild(jdks:[ "8", "11" ], mavens: ["3.8.x"]) Review comment: `asfMavenTlpPlgnBuild` ## File path: README.adoc ## @@ -2,13 +2,32 @@ This repository contains the Jenkins shared libraries that define the standard build process for Apache Maven subprojects. -The shared libraries rely on a definition of the per-Jenkins instance specific configuration details. -The definition of those instance specific configuration details as customized for the Apache build server is hosted in https://gitbox.apache.org/repos/asf?p=maven-jenkins-env.git[maven-jenkins-env] +== asfMavenTlpStdBuild() (building Maven plugins) Review comment: `asfMavenTlpPlgnBuild` -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Comment Edited] (MCOMPILER-347) Includes and excludes not passed into CompilerConfiguration
[
https://issues.apache.org/jira/browse/MCOMPILER-347?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17505234#comment-17505234
]
Václav Haisman edited comment on MCOMPILER-347 at 3/12/22, 10:37 AM:
-
[~olamy] This issue is that AbstractCompilerMojo does not seem to be passing
all of the compiler configuration into the compiler plugin. The linked PR seems
to fix that. Passing the includes/excludes down to the compiler plugin would
fix problems with filtering of file in Eclipse compiler plugin as well.
was (Author: wilx):
[~olamy] This issue is that AbstractCompilerMojo does not seem to be passing
all of the compiler configuration into the compiler plugin. The linked PR seems
to fix that. Passing the includes/excludes down to the compiler plugin would
fix problems in with filtering of file in Eclipse compiler plugin as well.
> Includes and excludes not passed into CompilerConfiguration
> ---
>
> Key: MCOMPILER-347
> URL: https://issues.apache.org/jira/browse/MCOMPILER-347
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.5
>Reporter: zhangchang
>Assignee: Olivier Lamy
>Priority: Major
>
> Some groovy script is only for runtime excute, other source need compile for
> test.
> So I set exclude in maven-compiler-plugin tag, but it not work.
> {code:java}
>
> ...
>
>
> maven-compiler-plugin
> 3.5
>
> groovy-eclipse-compiler
>
> **/rest/*
>
>
>
>
> org.codehaus.groovy
> groovy-eclipse-compiler
> 2.9.2-01
>
>
> org.codehaus.groovy
> groovy-eclipse-batch
> 2.4.3-01
>
>
>
>
> ...
>
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Comment Edited] (MCOMPILER-347) Includes and excludes not passed into CompilerConfiguration
[
https://issues.apache.org/jira/browse/MCOMPILER-347?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17505234#comment-17505234
]
Václav Haisman edited comment on MCOMPILER-347 at 3/12/22, 10:36 AM:
-
[~olamy] This issue is that AbstractCompilerMojo does not seem to be passing
all of the compiler configuration into the compiler plugin. The linked PR seems
to fix that. Passing the includes/excludes down to the compiler plugin would
fix problems in with filtering of file in Eclipse compiler plugin as well.
was (Author: wilx):
[~olamy] This issue is that AbstractCompilerMojo does not seem to be passing
all of the compiler configuration into the compiler plugin. The linked PR seems
to fix that.
> Includes and excludes not passed into CompilerConfiguration
> ---
>
> Key: MCOMPILER-347
> URL: https://issues.apache.org/jira/browse/MCOMPILER-347
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.5
>Reporter: zhangchang
>Assignee: Olivier Lamy
>Priority: Major
>
> Some groovy script is only for runtime excute, other source need compile for
> test.
> So I set exclude in maven-compiler-plugin tag, but it not work.
> {code:java}
>
> ...
>
>
> maven-compiler-plugin
> 3.5
>
> groovy-eclipse-compiler
>
> **/rest/*
>
>
>
>
> org.codehaus.groovy
> groovy-eclipse-compiler
> 2.9.2-01
>
>
> org.codehaus.groovy
> groovy-eclipse-batch
> 2.4.3-01
>
>
>
>
> ...
>
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (MCOMPILER-347) Includes and excludes not passed into CompilerConfiguration
[
https://issues.apache.org/jira/browse/MCOMPILER-347?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17505234#comment-17505234
]
Václav Haisman commented on MCOMPILER-347:
--
[~olamy] This issue is that AbstractCompilerMojo does not seem to be passing
all of the compiler configuration into the compiler plugin. The linked PR seems
to fix that.
> Includes and excludes not passed into CompilerConfiguration
> ---
>
> Key: MCOMPILER-347
> URL: https://issues.apache.org/jira/browse/MCOMPILER-347
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.5
>Reporter: zhangchang
>Assignee: Olivier Lamy
>Priority: Major
>
> Some groovy script is only for runtime excute, other source need compile for
> test.
> So I set exclude in maven-compiler-plugin tag, but it not work.
> {code:java}
>
> ...
>
>
> maven-compiler-plugin
> 3.5
>
> groovy-eclipse-compiler
>
> **/rest/*
>
>
>
>
> org.codehaus.groovy
> groovy-eclipse-compiler
> 2.9.2-01
>
>
> org.codehaus.groovy
> groovy-eclipse-batch
> 2.4.3-01
>
>
>
>
> ...
>
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [maven-indexer] cstamas opened a new pull request #185: [MINDEXER-145] Update parent and dependencies
cstamas opened a new pull request #185: URL: https://github.com/apache/maven-indexer/pull/185 Updates parent POM to 35 and several dependencies (minor). --- https://issues.apache.org/jira/browse/MINDEXER-145 -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Created] (MINDEXER-145) Update parent POM and dependencies
Tamás Cservenák created MINDEXER-145: Summary: Update parent POM and dependencies Key: MINDEXER-145 URL: https://issues.apache.org/jira/browse/MINDEXER-145 Project: Maven Indexer Issue Type: Task Reporter: Tamás Cservenák Updates: * parent POM to 35 * logback to 1.2.11 * guava to 31.1-jre (used only in tests) * checkstyle to 9.3 * examples/spring to 5.3.16 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (MCOMPILER-347) Includes and excludes not passed into CompilerConfiguration
[
https://issues.apache.org/jira/browse/MCOMPILER-347?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17505223#comment-17505223
]
Piotr Zygielo commented on MCOMPILER-347:
-
Can this be re-evaluated, please?
> Includes and excludes not passed into CompilerConfiguration
> ---
>
> Key: MCOMPILER-347
> URL: https://issues.apache.org/jira/browse/MCOMPILER-347
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.5
>Reporter: zhangchang
>Assignee: Olivier Lamy
>Priority: Major
>
> Some groovy script is only for runtime excute, other source need compile for
> test.
> So I set exclude in maven-compiler-plugin tag, but it not work.
> {code:java}
>
> ...
>
>
> maven-compiler-plugin
> 3.5
>
> groovy-eclipse-compiler
>
> **/rest/*
>
>
>
>
> org.codehaus.groovy
> groovy-eclipse-compiler
> 2.9.2-01
>
>
> org.codehaus.groovy
> groovy-eclipse-batch
> 2.4.3-01
>
>
>
>
> ...
>
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
