[GitHub] [maven-wagon] lhotari opened a new pull request #76: Upgrade HttpCore to 4.4.14 and HttpClient to 4.5.13
lhotari opened a new pull request #76:
URL: https://github.com/apache/maven-wagon/pull/76
- get fix for https://issues.apache.org/jira/browse/HTTPCORE-634
which is causing artifact download failures with error messages such as
"Could not transfer artifact groupId:artifact:1.2.3 from/to central
(https://repo1.maven.org/maven2): Entry
[id:1280][route:{s}->https://repo1.maven.org:443][state:null] has not been
leased from this pool"
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Comment Edited] (MNG-6795) define a replacement for ReasonPhrase to display details about transfert failures
[ https://issues.apache.org/jira/browse/MNG-6795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17284993#comment-17284993 ] Daniel Compton edited comment on MNG-6795 at 2/16/21, 1:31 AM: --- I'm also a maintainer of clojars.org and separately run [Deps|https://www.deps.co], a private Maven repository service. I use the reason phrase to help users debug errors more clearly with Deps. I fully agree that using the HTTP reason phrase to pass this information was a gigantic hack. If it was being proposed today as a new feature, I would vote against it given that it has been removed in HTTP/2 and was never intended for this use. However, it's a vital feature used by many public and private Maven repository managers to help users and customers debug problems. bq. Another problem is that Wagon is protocol agnostic, this means that even if we add those information to Wagon exceptions, it remains unused for other Wagon implementations except HTTP. I can see that this is not ideal, but it's also the current situation that we're in. I would guess that the majority of Maven users are using HTTP Wagons, and the overwhelming majority of errors occurring using Maven would happen with an HTTP Wagon. I don't have any terribly strong feelings about the exact implementation details, I'm happy to update my code to use whatever is the new format. was (Author: danielcompton): I'm also a maintainer of clojars.org and separately run [Deps|https://www.deps.co], a private Maven repository service. I use the reason phrase to help users debug errors more clearly with Deps. I fully agree that using the HTTP reason phrase to pass this information was a gigantic hack. If it was being proposed today as a new feature, I would vote against it given that it has been removed in HTTP/2 and was never intended for this use. However, it's a vital feature used by many public and private Maven repository managers to help users and customers debug problems. > Another problem is that Wagon is protocol agnostic, this means that even if > we add those information to Wagon exceptions, it remains unused for other > Wagon implementations except HTTP. I can see that this is not ideal, but it's also the current situation that we're in. I would guess that the majority of Maven users are using HTTP Wagons, and the overwhelming majority of errors occurring using Maven would happen with an HTTP Wagon. I don't have any terribly strong feelings about the exact implementation details, I'm happy to update my code to use whatever is the new format. > define a replacement for ReasonPhrase to display details about transfert > failures > - > > Key: MNG-6795 > URL: https://issues.apache.org/jira/browse/MNG-6795 > Project: Maven > Issue Type: Task > Components: Artifacts and Repositories >Affects Versions: 3.3.9, 3.6.3 >Reporter: Herve Boutemy >Priority: Major > Fix For: 4.0.x-candidate > > > as documented in WAGON-541 > [372aa52c80c2f7b458c095d837e15ebeafbdf0b7|https://gitbox.apache.org/repos/asf?p=maven-wagon.git&a=commit&h=372aa52c80c2f7b458c095d837e15ebeafbdf0b7], > ReasonPhrase has been removed from HTTP/2 and deprecated (optional) in > HTTP/1.1 for more than five years. It is useful to give detailed error > messages on artifact transfert errors with a repository manager. > A replacement has to be found -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6795) define a replacement for ReasonPhrase to display details about transfert failures
[ https://issues.apache.org/jira/browse/MNG-6795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17284993#comment-17284993 ] Daniel Compton commented on MNG-6795: - I'm also a maintainer of clojars.org and separately run [Deps|https://www.deps.co], a private Maven repository service. I use the reason phrase to help users debug errors more clearly with Deps. I fully agree that using the HTTP reason phrase to pass this information was a gigantic hack. If it was being proposed today as a new feature, I would vote against it given that it has been removed in HTTP/2 and was never intended for this use. However, it's a vital feature used by many public and private Maven repository managers to help users and customers debug problems. > Another problem is that Wagon is protocol agnostic, this means that even if > we add those information to Wagon exceptions, it remains unused for other > Wagon implementations except HTTP. I can see that this is not ideal, but it's also the current situation that we're in. I would guess that the majority of Maven users are using HTTP Wagons, and the overwhelming majority of errors occurring using Maven would happen with an HTTP Wagon. I don't have any terribly strong feelings about the exact implementation details, I'm happy to update my code to use whatever is the new format. > define a replacement for ReasonPhrase to display details about transfert > failures > - > > Key: MNG-6795 > URL: https://issues.apache.org/jira/browse/MNG-6795 > Project: Maven > Issue Type: Task > Components: Artifacts and Repositories >Affects Versions: 3.3.9, 3.6.3 >Reporter: Herve Boutemy >Priority: Major > Fix For: 4.0.x-candidate > > > as documented in WAGON-541 > [372aa52c80c2f7b458c095d837e15ebeafbdf0b7|https://gitbox.apache.org/repos/asf?p=maven-wagon.git&a=commit&h=372aa52c80c2f7b458c095d837e15ebeafbdf0b7], > ReasonPhrase has been removed from HTTP/2 and deprecated (optional) in > HTTP/1.1 for more than five years. It is useful to give detailed error > messages on artifact transfert errors with a repository manager. > A replacement has to be found -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (MSITE-650) Problem with multiple executions of surefire within site plugin 3.0
[ https://issues.apache.org/jira/browse/MSITE-650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17284974#comment-17284974 ] Herve Boutemy edited comment on MSITE-650 at 2/15/21, 11:07 PM: as seen before, it's related to forked lifecycle we need a MNG issue to track update in Maven core and I fear that current behaviour of forked lifecycle: 1. is a feature in the case of Cobertura for example, where we want multiple executions of forked lifecycle because it creates different output results 2. is a problem in the case of Maven Site Plugin, where we want only 1 execution because every execution is expected to git the same output then this issue is tricky to have a magic "fix" what you can do is avoid forked lifecycles was (Author: hboutemy): as seen before, it's related to forked lifecycle we need a MNG issue to track update in Maven core and I fear that current behaviour of forked lifecycle: 1. is a feature in the case of Cobertura for example, where we want multiple executions of forked lifecycle because it creates different output results 2. is an issue in the case of Maven Site Plugin, where we want only 1 execution because every execution is expected to git the same output then this issue is tricky to have a magic "fix" what you can do is avoid forked lifecycles > Problem with multiple executions of surefire within site plugin 3.0 > --- > > Key: MSITE-650 > URL: https://issues.apache.org/jira/browse/MSITE-650 > Project: Maven Site Plugin > Issue Type: Bug >Affects Versions: 3.0 >Reporter: Kristian Rosenvold >Assignee: Herve Boutemy >Priority: Major > Fix For: backlog > > Attachments: fooproject.tar.gz, mvn_X_install_fooproject.txt, > mvn_X_site_fooproject.txt, mvninstall_fooproject.txt, > mvnsite_3.4-SNAPSHOT.txt, mvnsite_fooproject.txt > > > There is a test project attached to SUREFIRE-905 that has a total of 4 > executions of surefire, with different configuration for each. > When running "mvn clean install" inside this project, surefire gets executed > 4 times as expected. When running "mvn site" only the first execution gets > run, the last three get stopped by the configuration-checksum in surefire, > indicating they get executed with the *same* configuration as the default > execution. (Surefire creates a SHA1 hash of all the mojo parameters to avoid > re-running the same configuration, which is why I conclude the three > executions get the same configuration as the default config) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MSITE-650) Problem with multiple executions of surefire within site plugin 3.0
[ https://issues.apache.org/jira/browse/MSITE-650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17284974#comment-17284974 ] Herve Boutemy commented on MSITE-650: - as seen before, it's related to forked lifecycle we need a MNG issue to track update in Maven core and I fear that current behaviour of forked lifecycle: 1. is a feature in the case of Cobertura for example, where we want multiple executions of forked lifecycle because it creates different output results 2. is an issue in the case of Maven Site Plugin, where we want only 1 execution because every execution is expected to git the same output then this issue is tricky to have a magic "fix" what you can do is avoid forked lifecycles > Problem with multiple executions of surefire within site plugin 3.0 > --- > > Key: MSITE-650 > URL: https://issues.apache.org/jira/browse/MSITE-650 > Project: Maven Site Plugin > Issue Type: Bug >Affects Versions: 3.0 >Reporter: Kristian Rosenvold >Assignee: Herve Boutemy >Priority: Major > Fix For: backlog > > Attachments: fooproject.tar.gz, mvn_X_install_fooproject.txt, > mvn_X_site_fooproject.txt, mvninstall_fooproject.txt, > mvnsite_3.4-SNAPSHOT.txt, mvnsite_fooproject.txt > > > There is a test project attached to SUREFIRE-905 that has a total of 4 > executions of surefire, with different configuration for each. > When running "mvn clean install" inside this project, surefire gets executed > 4 times as expected. When running "mvn site" only the first execution gets > run, the last three get stopped by the configuration-checksum in surefire, > indicating they get executed with the *same* configuration as the default > execution. (Surefire creates a SHA1 hash of all the mojo parameters to avoid > re-running the same configuration, which is why I conclude the three > executions get the same configuration as the default config) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [maven] michael-o commented on a change in pull request #446: [MNG-6511] - Optional project selection
michael-o commented on a change in pull request #446:
URL: https://github.com/apache/maven/pull/446#discussion_r576424436
##
File path:
maven-core/src/main/java/org/apache/maven/graph/DefaultGraphBuilder.java
##
@@ -242,21 +274,17 @@ public DefaultGraphBuilder( BuildResumptionDataRepository
buildResumptionDataRep
{
List result = projects;
-if ( !request.getExcludedProjects().isEmpty() )
+ProjectActivation projectActivation = request.getProjectActivation();
+Set requiredSelectors =
projectActivation.getRequiredInactiveProjectSelectors();
+Set optionalSelectors =
projectActivation.getOptionalInactiveProjectSelectors();
+if ( !requiredSelectors.isEmpty() || !optionalSelectors.isEmpty() )
{
-File reactorDirectory = getReactorDirectory( request );
+Set excludedProjects = new HashSet<>(
requiredSelectors.size() + optionalSelectors.size() );
+excludedProjects.addAll( getProjectsBySelectors( request,
projects, requiredSelectors, true ) );
+excludedProjects.addAll( getProjectsBySelectors( request,
projects, optionalSelectors, false ) );
Review comment:
That's acceptable. I think we need to place a comment above that
checking saying it is a workaround and create an issue with the actual cause
for later analysis because as soon as this goes to master it will be forgotten!
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [maven] MartinKanters commented on a change in pull request #446: [MNG-6511] - Optional project selection
MartinKanters commented on a change in pull request #446:
URL: https://github.com/apache/maven/pull/446#discussion_r576420436
##
File path:
maven-core/src/main/java/org/apache/maven/graph/DefaultGraphBuilder.java
##
@@ -242,21 +274,17 @@ public DefaultGraphBuilder( BuildResumptionDataRepository
buildResumptionDataRep
{
List result = projects;
-if ( !request.getExcludedProjects().isEmpty() )
+ProjectActivation projectActivation = request.getProjectActivation();
+Set requiredSelectors =
projectActivation.getRequiredInactiveProjectSelectors();
+Set optionalSelectors =
projectActivation.getOptionalInactiveProjectSelectors();
+if ( !requiredSelectors.isEmpty() || !optionalSelectors.isEmpty() )
{
-File reactorDirectory = getReactorDirectory( request );
+Set excludedProjects = new HashSet<>(
requiredSelectors.size() + optionalSelectors.size() );
+excludedProjects.addAll( getProjectsBySelectors( request,
projects, requiredSelectors, true ) );
+excludedProjects.addAll( getProjectsBySelectors( request,
projects, optionalSelectors, false ) );
Review comment:
I guess it would, but I'm not sure how to fix it otherwise. What would
you rather have? I don't think we can already check whether `a` or `:a` are the
same in an earlier stage.
I've just committed the exception before I read your reply. Please let me
know what you think.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [maven] michael-o commented on a change in pull request #446: [MNG-6511] - Optional project selection
michael-o commented on a change in pull request #446:
URL: https://github.com/apache/maven/pull/446#discussion_r576411705
##
File path:
maven-core/src/main/java/org/apache/maven/graph/DefaultGraphBuilder.java
##
@@ -242,21 +274,17 @@ public DefaultGraphBuilder( BuildResumptionDataRepository
buildResumptionDataRep
{
List result = projects;
-if ( !request.getExcludedProjects().isEmpty() )
+ProjectActivation projectActivation = request.getProjectActivation();
+Set requiredSelectors =
projectActivation.getRequiredInactiveProjectSelectors();
+Set optionalSelectors =
projectActivation.getOptionalInactiveProjectSelectors();
+if ( !requiredSelectors.isEmpty() || !optionalSelectors.isEmpty() )
{
-File reactorDirectory = getReactorDirectory( request );
+Set excludedProjects = new HashSet<>(
requiredSelectors.size() + optionalSelectors.size() );
+excludedProjects.addAll( getProjectsBySelectors( request,
projects, requiredSelectors, true ) );
+excludedProjects.addAll( getProjectsBySelectors( request,
projects, optionalSelectors, false ) );
Review comment:
But that would actually only take care of the symptom, wouldn't it?
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [maven] michael-o commented on a change in pull request #446: [MNG-6511] - Optional project selection
michael-o commented on a change in pull request #446:
URL: https://github.com/apache/maven/pull/446#discussion_r576411705
##
File path:
maven-core/src/main/java/org/apache/maven/graph/DefaultGraphBuilder.java
##
@@ -242,21 +274,17 @@ public DefaultGraphBuilder( BuildResumptionDataRepository
buildResumptionDataRep
{
List result = projects;
-if ( !request.getExcludedProjects().isEmpty() )
+ProjectActivation projectActivation = request.getProjectActivation();
+Set requiredSelectors =
projectActivation.getRequiredInactiveProjectSelectors();
+Set optionalSelectors =
projectActivation.getOptionalInactiveProjectSelectors();
+if ( !requiredSelectors.isEmpty() || !optionalSelectors.isEmpty() )
{
-File reactorDirectory = getReactorDirectory( request );
+Set excludedProjects = new HashSet<>(
requiredSelectors.size() + optionalSelectors.size() );
+excludedProjects.addAll( getProjectsBySelectors( request,
projects, requiredSelectors, true ) );
+excludedProjects.addAll( getProjectsBySelectors( request,
projects, optionalSelectors, false ) );
Review comment:
but that would actually only take care of the symptom, wouldn't it?
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [maven] MartinKanters commented on a change in pull request #446: [MNG-6511] - Optional project selection
MartinKanters commented on a change in pull request #446:
URL: https://github.com/apache/maven/pull/446#discussion_r576404399
##
File path:
maven-core/src/main/java/org/apache/maven/graph/DefaultGraphBuilder.java
##
@@ -242,21 +274,17 @@ public DefaultGraphBuilder( BuildResumptionDataRepository
buildResumptionDataRep
{
List result = projects;
-if ( !request.getExcludedProjects().isEmpty() )
+ProjectActivation projectActivation = request.getProjectActivation();
+Set requiredSelectors =
projectActivation.getRequiredInactiveProjectSelectors();
+Set optionalSelectors =
projectActivation.getOptionalInactiveProjectSelectors();
+if ( !requiredSelectors.isEmpty() || !optionalSelectors.isEmpty() )
{
-File reactorDirectory = getReactorDirectory( request );
+Set excludedProjects = new HashSet<>(
requiredSelectors.size() + optionalSelectors.size() );
+excludedProjects.addAll( getProjectsBySelectors( request,
projects, requiredSelectors, true ) );
+excludedProjects.addAll( getProjectsBySelectors( request,
projects, optionalSelectors, false ) );
Review comment:
"No goal" is definitely a bug. I'm thinking of throwing an exception
when the reactor command line flags result in an empty project 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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [maven] michael-o closed pull request #447: Fix warning with duplicate dependency
michael-o closed pull request #447: URL: https://github.com/apache/maven/pull/447 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven] michael-o commented on pull request #447: Fix warning with duplicate dependency
michael-o commented on pull request #447: URL: https://github.com/apache/maven/pull/447#issuecomment-779420601 There is already PR by @gnodet for this. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven] slawekjaranowski opened a new pull request #447: Fix warning with duplicate dependency
slawekjaranowski opened a new pull request #447: URL: https://github.com/apache/maven/pull/447 Following this checklist to help us incorporate your contribution quickly and easily: - [ ] Make sure there is a [JIRA issue](https://issues.apache.org/jira/browse/MNG) filed for the change (usually before you start working on it). Trivial changes like typos do not require a JIRA issue. Your pull request should address just this issue, without pulling in other changes. - [ ] Each commit in the pull request should have a meaningful subject line and body. - [ ] Format the pull request title like `[MNG-XXX] - Fixes bug in ApproximateQuantiles`, where you replace `MNG-XXX` with the appropriate JIRA issue. Best practice is to use the JIRA issue title in the pull request title and in the first line of the commit message. - [ ] Write a pull request description that is detailed enough to understand what the pull request does, how, and why. - [x] Run `mvn clean verify` to make sure basic checks pass. A more thorough check will be performed on your pull request automatically. - [ ] You have run the [Core IT][core-its] successfully. If your pull request is about ~20 lines of code you don't need to sign an [Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) if you are unsure please ask on the developers list. To make clear that you license your contribution under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) you have to acknowledge this by using the following check-box. - [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). [core-its]: https://maven.apache.org/core-its/core-it-suite/ This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven] michael-o commented on a change in pull request #446: [MNG-6511] - Optional project selection
michael-o commented on a change in pull request #446:
URL: https://github.com/apache/maven/pull/446#discussion_r576387372
##
File path:
maven-core/src/main/java/org/apache/maven/graph/DefaultGraphBuilder.java
##
@@ -242,21 +274,17 @@ public DefaultGraphBuilder( BuildResumptionDataRepository
buildResumptionDataRep
{
List result = projects;
-if ( !request.getExcludedProjects().isEmpty() )
+ProjectActivation projectActivation = request.getProjectActivation();
+Set requiredSelectors =
projectActivation.getRequiredInactiveProjectSelectors();
+Set optionalSelectors =
projectActivation.getOptionalInactiveProjectSelectors();
+if ( !requiredSelectors.isEmpty() || !optionalSelectors.isEmpty() )
{
-File reactorDirectory = getReactorDirectory( request );
+Set excludedProjects = new HashSet<>(
requiredSelectors.size() + optionalSelectors.size() );
+excludedProjects.addAll( getProjectsBySelectors( request,
projects, requiredSelectors, true ) );
+excludedProjects.addAll( getProjectsBySelectors( request,
projects, optionalSelectors, false ) );
Review comment:
But shouldn't that be a null sum game? "No goal ..." sounds wrong in any
case, doesn't it?
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [maven] MartinKanters commented on a change in pull request #446: [MNG-6511] - Optional project selection
MartinKanters commented on a change in pull request #446:
URL: https://github.com/apache/maven/pull/446#discussion_r576385701
##
File path:
maven-core/src/main/java/org/apache/maven/graph/DefaultGraphBuilder.java
##
@@ -242,21 +274,17 @@ public DefaultGraphBuilder( BuildResumptionDataRepository
buildResumptionDataRep
{
List result = projects;
-if ( !request.getExcludedProjects().isEmpty() )
+ProjectActivation projectActivation = request.getProjectActivation();
+Set requiredSelectors =
projectActivation.getRequiredInactiveProjectSelectors();
+Set optionalSelectors =
projectActivation.getOptionalInactiveProjectSelectors();
+if ( !requiredSelectors.isEmpty() || !optionalSelectors.isEmpty() )
{
-File reactorDirectory = getReactorDirectory( request );
+Set excludedProjects = new HashSet<>(
requiredSelectors.size() + optionalSelectors.size() );
+excludedProjects.addAll( getProjectsBySelectors( request,
projects, requiredSelectors, true ) );
+excludedProjects.addAll( getProjectsBySelectors( request,
projects, optionalSelectors, false ) );
Review comment:
Right, the data structure inside `ProjectActivation` is a
`Map<(ProjectSelector)String, (enum)ActivationSetting>`, so that means that a
project cannot be both turned selected and excluded. The one who gets set later
wins (in `-pl !a,+a` '+a' wins).
This was not fully intentional, but I don't dislike the outcome. The same
goes for ProfileActivation, by the way.
The bug remains though if the user invokes `mvn -pl -a,+:a` (same proj,
different selector). It will output "No goals have been specified for this
build.". I'll improve the error message in this case.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Commented] (MSITE-650) Problem with multiple executions of surefire within site plugin 3.0
[ https://issues.apache.org/jira/browse/MSITE-650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17284693#comment-17284693 ] Linus Fernandes commented on MSITE-650: --- I've been told this is related: The following is my pom file located at: https://raw.githubusercontent.com/Fernal73/DSAlgos/master/pom.xml Can you tell me what's causing the following plugins to be executed twice in sequence with the command mvn site? mvn i.e., normal build is as expected. The plugins (and goals) executed twice are: maven-jxr-plugin:3.0.0:jxr < generate-sources maven-jxr-plugin:3.0.0:test-jxr > generate-test-sources maven-enforcer-plugin:3.0.0-M3:enforce (enforce-versions) jacoco-maven-plugin:0.8.6:prepare-agent (default) lombok-maven-plugin:1.18.16.0:delombok (delombok) lombok-maven-plugin:1.18.16.0:testDelombok (test-delombok) maven-antrun-plugin:3.0.0:run (sources) maven-antrun-plugin:3.0.0:run (tests) The project is at https//github.com/fernal73/DSAlgos > Problem with multiple executions of surefire within site plugin 3.0 > --- > > Key: MSITE-650 > URL: https://issues.apache.org/jira/browse/MSITE-650 > Project: Maven Site Plugin > Issue Type: Bug >Affects Versions: 3.0 >Reporter: Kristian Rosenvold >Assignee: Herve Boutemy >Priority: Major > Fix For: backlog > > Attachments: fooproject.tar.gz, mvn_X_install_fooproject.txt, > mvn_X_site_fooproject.txt, mvninstall_fooproject.txt, > mvnsite_3.4-SNAPSHOT.txt, mvnsite_fooproject.txt > > > There is a test project attached to SUREFIRE-905 that has a total of 4 > executions of surefire, with different configuration for each. > When running "mvn clean install" inside this project, surefire gets executed > 4 times as expected. When running "mvn site" only the first execution gets > run, the last three get stopped by the configuration-checksum in surefire, > indicating they get executed with the *same* configuration as the default > execution. (Surefire creates a SHA1 hash of all the mojo parameters to avoid > re-running the same configuration, which is why I conclude the three > executions get the same configuration as the default config) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MINVOKER-278) IT failures when rebuilding 3.2.2 release
[
https://issues.apache.org/jira/browse/MINVOKER-278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17284690#comment-17284690
]
Slawomir Jaranowski commented on MINVOKER-278:
--
I built from source-release.zip on MacOs with java 1.8, 11, 15 and unable to
reproduce errors.
> IT failures when rebuilding 3.2.2 release
> -
>
> Key: MINVOKER-278
> URL: https://issues.apache.org/jira/browse/MINVOKER-278
> Project: Maven Invoker Plugin
> Issue Type: Bug
>Affects Versions: 3.2.2
>Reporter: Herve Boutemy
>Priority: Major
>
> rebuild is done on Linux using source-release.zip (done on Windows):
> {noformat}[INFO] Building: fail-build-with-verify-streamLogsOnFailures/pom.xml
> [INFO] run post-build script verify.groovy
> [INFO] The post-build script did not succeed. assert buildLog.contains(
> buildLogOfProject )
>|| |
>|false [INFO] Scanning for projects...
>| [ERROR] [ERROR] Some problems were encountered
> while processing the POMs:
>| [ERROR] Malformed POM
> /home/herve/tmp/maven-invoker-plugin-3.2.2/target/it/fail-build-with-verify-streamLogsOnFailures/target/it/project/pom.xml:
> Unrecognised tag: 'invalidElementShouldFailBuild' (position: START_TAG seen
> ...\r\n\r\n ... @34:35) @
> /home/herve/tmp/maven-invoker-plugin-3.2.2/target/it/fail-build-with-verify-streamLogsOnFailures/target/it/project/pom.xml,
> line 34, column 35
>| [FATAL] 'modelVersion' of '99.0.0' is newer than
> the versions supported by this version of Maven: [4.0.0]. Building this
> project requires a newer version of Maven. @ line 24, column 17
>| @
>| [ERROR] The build could not read 1 project -> [Help
> 1]
>| [ERROR]
>| [ERROR] The project test:fail-build:0.1-SNAPSHOT
> (/home/herve/tmp/maven-invoker-plugin-3.2.2/target/it/fail-build-with-verify-streamLogsOnFailures/target/it/project/pom.xml)
> has 2 errors
>| [ERROR] Malformed POM
> /home/herve/tmp/maven-invoker-plugin-3.2.2/target/it/fail-build-with-verify-streamLogsOnFailures/target/it/project/pom.xml:
> Unrecognised tag: 'invalidElementShouldFailBuild' (position: START_TAG seen
> ...\r\n\r\n ... @34:35) @
> /home/herve/tmp/maven-invoker-plugin-3.2.2/target/it/fail-build-with-verify-streamLogsOnFailures/target/it/project/pom.xml,
> line 34, column 35 -> [Help 2]
>| [ERROR] 'modelVersion' of '99.0.0' is newer
> than the versions supported by this version of Maven: [4.0.0]. Building this
> project requires a newer version of Maven. @ line 24, column 17
>| [ERROR]
>| [ERROR] To see the full stack trace of the errors,
> re-run Maven with the -e switch.
>| [ERROR] Re-run Maven using the -X switch to enable
> full debug logging.
>| [ERROR]
>| [ERROR] For more information about the errors and
> possible solutions, please read the following articles:
>| [ERROR] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/ProjectBuildingException
>| [ERROR] [Help 2]
> http://cwiki.apache.org/confluence/display/MAVEN/ModelParseException
>Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f)
>Maven home: /home/herve/local/.maven/apache-maven-3.6.3
>Java version: 11.0.7, vendor: AdoptOpenJDK, runtime:
> /home/herve/local/.jdk/jdk-11.0.7+10
> {noformat}
> and
> {noformat}[INFO] Building: fail-build-streamLogsOnFailures/pom.xml
> [INFO] run post-build script verify.groovy
> [INFO] The post-build script did not succeed. assert buildLog.contains(
> buildLogOfProject )
>|| |
>|false [INFO] Scanning for projects...
>| [ERROR] [ERROR] Some problems were encountered
> while processing the POMs:
>| [ERROR] Malformed POM
> /home/herve/tmp/maven-invoker-plugin-3.2.2/target/it/fail-build-streamLogsOnFailures/target/it/project/pom.xml:
> Unrecognised tag: 'invalidElementShouldFailBuild' (position: START_TAG seen
> ...\r\n\r\n ... @34:35) @
> /home/herve/tmp/maven-invoker-plugin-3.2.2/target/it/fail-build-streamLogsOnFailures/target/it/project/pom.xml,
> line 34, column 35
>| [FATAL] 'modelVersion' of '99.0.0' is newer than
> the versions supported by this version of Maven: [4.0.0]. Building this
> project requires a newer version of Maven. @ line 24, column 17
>| @
>| [ERROR] The build could not read 1 pr
[GitHub] [maven-deploy-plugin] klaraward commented on pull request #1: fix DeployAtEnd failures
klaraward commented on pull request #1: URL: https://github.com/apache/maven-deploy-plugin/pull/1#issuecomment-779089868 Any update on this? This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MGPG-75) Creates a signature with the wrong name if a classifier is defined
[ https://issues.apache.org/jira/browse/MGPG-75?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17284622#comment-17284622 ] Łukasz Dywicki commented on MGPG-75: Exact problem is when the primary project artifact specifies an classifier. Then gpg mojo generates signature file but *without* classifier in its name. You end up with below files: * abcdef-1.0.0-SNAPSHOT-*features*.xml * abcdef-1.0.0-SNAPSHOT.asc This is not critical, but when release is made it does not pass upload principles for maven central. > Creates a signature with the wrong name if a classifier is defined > -- > > Key: MGPG-75 > URL: https://issues.apache.org/jira/browse/MGPG-75 > Project: Maven GPG Plugin > Issue Type: Bug >Reporter: Mike Hummel >Assignee: Robert Scholte >Priority: Major > > See pull request > [https://github.com/apache/maven-gpg-plugin/pull/2#event-2847163553] > > The main file of a feature project is a xml file and has a classifier. The > plugin ignores the classifier and creates a signature with wrong name. > > The feature is created by the apache karaf maven plugin. > > The fix also use the classifier to create the correct signature file. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
