[jira] [Created] (MJAVADOC-671) Generated javadoc.bat fails to execute in Windows10
Jesus Salvo created MJAVADOC-671:
Summary: Generated javadoc.bat fails to execute in Windows10
Key: MJAVADOC-671
URL: https://issues.apache.org/jira/browse/MJAVADOC-671
Project: Maven Javadoc Plugin
Issue Type: Bug
Components: javadoc
Affects Versions: 3.2.0
Reporter: Jesus Salvo
Attachments: scratch.zip
In Windows10, I am consistently having this error generated:
{code:java}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-javadoc-plugin:3.2.0:jar (attach-javadocs) on
project work: MavenReportException: Error while generating Javadoc:
[ERROR] Exit code: 1 - javadoc: error - cannot read options (The system cannot
find the file specified)
[ERROR]
[ERROR] Command line was: cmd.exe /X /C
"C:\java\x64\1.8.0-282-openjdk\jre\..\bin\javadoc.exe @options @argfile"
[ERROR]
[ERROR] Refer to the generated Javadoc files in
'C:\projects\scratch\work\target\apidocs' dir. {code}
[^scratch.zip]
Extract the contents of the attached scratch.zip into Windows10, then simply
run `mvn clean package` from the scratch directory, and you get the above error.
The error is not generated in Linux.
h2. *Investigations done*
When `mvn clean package` fails in Windows10, if you change directory
target\apidocs and run the generated *javadoc.bat* file directly, you get the
exact same error above:
{code:java}
C:\projects\scratch\work\target\apidocs>
C:\projects\scratch\work\target\apidocs>javadoc.bat
C:\projects\scratch\work\target\apidocs>cmd.exe /X /C
"C:\java\x64\1.8.0-282-openjdk\jre\..\bin\javadoc.exe @options @argfile"
javadoc: error - cannot read options (The system cannot find the file specified)
1 error {code}
If I then modify the generated *javadoc.bat* file so that, instead of having
this:
{code:java}
cmd.exe /X /C "C:\java\x64\1.8.0-282-openjdk\jre\..\bin\javadoc.exe @options
@argfile" {code}
you replace it with this:
{code:java}
cmd.exe /X /C "cd C:\projects\scratch\work\target\apidocs &&
C:\java\x64\1.8.0-282-openjdk\jre\..\bin\javadoc.exe @options @argfile"{code}
... essentially ensuring the current and working directory of the shell
executed by cmd.exe is that apidocs directory, then execute *javadoc.bat*
again, the issue is resolved :
{code:java}
C:\projects\scratch\work\target\apidocs>cmd.exe /X /C "cd
C:\projects\scratch\work\target\apidocs &&
C:\java\x64\1.8.0-282-openjdk\jre\..\bin\javadoc.exe @options @argfile"
Loading source file
C:\projects\scratch\work\src\main\java\org\examples\Bar.java...
Loading source file
C:\projects\scratch\work\src\main\java\org\examples\Foo.java...
Constructing Javadoc information...
Standard Doclet version 1.8.0_282
Building tree for all the packages and classes...
Generating C:\projects\scratch\work\target\apidocs\org\examples\Bar.html...
Generating C:\projects\scratch\work\target\apidocs\org\examples\Foo.html...
Generating
C:\projects\scratch\work\target\apidocs\org\examples\package-frame.html...
Generating
C:\projects\scratch\work\target\apidocs\org\examples\package-summary.html...
Generating
C:\projects\scratch\work\target\apidocs\org\examples\package-tree.html...
Generating C:\projects\scratch\work\target\apidocs\constant-values.html...
Generating
C:\projects\scratch\work\target\apidocs\org\examples\class-use\Bar.html...
Generating
C:\projects\scratch\work\target\apidocs\org\examples\class-use\Foo.html...
Generating
C:\projects\scratch\work\target\apidocs\org\examples\package-use.html...
Building index for all the packages and classes...
Generating C:\projects\scratch\work\target\apidocs\overview-tree.html...
Generating C:\projects\scratch\work\target\apidocs\index-all.html...
Generating C:\projects\scratch\work\target\apidocs\deprecated-list.html...
Building index for all classes...
Generating C:\projects\scratch\work\target\apidocs\allclasses-frame.html...
Generating C:\projects\scratch\work\target\apidocs\allclasses-noframe.html...
Generating C:\projects\scratch\work\target\apidocs\index.html...
Generating C:\projects\scratch\work\target\apidocs\help-doc.html... {code}
This seems to be due to the way in Windows10 what the default directory is when
cmd.exe is executed, which is slightly different compared to Windows7, which I
also posted the question to stackoverflow:
[https://stackoverflow.com/questions/66165972/windows10-cmd-exe-default-directory-different-to-windows7]
h2. *Suggested fix*
If the detected operation system is Windows10, add a "cd ..." command to ensure
that javadoc.exe is executed from the correct directory.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNGSITE-430) Clarify remote repository resolution order
[
https://issues.apache.org/jira/browse/MNGSITE-430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17284031#comment-17284031
]
Hudson commented on MNGSITE-430:
Build succeeded in Jenkins: Maven » Maven TLP » maven-site » master #126
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven-site/job/master/126/
> Clarify remote repository resolution order
> --
>
> Key: MNGSITE-430
> URL: https://issues.apache.org/jira/browse/MNGSITE-430
> Project: Maven Project Web Site
> Issue Type: Improvement
>Reporter: Konrad Windszus
>Assignee: Sylwester Lachiewicz
>Priority: Major
>
> It is possible to declare remote repositories in {{settings.xml}} and
> {{pom.xml}}. While for the {{settings.xml}} it has to be given in a profile,
> for {{pom.xml}} it can be given in the top-level {{repositories}} element as
> well as in profiles. The order in which an artifact is tried to be resolved
> from the different remote repo is sometimes crucial to know (e.g. to speed up
> build times by first checking against remote repos having most of the
> artifacts like Maven Central)
> It would be nice to document this in
> https://maven.apache.org/guides/introduction/introduction-to-repositories.html
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MWRAPPER-11) Could not find artifact org.apache.maven:apache-maven-wrapper:zip:script
[
https://issues.apache.org/jira/browse/MWRAPPER-11?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17283984#comment-17283984
]
Anthony Whitford commented on MWRAPPER-11:
--
Is this a duplicate of MWRAPPER-6?
> Could not find artifact org.apache.maven:apache-maven-wrapper:zip:script
> -
>
> Key: MWRAPPER-11
> URL: https://issues.apache.org/jira/browse/MWRAPPER-11
> Project: Maven Wrapper
> Issue Type: Bug
>Affects Versions: 3.0.1
>Reporter: Caleb Cushing
>Priority: Blocker
>
> trying to upgrade from the original? non apache plugin. I get this stacktrace
> {code}
> ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-wrapper-plugin:3.0.1:wrapper (default-cli) on
> project dex: Could not find artifact org.apache.maven:apache-maven-wrapper:z
> ip:script:3.6.0 in central (https://repo.maven.apache.org/maven2) -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-wrapper-plugin:3.0.1:wrapper
> (default-cli) on project dex: Could not find
> artifact org.apache.maven:apache-maven-wrapper:zip:script:3.6.0 in central
> (https://repo.maven.apache.org/maven2)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:215)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:156)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:148)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:117)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:81)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
> (SingleThreadedBuilder.java:56)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
> (LifecycleStarter.java:128)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:956)
> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:288)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:192)
> at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke (Method.java:498)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
> (Launcher.java:289)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launch
> (Launcher.java:229)
> at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode
> (Launcher.java:415)
> at org.codehaus.plexus.classworlds.launcher.Launcher.main
> (Launcher.java:356)
> at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke (Method.java:498)
> at org.apache.maven.wrapper.BootstrapMainStarter.start
> (BootstrapMainStarter.java:39)
> at org.apache.maven.wrapper.WrapperExecutor.execute
> (WrapperExecutor.java:122)
> at org.apache.maven.wrapper.MavenWrapperMain.main
> (MavenWrapperMain.java:55)
> Caused by: org.apache.maven.plugin.MojoExecutionException: Could not find
> artifact org.apache.maven:apache-maven-wrapper:zip:script:3.6.0 in central
> (https://repo.maven.apache.org/mave
> n2)
> at org.apache.maven.plugins.wrapper.WrapperMojo.execute
> (WrapperMojo.java:127)
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
> (DefaultBuildPluginManager.java:137)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:210)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:156)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:148)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:117)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:81)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
> (SingleThreadedBuilder.java:56)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
> (LifecycleStarter.java:128)
> at
[GitHub] [maven-integration-testing] MartinKanters commented on pull request #98: [MNG-7095] Support for parallel builds when resuming
MartinKanters commented on pull request #98: URL: https://github.com/apache/maven-integration-testing/pull/98#issuecomment-778442266 > > > I've fixed the comments and change the tests to rely on the `verify` goal rather than `install`. > > > > > > Great. They are still running atm, but the results look good: https://github.com/apache/maven/runs/1890081377?check_suite_focus=true > > Is the CI build set up to run the tests against a branch of maven with the same name ? Yep, it checks whether the contributor who provides the PR has a matching branch on his/hers maven-integration-testing fork. You can see it in the "Collect environment context variables" step in one of the integration-test tasks: > Found a branch "MNG-7095" in fork "gnodet/maven-integration-testing", configuring this for the integration tests to be run against. 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-integration-testing] gnodet commented on pull request #98: [MNG-7095] Support for parallel builds when resuming
gnodet commented on pull request #98: URL: https://github.com/apache/maven-integration-testing/pull/98#issuecomment-778440870 > > I've fixed the comments and change the tests to rely on the `verify` goal rather than `install`. > > Great. They are still running atm, but the results look good: https://github.com/apache/maven/runs/1890081377?check_suite_focus=true Is the CI build set up to run the tests against a branch of maven with the same name ? 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 pull request #444: [MNG-7095] Fix resume for parallel builds
MartinKanters commented on pull request #444: URL: https://github.com/apache/maven/pull/444#issuecomment-778436709 Cool, your ITs are looking good right now, so the PR can be merged in my opinion. @mthmulders do you want to take another look? Otherwise I can merge somewhere this weekend. 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-integration-testing] MartinKanters commented on pull request #98: [MNG-7095] Support for parallel builds when resuming
MartinKanters commented on pull request #98: URL: https://github.com/apache/maven-integration-testing/pull/98#issuecomment-778436035 > I've fixed the comments and change the tests to rely on the `verify` goal rather than `install`. Great. They are still running atm, but the results look good: https://github.com/apache/maven/runs/1890081377?check_suite_focus=true 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-integration-testing] gnodet commented on pull request #98: [MNG-7095] Support for parallel builds when resuming
gnodet commented on pull request #98: URL: https://github.com/apache/maven-integration-testing/pull/98#issuecomment-778426174 I've fixed the comments and change the tests to rely on the `verify` goal rather than `install`. 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-integration-testing] MartinKanters commented on pull request #98: [MNG-7095] Support for parallel builds when resuming
MartinKanters commented on pull request #98: URL: https://github.com/apache/maven-integration-testing/pull/98#issuecomment-778420212 > I've rerun the GitHub Actions build on your maven PR, this should take these new ITs into account as well (as both branches are named the same): > https://github.com/apache/maven/actions/runs/561224481 FYI, the ITs failed because your maven-integration-testing branch is not even with apache:master. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Assigned] (MNG-7099) Can not resume build without installing the artifacts
[ https://issues.apache.org/jira/browse/MNG-7099?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Kanters reassigned MNG-7099: --- Assignee: Martin Kanters > Can not resume build without installing the artifacts > - > > Key: MNG-7099 > URL: https://issues.apache.org/jira/browse/MNG-7099 > Project: Maven > Issue Type: Task >Reporter: Guillaume Nodet >Assignee: Martin Kanters >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (MNG-7099) Can not resume build without installing the artifacts
[ https://issues.apache.org/jira/browse/MNG-7099?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Kanters closed MNG-7099. --- Resolution: Duplicate > Can not resume build without installing the artifacts > - > > Key: MNG-7099 > URL: https://issues.apache.org/jira/browse/MNG-7099 > Project: Maven > Issue Type: Task >Reporter: Guillaume Nodet >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-7099) Can not resume build without installing the artifacts
[ https://issues.apache.org/jira/browse/MNG-7099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17283945#comment-17283945 ] Martin Kanters commented on MNG-7099: - Thanks anyway for the PR and the bug report! > Can not resume build without installing the artifacts > - > > Key: MNG-7099 > URL: https://issues.apache.org/jira/browse/MNG-7099 > Project: Maven > Issue Type: Task >Reporter: Guillaume Nodet >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [maven-integration-testing] gnodet closed pull request #99: [MNG-7099] Add integration test
gnodet closed pull request #99: URL: https://github.com/apache/maven-integration-testing/pull/99 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-integration-testing] gnodet commented on pull request #99: [MNG-7099] Add integration test
gnodet commented on pull request #99: URL: https://github.com/apache/maven-integration-testing/pull/99#issuecomment-778414851 Duplicate, already fixed in maven 4 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MNG-7099) Can not resume build without installing the artifacts
[ https://issues.apache.org/jira/browse/MNG-7099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17283943#comment-17283943 ] Guillaume Nodet commented on MNG-7099: -- Yes, this is clearly a duplicate. Feel free to close this issue. Thx ! > Can not resume build without installing the artifacts > - > > Key: MNG-7099 > URL: https://issues.apache.org/jira/browse/MNG-7099 > Project: Maven > Issue Type: Task >Reporter: Guillaume Nodet >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [maven-integration-testing] MartinKanters commented on pull request #98: [MNG-7095] Support for parallel builds when resuming
MartinKanters commented on pull request #98: URL: https://github.com/apache/maven-integration-testing/pull/98#issuecomment-778413713 Also I don't mind it too much, but perhaps we could avoid `install` now, if MNG-4660 indeed has fixed the issue you described in MNG-7099. 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 edited a comment on pull request #444: [MNG-7095] Fix resume for parallel builds
MartinKanters edited a comment on pull request #444: URL: https://github.com/apache/maven/pull/444#issuecomment-778412923 > > > @mthmulders @MartinKanters quick question. > > > I'm working on improving the integration test and have the following scenario: a parent, 3 modules named `A`, `B`, `C` with `C` depending on `B` (that's the `mng-5760/parent-dependent` test project). > > > I run the `test` goal on the project with `-T2` and with `A` and `C` failing, which means `B` succeeds. When resuming, `C` fails because it can not find the artifact `B`. That's because the goal run previously was `test` and not `install` so the artifact is not in the local repository. However, shouldn't maven be _aware_ that the project is in the local reactor somehow so that the build can succeed ? > > > > > > @gnodet I would also expect that to succeed. Although module B hadn't been packaged in the earlier build, it does have a folder with compiled classes, and that should be enough. Can you isolate that behaviour into a separate test project so I can have a look at that later? > > I've pushed [apache/maven-integration-testing#98](https://github.com/apache/maven-integration-testing/pull/98) which contains 2 integration tests for the parallel build with the resume flag. > > I'll create another PR with an integration test for the other problem. You've encountered the bug that MNG-4660 has fixed, but is not released in a main Maven release yet. With the latest Maven snapshot build you should not have to use install anymore. I reviewed your ITs, they look good (apart from some small points). 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 pull request #444: [MNG-7095] Fix resume for parallel builds
MartinKanters commented on pull request #444: URL: https://github.com/apache/maven/pull/444#issuecomment-778412923 > > > @mthmulders @MartinKanters quick question. > > > I'm working on improving the integration test and have the following scenario: a parent, 3 modules named `A`, `B`, `C` with `C` depending on `B` (that's the `mng-5760/parent-dependent` test project). > > > I run the `test` goal on the project with `-T2` and with `A` and `C` failing, which means `B` succeeds. When resuming, `C` fails because it can not find the artifact `B`. That's because the goal run previously was `test` and not `install` so the artifact is not in the local repository. However, shouldn't maven be _aware_ that the project is in the local reactor somehow so that the build can succeed ? > > > > > > @gnodet I would also expect that to succeed. Although module B hadn't been packaged in the earlier build, it does have a folder with compiled classes, and that should be enough. Can you isolate that behaviour into a separate test project so I can have a look at that later? > > I've pushed [apache/maven-integration-testing#98](https://github.com/apache/maven-integration-testing/pull/98) which contains 2 integration tests for the parallel build with the resume flag. > > I'll create another PR with an integration test for the other problem. You've encountered the bug that MNG-4660 has fixed, but is not released in a main Maven release yet. With the latest Maven snapshot build you should not have to use install anymore. I did review your other ITs as well, they look good (apart from some small points). 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-integration-testing] MartinKanters commented on pull request #98: [MNG-7095] Support for parallel builds when resuming
MartinKanters commented on pull request #98: URL: https://github.com/apache/maven-integration-testing/pull/98#issuecomment-778411008 I've rerun the GitHub Actions build on your maven PR, this should take these new ITs into account as well (as both branches are named the same): https://github.com/apache/maven/actions/runs/561224481 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-integration-testing] MartinKanters commented on a change in pull request #98: [MNG-7095] Support for parallel builds when resuming
MartinKanters commented on a change in pull request #98:
URL:
https://github.com/apache/maven-integration-testing/pull/98#discussion_r57547
##
File path:
core-it-suite/src/test/java/org/apache/maven/it/MavenITmng5760ResumeFeatureTest.java
##
@@ -175,6 +179,112 @@ public void testShouldNotCrashWithoutProject() throws
Exception
}
}
+public void testFailureWithParallelBuild() throws Exception
+{
+Verifier verifier = newVerifier( fourModulesTestDir.getAbsolutePath()
);
+verifier.addCliOption( "-T2" );
+verifier.addCliOption( "-Dmodule-a.delay=1000" );
+verifier.addCliOption( "-Dmodule-a.fail=true" );
+verifier.addCliOption( "-Dmodule-c.fail=true" );
+
+verifier.executeGoal(
"org.apache.maven.plugins:maven-clean-plugin:clean" );
+verifier.deleteArtifact( "org.apache.maven.its.mng5760", "module-a",
"1.0", "jar" );
+verifier.deleteArtifact( "org.apache.maven.its.mng5760", "module-b",
"1.0", "jar" );
+verifier.deleteArtifact( "org.apache.maven.its.mng5760", "module-c",
"1.0", "jar" );
+verifier.deleteArtifact( "org.apache.maven.its.mng5760", "module-d",
"1.0", "jar" );
+
+try
+{
+verifier.executeGoal( "install" );
+fail( "Expected this invocation to fail" );
+}
+catch ( final VerificationException ve )
+{
+// Expected to fail.
+verifier.assertArtifactNotPresent( "org.apache.maven.its.mng5760",
"module-a", "1.0", "jar" );
+verifier.assertArtifactPresent( "org.apache.maven.its.mng5760",
"module-b", "1.0", "jar" );
+verifier.assertArtifactNotPresent( "org.apache.maven.its.mng5760",
"module-c", "1.0", "jar" );
+verifier.assertArtifactNotPresent( "org.apache.maven.its.mng5760",
"module-d", "1.0", "jar" );
+}
+finally
+{
+verifier.resetStreams();
+}
+
+// Let module-b and module-c fail, if they would have been built...
Review comment:
You are only letting module-b fail. I think the comment is not correct,
right? (if so, please also correct the one below)
##
File path:
core-it-suite/src/test/java/org/apache/maven/it/MavenITmng5760ResumeFeatureTest.java
##
@@ -175,6 +179,112 @@ public void testShouldNotCrashWithoutProject() throws
Exception
}
}
+public void testFailureWithParallelBuild() throws Exception
+{
+Verifier verifier = newVerifier( fourModulesTestDir.getAbsolutePath()
);
+verifier.addCliOption( "-T2" );
+verifier.addCliOption( "-Dmodule-a.delay=1000" );
+verifier.addCliOption( "-Dmodule-a.fail=true" );
+verifier.addCliOption( "-Dmodule-c.fail=true" );
+
+verifier.executeGoal(
"org.apache.maven.plugins:maven-clean-plugin:clean" );
+verifier.deleteArtifact( "org.apache.maven.its.mng5760", "module-a",
"1.0", "jar" );
+verifier.deleteArtifact( "org.apache.maven.its.mng5760", "module-b",
"1.0", "jar" );
+verifier.deleteArtifact( "org.apache.maven.its.mng5760", "module-c",
"1.0", "jar" );
+verifier.deleteArtifact( "org.apache.maven.its.mng5760", "module-d",
"1.0", "jar" );
+
+try
+{
+verifier.executeGoal( "install" );
+fail( "Expected this invocation to fail" );
+}
+catch ( final VerificationException ve )
+{
+// Expected to fail.
+verifier.assertArtifactNotPresent( "org.apache.maven.its.mng5760",
"module-a", "1.0", "jar" );
+verifier.assertArtifactPresent( "org.apache.maven.its.mng5760",
"module-b", "1.0", "jar" );
+verifier.assertArtifactNotPresent( "org.apache.maven.its.mng5760",
"module-c", "1.0", "jar" );
+verifier.assertArtifactNotPresent( "org.apache.maven.its.mng5760",
"module-d", "1.0", "jar" );
+}
+finally
+{
+verifier.resetStreams();
+}
+
+// Let module-b and module-c fail, if they would have been built...
+verifier = newVerifier( fourModulesTestDir.getAbsolutePath() );
+verifier.addCliOption( "-T2" );
+verifier.addCliOption( "-Dmodule-b.fail=true" );
+// ... but adding -r should exclude those two from the build because
the previous Maven invocation
+// marked them as successfully built.
+verifier.addCliOption( "-r" );
+try
+{
+verifier.executeGoal( "install" );
+verifier.assertArtifactPresent( "org.apache.maven.its.mng5760",
"module-a", "1.0", "jar" );
+verifier.assertArtifactPresent( "org.apache.maven.its.mng5760",
"module-b", "1.0", "jar" );
+verifier.assertArtifactPresent( "org.apache.maven.its.mng5760",
"module-c", "1.0", "jar" );
+verifier.assertArtifactPresent( "org.apache.maven.its.mng5760",
"module-d", "1.0", "jar" );
+}
+finally
+
[jira] [Commented] (MNG-7099) Can not resume build without installing the artifacts
[ https://issues.apache.org/jira/browse/MNG-7099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17283935#comment-17283935 ] Martin Kanters commented on MNG-7099: - Hey [~gnodet], I totally understand you, this has always bugged me as well! Luckily this was fixed with MNG-4660 [1], which is implemented a while ago, but did not made an official Maven release yet. I've successfully ran your IT against the latest master of Maven. (I had to change line 66 to expect 'mvn -r' though, another unreleased feature...) We have also provided test cases for MNG-4660 in the integration tests project, which are quite similar to yours. Please let me know if you are okay if we close this issue. [1] https://issues.apache.org/jira/browse/MNG-4660 > Can not resume build without installing the artifacts > - > > Key: MNG-7099 > URL: https://issues.apache.org/jira/browse/MNG-7099 > Project: Maven > Issue Type: Task >Reporter: Guillaume Nodet >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [maven] MartinKanters commented on a change in pull request #444: [MNG-7095] Fix resume for parallel builds
MartinKanters commented on a change in pull request #444:
URL: https://github.com/apache/maven/pull/444#discussion_r575186110
##
File path:
maven-core/src/main/java/org/apache/maven/execution/DefaultBuildResumptionAnalyzer.java
##
@@ -47,132 +41,49 @@
@Override
public Optional determineBuildResumptionData( final
MavenExecutionResult result )
{
-final List failedProjects = getFailedProjectsInOrder(
result );
-
-if ( failedProjects.isEmpty() )
+if ( !result.hasExceptions() )
{
-LOGGER.info( "No failed projects found, resuming the build would
not make sense." );
return Optional.empty();
}
-final MavenProject resumeFromProject = failedProjects.get( 0 );
-
-final String resumeFromSelector;
-final List projectsToSkip;
-if ( isFailedProjectFirstInBuild( result, resumeFromProject ) )
-{
-// As the first module in the build failed, there is no need to
specify this as the resumeFrom project.
-resumeFromSelector = null;
-projectsToSkip = determineProjectsToSkip( result, failedProjects,
0 );
-}
-else
-{
-resumeFromSelector = resumeFromProject.getGroupId() + ":" +
resumeFromProject.getArtifactId();
-List allProjects =
result.getTopologicallySortedProjects();
-int resumeFromProjectIndex = allProjects.indexOf(
resumeFromProject );
-projectsToSkip = determineProjectsToSkip( result, failedProjects,
resumeFromProjectIndex + 1 );
-}
-
-boolean canBuildBeResumed = StringUtils.isNotEmpty( resumeFromSelector
) || !projectsToSkip.isEmpty();
-if ( canBuildBeResumed )
-{
-return Optional.of( new BuildResumptionData( resumeFromSelector,
projectsToSkip ) );
-}
-else
-{
-return Optional.empty();
-}
-}
-
-private boolean isFailedProjectFirstInBuild( final MavenExecutionResult
result, final MavenProject failedProject )
-{
-final List sortedProjects =
result.getTopologicallySortedProjects();
-return sortedProjects.indexOf( failedProject ) == 0;
-}
-
-private List getFailedProjectsInOrder( MavenExecutionResult
result )
-{
List sortedProjects =
result.getTopologicallySortedProjects();
-return result.getExceptions().stream()
-.filter( LifecycleExecutionException.class::isInstance )
-.map( LifecycleExecutionException.class::cast )
-.map( LifecycleExecutionException::getProject )
-.filter( Objects::nonNull )
-.sorted( comparing( sortedProjects::indexOf ) )
-.collect( Collectors.toList() );
-}
-
-/**
- * Projects after the first failed project could have succeeded by using
-T or --fail-at-end.
- * These projects can be skipped from later builds.
- * This is not the case these projects are dependent on one of the failed
projects.
- * @param result The result of the Maven build.
- * @param failedProjects The list of failed projects in the build.
- * @param startFromProjectIndex Start looking for projects which can be
skipped from a certain index.
- * @return A list of projects which can be skipped in a later build.
- */
-private List determineProjectsToSkip( MavenExecutionResult result,
- List
failedProjects,
- int startFromProjectIndex )
-{
-List allProjects =
result.getTopologicallySortedProjects();
-List remainingProjects = allProjects.subList(
startFromProjectIndex, allProjects.size() );
-
-List failedProjectsGAList = failedProjects.stream()
-.map( GroupArtifactPair::new )
-.collect( Collectors.toList() );
-
-return remainingProjects.stream()
+long succeeded = sortedProjects.stream()
.filter( project -> result.getBuildSummary( project )
instanceof BuildSuccess )
-.filter( project -> hasNoDependencyOnProjects( project,
failedProjectsGAList ) )
-.map( project -> project.getGroupId() + ":" +
project.getArtifactId() )
-.collect( Collectors.toList() );
-}
-
-private boolean hasNoDependencyOnProjects( MavenProject project,
List projectsGAs )
-{
-return project.getDependencies().stream()
-.map( GroupArtifactPair::new )
-.noneMatch( projectsGAs::contains );
-}
-
-private static class GroupArtifactPair
-{
-private final String groupId;
-private final String artifactId;
-
-GroupArtifactPair( MavenProject project )
-{
-this.groupId = project.getGroupId();
-this.artifactId = project.getArtifactId();
-}
+.count();
-
[GitHub] [maven] gnodet commented on pull request #444: [MNG-7095] Fix resume for parallel builds
gnodet commented on pull request #444: URL: https://github.com/apache/maven/pull/444#issuecomment-778388548 I've raised MNG-7099 and provided a PR with an integration test. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MNG-7099) Can not resume build without installing the artifacts
[ https://issues.apache.org/jira/browse/MNG-7099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17283918#comment-17283918 ] Guillaume Nodet commented on MNG-7099: -- Fwiw, I think that's the reason why I've never used anything but the install goal. I.e., if you can't resume it, it's barely usable with big builds. > Can not resume build without installing the artifacts > - > > Key: MNG-7099 > URL: https://issues.apache.org/jira/browse/MNG-7099 > Project: Maven > Issue Type: Task >Reporter: Guillaume Nodet >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-7099) Can not resume build without installing the artifacts
[ https://issues.apache.org/jira/browse/MNG-7099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17283917#comment-17283917 ] Guillaume Nodet commented on MNG-7099: -- A PR with an integration test is available at https://github.com/apache/maven-integration-testing/pull/99 > Can not resume build without installing the artifacts > - > > Key: MNG-7099 > URL: https://issues.apache.org/jira/browse/MNG-7099 > Project: Maven > Issue Type: Task >Reporter: Guillaume Nodet >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [maven-integration-testing] gnodet opened a new pull request #99: [MNG-7099] Add integration test
gnodet opened a new pull request #99: URL: https://github.com/apache/maven-integration-testing/pull/99 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Created] (MNG-7099) Can not resume build without installing the artifacts
Guillaume Nodet created MNG-7099: Summary: Can not resume build without installing the artifacts Key: MNG-7099 URL: https://issues.apache.org/jira/browse/MNG-7099 Project: Maven Issue Type: Task Reporter: Guillaume Nodet -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (MSHADE-382) Add an option to skip execution
Andres Almiray created MSHADE-382: - Summary: Add an option to skip execution Key: MSHADE-382 URL: https://issues.apache.org/jira/browse/MSHADE-382 Project: Maven Shade Plugin Issue Type: Improvement Affects Versions: 3.2.4 Reporter: Andres Almiray It'd be great to have a property for skipping execution, such as `maven.shade.skip`. Useful when a parent has setup shading but a child would like to skip it for example. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [maven] gnodet commented on pull request #444: [MNG-7095] Fix resume for parallel builds
gnodet commented on pull request #444: URL: https://github.com/apache/maven/pull/444#issuecomment-778360471 > > @mthmulders @MartinKanters quick question. > > I'm working on improving the integration test and have the following scenario: a parent, 3 modules named `A`, `B`, `C` with `C` depending on `B` (that's the `mng-5760/parent-dependent` test project). > > I run the `test` goal on the project with `-T2` and with `A` and `C` failing, which means `B` succeeds. When resuming, `C` fails because it can not find the artifact `B`. That's because the goal run previously was `test` and not `install` so the artifact is not in the local repository. However, shouldn't maven be _aware_ that the project is in the local reactor somehow so that the build can succeed ? > > @gnodet I would also expect that to succeed. Although module B hadn't been packaged in the earlier build, it does have a folder with compiled classes, and that should be enough. Can you isolate that behaviour into a separate test project so I can have a look at that later? I've pushed https://github.com/apache/maven-integration-testing/pull/98 which contains 2 integration tests for the parallel build with the resume flag. I'll create another PR with an integration test for the other problem. 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-integration-testing] gnodet commented on pull request #98: [MNG-7095] Support for parallel builds when resuming
gnodet commented on pull request #98: URL: https://github.com/apache/maven-integration-testing/pull/98#issuecomment-778325826 I'll add another test This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MNG-7077) Use JUnit 5 extension
[ https://issues.apache.org/jira/browse/MNG-7077?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17283833#comment-17283833 ] Hudson commented on MNG-7077: - Build succeeded in Jenkins: Maven » Maven TLP » maven » master #100 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/master/100/ > Use JUnit 5 extension > - > > Key: MNG-7077 > URL: https://issues.apache.org/jira/browse/MNG-7077 > Project: Maven > Issue Type: Improvement > Components: core >Reporter: Guillaume Nodet >Assignee: Robert Scholte >Priority: Major > Fix For: 4.0.0, 4.0.0-alpha-1 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [maven] mthmulders commented on pull request #444: [MNG-7095] Fix resume for parallel builds
mthmulders commented on pull request #444: URL: https://github.com/apache/maven/pull/444#issuecomment-778301747 > @mthmulders @MartinKanters quick question. > I'm working on improving the integration test and have the following scenario: a parent, 3 modules named `A`, `B`, `C` with `C` depending on `B` (that's the `mng-5760/parent-dependent` test project). > I run the `test` goal on the project with `-T2` and with `A` and `C` failing, which means `B` succeeds. When resuming, `C` fails because it can not find the artifact `B`. That's because the goal run previously was `test` and not `install` so the artifact is not in the local repository. However, shouldn't maven be _aware_ that the project is in the local reactor somehow so that the build can succeed ? @gnodet I would also expect that to succeed. Although module B hadn't been packaged in the earlier build, it does have a folder with compiled classes, and that should be enough. Can you isolate that behaviour into a separate test project so I can have a look at that later? This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven] rfscholte closed pull request #432: [MNG-7077] Use JUnit 5 extension
rfscholte closed pull request #432: URL: https://github.com/apache/maven/pull/432 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven] rfscholte commented on pull request #432: [MNG-7077] Use JUnit 5 extension
rfscholte commented on pull request #432: URL: https://github.com/apache/maven/pull/432#issuecomment-778294714 Merged with https://github.com/apache/maven/commit/48fc10889ef89d12ebe2258029937010d81aebb7 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] [Closed] (MNG-7077) Use JUnit 5 extension
[ https://issues.apache.org/jira/browse/MNG-7077?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte closed MNG-7077. --- Fix Version/s: 4.0.0-alpha-1 4.0.0 Assignee: Robert Scholte Resolution: Fixed Fixed in [48fc10889ef89d12ebe2258029937010d81aebb7|https://gitbox.apache.org/repos/asf?p=maven.git;a=commit;h=48fc10889ef89d12ebe2258029937010d81aebb7] > Use JUnit 5 extension > - > > Key: MNG-7077 > URL: https://issues.apache.org/jira/browse/MNG-7077 > Project: Maven > Issue Type: Improvement > Components: core >Reporter: Guillaume Nodet >Assignee: Robert Scholte >Priority: Major > Fix For: 4.0.0, 4.0.0-alpha-1 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [maven] gnodet commented on pull request #444: [MNG-7095] Fix resume for parallel builds
gnodet commented on pull request #444: URL: https://github.com/apache/maven/pull/444#issuecomment-778273066 I've added an integration test that tries to make sure the resume won't rebuild already built projects, see https://github.com/apache/maven-integration-testing/pull/98 Eventually, a test that would verify that SKIPPED projects that are _topologically before_ the first FAILED project are rebuilt too would be nice. 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-integration-testing] gnodet opened a new pull request #98: [MNG-7095] Support for parallel builds when resuming
gnodet opened a new pull request #98: URL: https://github.com/apache/maven-integration-testing/pull/98 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] gnodet commented on pull request #444: [MNG-7095] Fix resume for parallel builds
gnodet commented on pull request #444: URL: https://github.com/apache/maven/pull/444#issuecomment-778266531 > @mthmulders @MartinKanters quick question. > I'm working on improving the integration test and have the following scenario: a parent, 3 modules named `A`, `B`, `C` with `C` depending on `B` (that's the `mng-5760/parent-dependent` test project). > I run the `test` goal on the project with `-T2` and with `A` and `C` failing, which means `B` succeeds. When resuming, `C` fails because it can not find the artifact `B`. That's because the goal run previously was `test` and not `install` so the artifact is not in the local repository. However, shouldn't maven be _aware_ that the project is in the local reactor somehow so that the build can succeed ? I think this problem is not specific to the `--resume` feature, and it seems the behavior is the same for the `--resume-from` feature. So I'll push a PR with the test once I've run the full 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] gnodet commented on pull request #444: [MNG-7095] Fix resume for parallel builds
gnodet commented on pull request #444: URL: https://github.com/apache/maven/pull/444#issuecomment-778264311 @mthmulders @MartinKanters quick question. I'm working on improving the integration test and have the following scenario: a parent, 3 modules named `A`, `B`, `C` with `C` depending on `B` (that's the `mng-5760/parent-dependent` test project). I run the `test` goal on the project with `-T2` and with `A` and `C` failing, which means `B` succeeds. When resuming, `C` fails because it can not find the artifact `B`. That's because the goal run previously was `test` and not `install` so the artifact is not in the local repository. However, shouldn't maven be _aware_ that the project is in the local reactor somehow so that the build can succeed ? This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven] rfscholte commented on pull request #402: DefaultProjectBuilder enhancements
rfscholte commented on pull request #402: URL: https://github.com/apache/maven/pull/402#issuecomment-778258696 ok, let me check that one first This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MNG-7063) Infinite loop using Shade plugin and JUnit 5 dependency
[
https://issues.apache.org/jira/browse/MNG-7063?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17283768#comment-17283768
]
Michael Osipov commented on MNG-7063:
-
[~cstamas], this is likely the same as your issue with Maven from master.
> Infinite loop using Shade plugin and JUnit 5 dependency
> ---
>
> Key: MNG-7063
> URL: https://issues.apache.org/jira/browse/MNG-7063
> Project: Maven
> Issue Type: Bug
>Affects Versions: 4.0.0-alpha-1
>Reporter: Thiago Henrique Hupner
>Assignee: Robert Scholte
>Priority: Major
> Fix For: 4.0.0-alpha-1
>
>
> When trying my project with Maven 4.0.0, it got in an infinite loop.
> I've figured out that adding the JUnit 5 dependency and using the Shade
> plugin transformer causes the problem.
> With Maven 3.6.3 this problem doesn't happen.
>
> {code:xml}
>
> http://maven.apache.org/POM/4.0.0;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/xsd/maven-4.0.0.xsd;>
> 4.0.0
> org.example
> maven-bug
> 1.0-SNAPSHOT
>
> 8
> 8
>
> jar
>
>
> com.google.guava
> guava
> 29.0-jre
>
>
> org.junit.jupiter
> junit-jupiter-api
> 5.7.0
> test
>
>
>
>
>
> org.apache.maven.plugins
> maven-shade-plugin
> 3.2.4
>
>
> package
>
> shade
>
>
>
>
>
>
>
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [maven] gnodet commented on pull request #402: DefaultProjectBuilder enhancements
gnodet commented on pull request #402: URL: https://github.com/apache/maven/pull/402#issuecomment-778257427 > I just had another look at this. It looks to me that this commit has become too big. We should split it into 2 pieces: > > * rewriting JUnit tests using maven-test-support. > * Remove double cache, which would fix [MNG-7063](https://issues.apache.org/jira/browse/MNG-7063). Done. Fwiw, https://github.com/apache/maven/pull/432 is about the junit 5. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven] rfscholte commented on pull request #402: DefaultProjectBuilder enhancements
rfscholte commented on pull request #402: URL: https://github.com/apache/maven/pull/402#issuecomment-778249119 I just had another look at this. It looks to me that this commit has become too big. We should split it into 2 pieces: * rewriting JUnit tests using maven-test-support. * Remove double cache, which would fix MNG-7063. 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] gnodet commented on a change in pull request #444: [MNG-7095] Fix resume for parallel builds
gnodet commented on a change in pull request #444:
URL: https://github.com/apache/maven/pull/444#discussion_r575250093
##
File path: maven-embedder/src/main/java/org/apache/maven/cli/MavenCli.java
##
@@ -1032,20 +1031,6 @@ private int execute( CliRequest cliRequest )
{
logBuildResumeHint( "mvn -r" );
}
-else if ( !failedProjects.isEmpty() )
Review comment:
I see. I'll bring it back.
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 #444: [MNG-7095] Fix resume for parallel builds
MartinKanters commented on a change in pull request #444:
URL: https://github.com/apache/maven/pull/444#discussion_r575239494
##
File path: maven-embedder/src/main/java/org/apache/maven/cli/MavenCli.java
##
@@ -1032,20 +1031,6 @@ private int execute( CliRequest cliRequest )
{
logBuildResumeHint( "mvn -r" );
}
-else if ( !failedProjects.isEmpty() )
Review comment:
It would indeed be a very exceptional case, but it's possible that
writing the resume.properties file on disk fails for some reason. That's why we
kept it.
This piece of code ensures that in that event, the canResume flag is not set
to `true`, so it would end up in logging the `-rf` hint.
https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/DefaultMaven.java#L404-L412
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Commented] (MNG-6763) Restrict repositories to specific groupIds
[
https://issues.apache.org/jira/browse/MNG-6763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17283700#comment-17283700
]
Michael Osipov commented on MNG-6763:
-
I believe that this can be down with {{maven-common-artifact-filters}} it
supports exclusions too.
> Restrict repositories to specific groupIds
> --
>
> Key: MNG-6763
> URL: https://issues.apache.org/jira/browse/MNG-6763
> Project: Maven
> Issue Type: New Feature
>Reporter: dennis lucero
>Priority: Major
> Labels: intern
>
> It should be possible to restrict the repositories specified in settings.xml
> to specific groupIds. Looking at
> [https://maven.apache.org/ref/3.6.2/maven-settings/settings.html#class_repository],
> it seems this is currently not the case.
> Background: We use Nexus to host our own artifacts. The settings.xml contains
> our Nexus repository with always because
> sometimes a project is built while a dependency is not yet in our Nexus repo
> – without updatePolicy, it would take 24 hours or manual deletion of metadata
> to make Maven re-check for the missing dependency.
> Additionally, we use versions-maven-plugin:2.7:display-dependency-updates in
> our build process.
> This results in lots of queries (more than 300 in a simple Dropwizard
> project) to our repo which will never succeed. If we could specify that our
> repo only supplies groupIds beginning with org.example, Maven could skip
> update checks for groupIds starting with com.fasterxml.jackson and so on,
> speeding up the build process.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [maven] mthmulders commented on a change in pull request #444: [MNG-7095] Fix resume for parallel builds
mthmulders commented on a change in pull request #444:
URL: https://github.com/apache/maven/pull/444#discussion_r575231766
##
File path:
maven-core/src/main/java/org/apache/maven/execution/DefaultBuildResumptionDataRepository.java
##
@@ -133,22 +126,14 @@ private Properties loadResumptionFile( Path
rootBuildDirectory )
// This method is made package-private for testing purposes
void applyResumptionProperties( MavenExecutionRequest request, Properties
properties )
{
-if ( properties.containsKey( RESUME_FROM_PROPERTY ) &&
StringUtils.isEmpty( request.getResumeFrom() ) )
+if ( properties.containsKey( RESUME_PROJECT_LIST )
+&& StringUtils.isEmpty( request.getResumeFrom() ) )
{
-String propertyValue = properties.getProperty(
RESUME_FROM_PROPERTY );
-request.setResumeFrom( propertyValue );
+String propertyValue = properties.getProperty( RESUME_PROJECT_LIST
);
+Stream.of( propertyValue.split( PROPERTY_DELIMITER ) )
+.filter( StringUtils::isNotEmpty )
+.forEach( request.getSelectedProjects():: add );
Review comment:
```suggestion
.forEach( request.getSelectedProjects()::add );
```
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] mthmulders commented on a change in pull request #444: [MNG-7095] Fix resume for parallel builds
mthmulders commented on a change in pull request #444:
URL: https://github.com/apache/maven/pull/444#discussion_r575231427
##
File path:
maven-core/src/main/java/org/apache/maven/execution/DefaultBuildResumptionDataRepository.java
##
@@ -133,22 +126,14 @@ private Properties loadResumptionFile( Path
rootBuildDirectory )
// This method is made package-private for testing purposes
void applyResumptionProperties( MavenExecutionRequest request, Properties
properties )
{
-if ( properties.containsKey( RESUME_FROM_PROPERTY ) &&
StringUtils.isEmpty( request.getResumeFrom() ) )
+if ( properties.containsKey( RESUME_PROJECT_LIST )
+&& StringUtils.isEmpty( request.getResumeFrom() ) )
{
-String propertyValue = properties.getProperty(
RESUME_FROM_PROPERTY );
-request.setResumeFrom( propertyValue );
+String propertyValue = properties.getProperty( RESUME_PROJECT_LIST
);
+Stream.of( propertyValue.split( PROPERTY_DELIMITER ) )
+.filter( StringUtils::isNotEmpty )
+.forEach( request.getSelectedProjects():: add );
Review comment:
Just checked, and including `-pl :xxx` where `xxx` is also in
**target/resume.properties** builds that module once, as you'd hope/expect.
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] mthmulders commented on a change in pull request #444: [MNG-7095] Fix resume for parallel builds
mthmulders commented on a change in pull request #444:
URL: https://github.com/apache/maven/pull/444#discussion_r575230619
##
File path:
maven-core/src/main/java/org/apache/maven/execution/DefaultBuildResumptionAnalyzer.java
##
@@ -47,132 +41,49 @@
@Override
public Optional determineBuildResumptionData( final
MavenExecutionResult result )
{
-final List failedProjects = getFailedProjectsInOrder(
result );
-
-if ( failedProjects.isEmpty() )
+if ( !result.hasExceptions() )
{
-LOGGER.info( "No failed projects found, resuming the build would
not make sense." );
return Optional.empty();
}
-final MavenProject resumeFromProject = failedProjects.get( 0 );
-
-final String resumeFromSelector;
-final List projectsToSkip;
-if ( isFailedProjectFirstInBuild( result, resumeFromProject ) )
-{
-// As the first module in the build failed, there is no need to
specify this as the resumeFrom project.
-resumeFromSelector = null;
-projectsToSkip = determineProjectsToSkip( result, failedProjects,
0 );
-}
-else
-{
-resumeFromSelector = resumeFromProject.getGroupId() + ":" +
resumeFromProject.getArtifactId();
-List allProjects =
result.getTopologicallySortedProjects();
-int resumeFromProjectIndex = allProjects.indexOf(
resumeFromProject );
-projectsToSkip = determineProjectsToSkip( result, failedProjects,
resumeFromProjectIndex + 1 );
-}
-
-boolean canBuildBeResumed = StringUtils.isNotEmpty( resumeFromSelector
) || !projectsToSkip.isEmpty();
-if ( canBuildBeResumed )
-{
-return Optional.of( new BuildResumptionData( resumeFromSelector,
projectsToSkip ) );
-}
-else
-{
-return Optional.empty();
-}
-}
-
-private boolean isFailedProjectFirstInBuild( final MavenExecutionResult
result, final MavenProject failedProject )
-{
-final List sortedProjects =
result.getTopologicallySortedProjects();
-return sortedProjects.indexOf( failedProject ) == 0;
-}
-
-private List getFailedProjectsInOrder( MavenExecutionResult
result )
-{
List sortedProjects =
result.getTopologicallySortedProjects();
-return result.getExceptions().stream()
-.filter( LifecycleExecutionException.class::isInstance )
-.map( LifecycleExecutionException.class::cast )
-.map( LifecycleExecutionException::getProject )
-.filter( Objects::nonNull )
-.sorted( comparing( sortedProjects::indexOf ) )
-.collect( Collectors.toList() );
-}
-
-/**
- * Projects after the first failed project could have succeeded by using
-T or --fail-at-end.
- * These projects can be skipped from later builds.
- * This is not the case these projects are dependent on one of the failed
projects.
- * @param result The result of the Maven build.
- * @param failedProjects The list of failed projects in the build.
- * @param startFromProjectIndex Start looking for projects which can be
skipped from a certain index.
- * @return A list of projects which can be skipped in a later build.
- */
-private List determineProjectsToSkip( MavenExecutionResult result,
- List
failedProjects,
- int startFromProjectIndex )
-{
-List allProjects =
result.getTopologicallySortedProjects();
-List remainingProjects = allProjects.subList(
startFromProjectIndex, allProjects.size() );
-
-List failedProjectsGAList = failedProjects.stream()
-.map( GroupArtifactPair::new )
-.collect( Collectors.toList() );
-
-return remainingProjects.stream()
+long succeeded = sortedProjects.stream()
.filter( project -> result.getBuildSummary( project )
instanceof BuildSuccess )
-.filter( project -> hasNoDependencyOnProjects( project,
failedProjectsGAList ) )
-.map( project -> project.getGroupId() + ":" +
project.getArtifactId() )
-.collect( Collectors.toList() );
-}
-
-private boolean hasNoDependencyOnProjects( MavenProject project,
List projectsGAs )
-{
-return project.getDependencies().stream()
-.map( GroupArtifactPair::new )
-.noneMatch( projectsGAs::contains );
-}
-
-private static class GroupArtifactPair
-{
-private final String groupId;
-private final String artifactId;
-
-GroupArtifactPair( MavenProject project )
-{
-this.groupId = project.getGroupId();
-this.artifactId = project.getArtifactId();
-}
+.count();
-
[GitHub] [maven] gnodet commented on pull request #444: [MNG-7095] Fix resume for parallel builds
gnodet commented on pull request #444: URL: https://github.com/apache/maven/pull/444#issuecomment-778165900 > I like the fact that the solution becomes much simpler. Could you please add a unit test or an [integration test](https://github.com/apache/maven-integration-testing/) that proves the issue has been fixed? I've pushed a PR with the suggested fixes. I'll try to create an integration tests asap. 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 #444: [MNG-7095] Fix resume for parallel builds
MartinKanters commented on a change in pull request #444:
URL: https://github.com/apache/maven/pull/444#discussion_r575186110
##
File path:
maven-core/src/main/java/org/apache/maven/execution/DefaultBuildResumptionAnalyzer.java
##
@@ -47,132 +41,49 @@
@Override
public Optional determineBuildResumptionData( final
MavenExecutionResult result )
{
-final List failedProjects = getFailedProjectsInOrder(
result );
-
-if ( failedProjects.isEmpty() )
+if ( !result.hasExceptions() )
{
-LOGGER.info( "No failed projects found, resuming the build would
not make sense." );
return Optional.empty();
}
-final MavenProject resumeFromProject = failedProjects.get( 0 );
-
-final String resumeFromSelector;
-final List projectsToSkip;
-if ( isFailedProjectFirstInBuild( result, resumeFromProject ) )
-{
-// As the first module in the build failed, there is no need to
specify this as the resumeFrom project.
-resumeFromSelector = null;
-projectsToSkip = determineProjectsToSkip( result, failedProjects,
0 );
-}
-else
-{
-resumeFromSelector = resumeFromProject.getGroupId() + ":" +
resumeFromProject.getArtifactId();
-List allProjects =
result.getTopologicallySortedProjects();
-int resumeFromProjectIndex = allProjects.indexOf(
resumeFromProject );
-projectsToSkip = determineProjectsToSkip( result, failedProjects,
resumeFromProjectIndex + 1 );
-}
-
-boolean canBuildBeResumed = StringUtils.isNotEmpty( resumeFromSelector
) || !projectsToSkip.isEmpty();
-if ( canBuildBeResumed )
-{
-return Optional.of( new BuildResumptionData( resumeFromSelector,
projectsToSkip ) );
-}
-else
-{
-return Optional.empty();
-}
-}
-
-private boolean isFailedProjectFirstInBuild( final MavenExecutionResult
result, final MavenProject failedProject )
-{
-final List sortedProjects =
result.getTopologicallySortedProjects();
-return sortedProjects.indexOf( failedProject ) == 0;
-}
-
-private List getFailedProjectsInOrder( MavenExecutionResult
result )
-{
List sortedProjects =
result.getTopologicallySortedProjects();
-return result.getExceptions().stream()
-.filter( LifecycleExecutionException.class::isInstance )
-.map( LifecycleExecutionException.class::cast )
-.map( LifecycleExecutionException::getProject )
-.filter( Objects::nonNull )
-.sorted( comparing( sortedProjects::indexOf ) )
-.collect( Collectors.toList() );
-}
-
-/**
- * Projects after the first failed project could have succeeded by using
-T or --fail-at-end.
- * These projects can be skipped from later builds.
- * This is not the case these projects are dependent on one of the failed
projects.
- * @param result The result of the Maven build.
- * @param failedProjects The list of failed projects in the build.
- * @param startFromProjectIndex Start looking for projects which can be
skipped from a certain index.
- * @return A list of projects which can be skipped in a later build.
- */
-private List determineProjectsToSkip( MavenExecutionResult result,
- List
failedProjects,
- int startFromProjectIndex )
-{
-List allProjects =
result.getTopologicallySortedProjects();
-List remainingProjects = allProjects.subList(
startFromProjectIndex, allProjects.size() );
-
-List failedProjectsGAList = failedProjects.stream()
-.map( GroupArtifactPair::new )
-.collect( Collectors.toList() );
-
-return remainingProjects.stream()
+long succeeded = sortedProjects.stream()
.filter( project -> result.getBuildSummary( project )
instanceof BuildSuccess )
-.filter( project -> hasNoDependencyOnProjects( project,
failedProjectsGAList ) )
-.map( project -> project.getGroupId() + ":" +
project.getArtifactId() )
-.collect( Collectors.toList() );
-}
-
-private boolean hasNoDependencyOnProjects( MavenProject project,
List projectsGAs )
-{
-return project.getDependencies().stream()
-.map( GroupArtifactPair::new )
-.noneMatch( projectsGAs::contains );
-}
-
-private static class GroupArtifactPair
-{
-private final String groupId;
-private final String artifactId;
-
-GroupArtifactPair( MavenProject project )
-{
-this.groupId = project.getGroupId();
-this.artifactId = project.getArtifactId();
-}
+.count();
-
[GitHub] [maven] gnodet commented on a change in pull request #444: [MNG-7095] Fix resume for parallel builds
gnodet commented on a change in pull request #444:
URL: https://github.com/apache/maven/pull/444#discussion_r575184291
##
File path: maven-embedder/src/main/java/org/apache/maven/cli/MavenCli.java
##
@@ -1032,20 +1031,6 @@ private int execute( CliRequest cliRequest )
{
logBuildResumeHint( "mvn -r" );
}
-else if ( !failedProjects.isEmpty() )
Review comment:
I can bring it back, I just don't think there's any case where `-rf`
could work while `-r` would not be available. Especially now with the fact
that it's just a list of non succeeded 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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [maven] gnodet commented on a change in pull request #444: [MNG-7095] Fix resume for parallel builds
gnodet commented on a change in pull request #444:
URL: https://github.com/apache/maven/pull/444#discussion_r575182290
##
File path:
maven-core/src/test/java/org/apache/maven/execution/DefaultBuildResumptionDataRepositoryTest.java
##
@@ -54,38 +55,38 @@ public void
resumeFromPropertyDoesNotOverrideExistingRequestParameters()
MavenExecutionRequest request = new DefaultMavenExecutionRequest();
request.setResumeFrom( ":module-b" );
Properties properties = new Properties();
-properties.setProperty( "resumeFrom", ":module-a" );
+properties.setProperty( "projectList", ":module-a" );
repository.applyResumptionProperties( request, properties );
assertThat( request.getResumeFrom(), is( ":module-b" ) );
}
@Test
-public void
excludedProjectsFromPropertyGetsAddedToExistingRequestParameters()
+public void projectsFromPropertyGetsAddedToExistingRequestParameters()
{
MavenExecutionRequest request = new DefaultMavenExecutionRequest();
-List excludedProjects = new ArrayList<>();
-excludedProjects.add( ":module-a" );
-request.setExcludedProjects( excludedProjects );
+List selectedProjects = new ArrayList<>();
+selectedProjects.add( ":module-a" );
+request.setSelectedProjects( selectedProjects );
Properties properties = new Properties();
-properties.setProperty( "excludedProjects", ":module-b, :module-c" );
+properties.setProperty( "projectList", ":module-b, :module-c" );
repository.applyResumptionProperties( request, properties );
-assertThat( request.getExcludedProjects(), contains( ":module-a",
":module-b", ":module-c" ) );
+assertThat( request.getSelectedProjects(), contains( ":module-a",
":module-b", ":module-c" ) );
}
@Test
-public void excludedProjectsAreNotAddedWhenPropertyValueIsEmpty()
+public void SELECTEDProjectsAreNotAddedWhenPropertyValueIsEmpty()
Review comment:
That's clearly a typo !
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] gnodet commented on a change in pull request #444: [MNG-7095] Fix resume for parallel builds
gnodet commented on a change in pull request #444:
URL: https://github.com/apache/maven/pull/444#discussion_r575178829
##
File path:
maven-core/src/main/java/org/apache/maven/execution/BuildResumptionData.java
##
@@ -32,36 +29,20 @@
/**
* The project where the next build could resume from.
*/
-private final String resumeFrom;
-
-/**
- * List of projects to skip.
- */
-private final List projectsToSkip;
+private final List projectList;
Review comment:
I'll refactor this class to change the field name and fix the javadoc.
##
File path:
maven-core/src/main/java/org/apache/maven/execution/BuildResumptionData.java
##
@@ -32,36 +29,20 @@
/**
* The project where the next build could resume from.
*/
-private final String resumeFrom;
-
-/**
- * List of projects to skip.
- */
-private final List projectsToSkip;
+private final List projectList;
-public BuildResumptionData ( final String resumeFrom, final List
projectsToSkip )
+public BuildResumptionData ( final List projectList )
{
-this.resumeFrom = resumeFrom;
-this.projectsToSkip = projectsToSkip;
+this.projectList = projectList;
}
/**
- * Returns the project where the next build can resume from.
- * This is usually the first failed project in the order of the reactor.
- * @return An optional containing the group and artifact id of the
project. It does not make sense to resume
- * the build when the first project of the reactor has failed, so then
it will return an empty optional.
+ * Returns the projects that still need to be build when resuming.
Review comment:
See above
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] gnodet commented on a change in pull request #444: [MNG-7095] Fix resume for parallel builds
gnodet commented on a change in pull request #444:
URL: https://github.com/apache/maven/pull/444#discussion_r575178653
##
File path:
maven-core/src/main/java/org/apache/maven/execution/DefaultBuildResumptionAnalyzer.java
##
@@ -47,132 +41,49 @@
@Override
public Optional determineBuildResumptionData( final
MavenExecutionResult result )
{
-final List failedProjects = getFailedProjectsInOrder(
result );
-
-if ( failedProjects.isEmpty() )
+if ( !result.hasExceptions() )
{
-LOGGER.info( "No failed projects found, resuming the build would
not make sense." );
return Optional.empty();
}
-final MavenProject resumeFromProject = failedProjects.get( 0 );
-
-final String resumeFromSelector;
-final List projectsToSkip;
-if ( isFailedProjectFirstInBuild( result, resumeFromProject ) )
-{
-// As the first module in the build failed, there is no need to
specify this as the resumeFrom project.
-resumeFromSelector = null;
-projectsToSkip = determineProjectsToSkip( result, failedProjects,
0 );
-}
-else
-{
-resumeFromSelector = resumeFromProject.getGroupId() + ":" +
resumeFromProject.getArtifactId();
-List allProjects =
result.getTopologicallySortedProjects();
-int resumeFromProjectIndex = allProjects.indexOf(
resumeFromProject );
-projectsToSkip = determineProjectsToSkip( result, failedProjects,
resumeFromProjectIndex + 1 );
-}
-
-boolean canBuildBeResumed = StringUtils.isNotEmpty( resumeFromSelector
) || !projectsToSkip.isEmpty();
-if ( canBuildBeResumed )
-{
-return Optional.of( new BuildResumptionData( resumeFromSelector,
projectsToSkip ) );
-}
-else
-{
-return Optional.empty();
-}
-}
-
-private boolean isFailedProjectFirstInBuild( final MavenExecutionResult
result, final MavenProject failedProject )
-{
-final List sortedProjects =
result.getTopologicallySortedProjects();
-return sortedProjects.indexOf( failedProject ) == 0;
-}
-
-private List getFailedProjectsInOrder( MavenExecutionResult
result )
-{
List sortedProjects =
result.getTopologicallySortedProjects();
-return result.getExceptions().stream()
-.filter( LifecycleExecutionException.class::isInstance )
-.map( LifecycleExecutionException.class::cast )
-.map( LifecycleExecutionException::getProject )
-.filter( Objects::nonNull )
-.sorted( comparing( sortedProjects::indexOf ) )
-.collect( Collectors.toList() );
-}
-
-/**
- * Projects after the first failed project could have succeeded by using
-T or --fail-at-end.
- * These projects can be skipped from later builds.
- * This is not the case these projects are dependent on one of the failed
projects.
- * @param result The result of the Maven build.
- * @param failedProjects The list of failed projects in the build.
- * @param startFromProjectIndex Start looking for projects which can be
skipped from a certain index.
- * @return A list of projects which can be skipped in a later build.
- */
-private List determineProjectsToSkip( MavenExecutionResult result,
- List
failedProjects,
- int startFromProjectIndex )
-{
-List allProjects =
result.getTopologicallySortedProjects();
-List remainingProjects = allProjects.subList(
startFromProjectIndex, allProjects.size() );
-
-List failedProjectsGAList = failedProjects.stream()
-.map( GroupArtifactPair::new )
-.collect( Collectors.toList() );
-
-return remainingProjects.stream()
+long succeeded = sortedProjects.stream()
.filter( project -> result.getBuildSummary( project )
instanceof BuildSuccess )
-.filter( project -> hasNoDependencyOnProjects( project,
failedProjectsGAList ) )
-.map( project -> project.getGroupId() + ":" +
project.getArtifactId() )
-.collect( Collectors.toList() );
-}
-
-private boolean hasNoDependencyOnProjects( MavenProject project,
List projectsGAs )
-{
-return project.getDependencies().stream()
-.map( GroupArtifactPair::new )
-.noneMatch( projectsGAs::contains );
-}
-
-private static class GroupArtifactPair
-{
-private final String groupId;
-private final String artifactId;
-
-GroupArtifactPair( MavenProject project )
-{
-this.groupId = project.getGroupId();
-this.artifactId = project.getArtifactId();
-}
+.count();
-
[jira] [Created] (MNG-7098) Project counter should be cumulative when using resume
Robert Scholte created MNG-7098:
---
Summary: Project counter should be cumulative when using resume
Key: MNG-7098
URL: https://issues.apache.org/jira/browse/MNG-7098
Project: Maven
Issue Type: Improvement
Components: Reactor and workspace
Reporter: Robert Scholte
Fix For: 4.0.x-candidate
When doing a resume on a build, the counter now starts again at 1.
E.g. Suppose a project has 10 modules and the 7th module fails. With a resume
now you'll see {{[1/4]}}.
To me it makes more sense to say {{[7/10]}}. You're still as close to the end
as usual, but this indicates the size of the complete project.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [maven] mthmulders commented on a change in pull request #444: [MNG-7095] Fix resume for parallel builds
mthmulders commented on a change in pull request #444:
URL: https://github.com/apache/maven/pull/444#discussion_r575106537
##
File path:
maven-core/src/main/java/org/apache/maven/execution/BuildResumptionData.java
##
@@ -32,36 +29,20 @@
/**
* The project where the next build could resume from.
*/
-private final String resumeFrom;
-
-/**
- * List of projects to skip.
- */
-private final List projectsToSkip;
+private final List projectList;
Review comment:
The name of the variable is a bit vague, it doesn't clearly indicate
what kind of projects it contains. How about `remainingProjects`? Also, the
Javadoc is outdated - the Javadoc of the corresponding `getProjectList()` looks
a lot better.
##
File path:
maven-core/src/main/java/org/apache/maven/execution/BuildResumptionData.java
##
@@ -32,36 +29,20 @@
/**
* The project where the next build could resume from.
*/
-private final String resumeFrom;
-
-/**
- * List of projects to skip.
- */
-private final List projectsToSkip;
+private final List projectList;
-public BuildResumptionData ( final String resumeFrom, final List
projectsToSkip )
+public BuildResumptionData ( final List projectList )
{
-this.resumeFrom = resumeFrom;
-this.projectsToSkip = projectsToSkip;
+this.projectList = projectList;
}
/**
- * Returns the project where the next build can resume from.
- * This is usually the first failed project in the order of the reactor.
- * @return An optional containing the group and artifact id of the
project. It does not make sense to resume
- * the build when the first project of the reactor has failed, so then
it will return an empty optional.
+ * Returns the projects that still need to be build when resuming.
Review comment:
```suggestion
* Returns the projects that still need to be built when resuming.
```
##
File path: maven-embedder/src/main/java/org/apache/maven/cli/MavenCli.java
##
@@ -1032,20 +1031,6 @@ private int execute( CliRequest cliRequest )
{
logBuildResumeHint( "mvn -r" );
}
-else if ( !failedProjects.isEmpty() )
Review comment:
I don't understand why you removed this block.
##
File path:
maven-core/src/test/java/org/apache/maven/execution/DefaultBuildResumptionAnalyzerTest.java
##
@@ -133,6 +129,12 @@ private Dependency toDependency(MavenProject mavenProject )
return dependency;
}
+private MavenProject createSkippedMavenProject( String artifactId )
+{
+MavenProject project = createMavenProject( artifactId );
Review comment:
Method body can be one line as the outcome of `createMavenProject` is
not changed.
##
File path:
maven-core/src/main/java/org/apache/maven/execution/DefaultBuildResumptionAnalyzer.java
##
@@ -47,132 +41,49 @@
@Override
public Optional determineBuildResumptionData( final
MavenExecutionResult result )
{
-final List failedProjects = getFailedProjectsInOrder(
result );
-
-if ( failedProjects.isEmpty() )
+if ( !result.hasExceptions() )
{
-LOGGER.info( "No failed projects found, resuming the build would
not make sense." );
return Optional.empty();
}
-final MavenProject resumeFromProject = failedProjects.get( 0 );
-
-final String resumeFromSelector;
-final List projectsToSkip;
-if ( isFailedProjectFirstInBuild( result, resumeFromProject ) )
-{
-// As the first module in the build failed, there is no need to
specify this as the resumeFrom project.
-resumeFromSelector = null;
-projectsToSkip = determineProjectsToSkip( result, failedProjects,
0 );
-}
-else
-{
-resumeFromSelector = resumeFromProject.getGroupId() + ":" +
resumeFromProject.getArtifactId();
-List allProjects =
result.getTopologicallySortedProjects();
-int resumeFromProjectIndex = allProjects.indexOf(
resumeFromProject );
-projectsToSkip = determineProjectsToSkip( result, failedProjects,
resumeFromProjectIndex + 1 );
-}
-
-boolean canBuildBeResumed = StringUtils.isNotEmpty( resumeFromSelector
) || !projectsToSkip.isEmpty();
-if ( canBuildBeResumed )
-{
-return Optional.of( new BuildResumptionData( resumeFromSelector,
projectsToSkip ) );
-}
-else
-{
-return Optional.empty();
-}
-}
-
-private boolean isFailedProjectFirstInBuild( final MavenExecutionResult
result, final MavenProject failedProject )
-{
-final List sortedProjects =
result.getTopologicallySortedProjects();
-return sortedProjects.indexOf( failedProject ) == 0;
-}
-
-
