You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@maven.apache.org by "gnodet (via GitHub)" <gi...@apache.org> on 2026/09/26 16:40:10 UTC
[PR] fix: honour failOnError in fast mode by running deletion synchronously (fixes #352) [maven-clean-plugin]
gnodet opened a new pull request, #355:
URL: https://github.com/apache/maven-clean-plugin/pull/355
## Problem
When `-Dmaven.clean.fast=true` is set, `failOnError=true` (the default) silently had no effect: deletion failures were logged as warnings but the build succeeded. This is the issue described in #352.
## Root cause
The deletion ran inside a background executor thread, and errors were only surfaced at session end through `errorOccurred()` → `run()` → `logger.warn(...)`. A session-end listener cannot structurally fail the build (Maven swallows whatever it throws).
## Fix — option 2 from #352
When `failOnError=true`, `BackgroundCleaner.fastDelete()` now runs the file deletion **synchronously in the calling thread** instead of submitting it to the background executor. The atomic directory move (the "fast" part) still happens, so the build thread is unblocked from its own work immediately; only the actual file deletion blocks until done. Any `IOException` from the deletion is thrown immediately and propagated by `CleanMojo` as a `MojoException`.
When `failOnError=false`, deletion remains fully asynchronous (existing behaviour): errors are accumulated and logged as warnings at session end.
## Key changes
- `BackgroundCleaner.fastDelete()` gains a `failOnError` parameter.
- `deleteInBackground()` now returns `IOException` (null = success) instead of `void`, allowing the synchronous path to propagate errors and the async path to route them through `errorOccurred()`.
- `Cleaner.fastDelete()` threads `failOnError` through to `BackgroundCleaner`.
- `CleanMojo` / `BackgroundCleaner` Javadoc updated: removed all "failOnError has no effect in fast mode" notes.
- `CleanerTest.java`: fixed a pre-existing missing `}` / `/**` pair (introduced in a03c4d7) that caused a compilation failure.
- `BackgroundCleanerTest`: two new tests verify the new behaviour (`failOnErrorThrowsWhenDeletionFails`, `failOnErrorFalseDoesNotThrowWhenDeletionFails`).
Closes #352
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@maven.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] fix: clarify that failOnError has no effect in fast mode (fixes #352) [maven-clean-plugin]
Posted by "gnodet-bot (via GitHub)" <gi...@apache.org>.
gnodet-bot commented on code in PR #355:
URL: https://github.com/apache/maven-clean-plugin/pull/355#discussion_r4120951137
##########
src/it/fast-delete/verify.groovy:
##########
@@ -29,4 +29,7 @@ if ( new File( basedir, ".fastdir" ).exists() )
}
File buildLog = new File(basedir, 'build.log')
-return buildLog.text.contains('mvn-background-cleaner')
+// With failOnError=true (the default), deletion runs synchronously — the
+// background cleaner thread name won't appear. Verify that the fast-delete
+// path was used by checking for the staging-directory debug message.
Review Comment:
💡 **Same stale comment** — deletion does not run synchronously in fast mode.
```suggestion
// The old thread-name check ('mvn-background-cleaner') was brittle. Instead,
// verify the fast-delete path was used by checking for the debug message
// emitted by deleteInBackground().
```
##########
src/it/fast-delete-default/verify.groovy:
##########
@@ -24,4 +24,7 @@ if ( new File( basedir, "target" ).exists() )
}
File buildLog = new File(basedir, 'build.log')
-return buildLog.text.contains('mvn-background-cleaner')
+// With failOnError=true (the default), deletion runs synchronously — the
+// background cleaner thread name won't appear. Verify that the fast-delete
+// path was used by checking for the staging-directory debug message.
Review Comment:
💡 **Stale comment from intermediate commits.** This PR no longer makes deletion synchronous when `failOnError=true` — deletion is always asynchronous in fast mode. The real reason the thread name check was replaced is that the old `mvn-background-cleaner` thread name assertion was brittle; the debug message works regardless of execution mode.
```suggestion
// The old thread-name check ('mvn-background-cleaner') was brittle. Instead,
// verify the fast-delete path was used by checking for the debug message
// emitted by deleteInBackground().
```
##########
src/it/fast-delete-multi-module/verify.groovy:
##########
@@ -31,8 +31,11 @@ assert !new File( basedir, 'module-noforce/target' ).exists() : 'module-noforce/
// The shared staging directory should be cleaned after the session ends
assert !new File( basedir, '.fastdir' ).exists() : '.fastdir staging directory should have been deleted'
-// The background cleaner thread must have been used (proves session-scoped sharing)
-assert log.contains( 'mvn-background-cleaner' ) : 'expected background cleaner thread name in log'
+// The background cleaner must have been used (proves session-scoped sharing)
+// With failOnError=true (the default), deletion runs synchronously so the
+// background cleaner thread name won't appear. Check for the staging-directory
+// debug message instead.
+assert log.contains( 'in background' ) : 'expected background cleaner staging message in log'
Review Comment:
💡 **Same stale comment** — deletion does not run synchronously in fast mode.
```suggestion
// The old thread-name check ('mvn-background-cleaner') was brittle. Instead,
// verify the fast-delete path was used by checking for the debug message
// emitted by deleteInBackground().
assert log.contains( 'in background' ) : 'expected background cleaner staging message in log'
```
##########
src/it/read-only-fast/verify.groovy:
##########
@@ -29,4 +29,7 @@ if (new File(basedir, ".fastdir").exists()) {
}
File buildLog = new File(basedir, 'build.log')
-return buildLog.text.contains('mvn-background-cleaner')
+// With failOnError=true (the default), deletion runs synchronously — the
+// background cleaner thread name won't appear. Verify that the fast-delete
+// path was used by checking for the staging-directory debug message.
Review Comment:
💡 **Same stale comment** — deletion does not run synchronously in fast mode.
```suggestion
// The old thread-name check ('mvn-background-cleaner') was brittle. Instead,
// verify the fast-delete path was used by checking for the debug message
// emitted by deleteInBackground().
```
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@maven.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] fix: clarify that failOnError has no effect in fast mode (fixes #352) [maven-clean-plugin]
Posted by "gnodet (via GitHub)" <gi...@apache.org>.
gnodet commented on code in PR #355:
URL: https://github.com/apache/maven-clean-plugin/pull/355#discussion_r4120959821
##########
src/test/java/org/apache/maven/plugins/clean/BackgroundCleanerTest.java:
##########
@@ -346,16 +346,15 @@ void scanForLeftoversIsNoOpWhenFastDirAbsent(@TempDir Path tempDir) throws IOExc
}
// -----------------------------------------------------------------------
- // failOnError — background path cannot structurally fail the build
+ // async path logs warnings instead of throwing
// -----------------------------------------------------------------------
/**
* Background deletion failures must be logged as warnings without throwing.
*
- * <p>{@code failOnError} has no effect when {@code fast=true}: a session-end listener cannot
- * structurally fail the build — Maven catches whatever a listener throws and downgrades it to
- * a warning. This test verifies that errors are reported as warnings and that {@code onEvent}
- * returns normally.</p>
+ * <p>When {@code failOnError=false}, the deletion is offloaded to the background executor
+ * thread. This test verifies that errors in that path are reported as warnings and that
+ * {@code onEvent} returns normally.</p>
Review Comment:
Fixed in 835d16c.
##########
src/it/fast-delete-default/verify.groovy:
##########
@@ -24,4 +24,7 @@ if ( new File( basedir, "target" ).exists() )
}
File buildLog = new File(basedir, 'build.log')
-return buildLog.text.contains('mvn-background-cleaner')
+// With failOnError=true (the default), deletion runs synchronously — the
+// background cleaner thread name won't appear. Verify that the fast-delete
+// path was used by checking for the staging-directory debug message.
Review Comment:
Fixed in 835d16c.
##########
src/it/fast-delete/verify.groovy:
##########
@@ -29,4 +29,7 @@ if ( new File( basedir, ".fastdir" ).exists() )
}
File buildLog = new File(basedir, 'build.log')
-return buildLog.text.contains('mvn-background-cleaner')
+// With failOnError=true (the default), deletion runs synchronously — the
+// background cleaner thread name won't appear. Verify that the fast-delete
+// path was used by checking for the staging-directory debug message.
Review Comment:
Fixed in 835d16c.
##########
src/it/fast-delete-multi-module/verify.groovy:
##########
@@ -31,8 +31,11 @@ assert !new File( basedir, 'module-noforce/target' ).exists() : 'module-noforce/
// The shared staging directory should be cleaned after the session ends
assert !new File( basedir, '.fastdir' ).exists() : '.fastdir staging directory should have been deleted'
-// The background cleaner thread must have been used (proves session-scoped sharing)
-assert log.contains( 'mvn-background-cleaner' ) : 'expected background cleaner thread name in log'
+// The background cleaner must have been used (proves session-scoped sharing)
+// With failOnError=true (the default), deletion runs synchronously so the
+// background cleaner thread name won't appear. Check for the staging-directory
+// debug message instead.
+assert log.contains( 'in background' ) : 'expected background cleaner staging message in log'
Review Comment:
Fixed in 835d16c.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@maven.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] fix: clarify that failOnError has no effect in fast mode (fixes #352) [maven-clean-plugin]
Posted by "desruisseaux (via GitHub)" <gi...@apache.org>.
desruisseaux commented on code in PR #355:
URL: https://github.com/apache/maven-clean-plugin/pull/355#discussion_r4122427409
##########
src/it/fast-delete-default/verify.groovy:
##########
@@ -24,4 +24,7 @@ if ( new File( basedir, "target" ).exists() )
}
File buildLog = new File(basedir, 'build.log')
-return buildLog.text.contains('mvn-background-cleaner')
+// The old thread-name check ('mvn-background-cleaner') was brittle. Instead,
Review Comment:
We don't need to talk about the old name. For someone reading the new code where the old name has disappeared, it is only noise.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@maven.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] fix: clarify that failOnError has no effect in fast mode (fixes #352) [maven-clean-plugin]
Posted by "gnodet (via GitHub)" <gi...@apache.org>.
gnodet merged PR #355:
URL: https://github.com/apache/maven-clean-plugin/pull/355
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@maven.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] fix: honour failOnError in fast mode by running deletion synchronously (fixes #352) [maven-clean-plugin]
Posted by "gnodet (via GitHub)" <gi...@apache.org>.
gnodet commented on code in PR #355:
URL: https://github.com/apache/maven-clean-plugin/pull/355#discussion_r4112204146
##########
src/test/java/org/apache/maven/plugins/clean/BackgroundCleanerTest.java:
##########
@@ -345,6 +345,73 @@ void scanForLeftoversIsNoOpWhenFastDirAbsent(@TempDir Path tempDir) throws IOExc
assertNotNull(bc);
}
+ // -----------------------------------------------------------------------
+ // failOnError=true — synchronous deletion that fails the build
+ // -----------------------------------------------------------------------
+
+ /**
+ * When {@code failOnError=true} and the deletion fails, {@link BackgroundCleaner#fastDelete}
+ * must throw an {@link IOException} synchronously so that the build can be failed.
+ * This verifies that {@code failOnError} now works correctly in fast mode (fixes #352).
+ */
+ @Test
+ @DisabledOnOs(OS.WINDOWS)
+ void failOnErrorThrowsWhenDeletionFails(@TempDir Path tempDir) throws Exception {
+ Path fastDir = tempDir.resolve(".clean");
+ Path target = createDirectory(tempDir.resolve("target"));
+ Path subDir = createDirectory(target.resolve("subdir"));
+ createFile(subDir.resolve("file.txt"));
+ // Make the directory read-only so deletion of its contents fails (force=false).
+ Files.setPosixFilePermissions(subDir, PosixFilePermissions.fromString("r-xr-xr-x"));
+
+ Log log = mock(Log.class);
+ Session session = mockSession(null);
+
+ BackgroundCleaner bc = BackgroundCleaner.getOrCreate(session, log, fastDir, FastMode.BACKGROUND);
+ try {
+ // failOnError=true must cause fastDelete to throw synchronously.
+ org.junit.jupiter.api.Assertions.assertThrows(
+ IOException.class,
+ () -> bc.fastDelete(target, false, false, true),
+ "fastDelete with failOnError=true must throw when deletion fails");
+ } finally {
+ makeWritableRecursively(tempDir);
+ }
+ }
+
+ /**
+ * When {@code failOnError=false} and the deletion fails, {@link BackgroundCleaner#fastDelete}
+ * must return normally (error is logged as a warning at session end, not propagated).
+ * This is the existing behaviour for the asynchronous path.
+ */
+ @Test
+ @DisabledOnOs(OS.WINDOWS)
+ void failOnErrorFalseDoesNotThrowWhenDeletionFails(@TempDir Path tempDir) throws Exception {
+ Path fastDir = tempDir.resolve(".clean");
+ Path target = createDirectory(tempDir.resolve("target"));
+ Path subDir = createDirectory(target.resolve("subdir"));
+ createFile(subDir.resolve("file.txt"));
+ Files.setPosixFilePermissions(subDir, PosixFilePermissions.fromString("r-xr-xr-x"));
+
+ Log log = mock(Log.class);
+ ArgumentCaptor<Listener> captor = ArgumentCaptor.forClass(Listener.class);
+ Session session = mockSession(captor);
+
+ BackgroundCleaner bc = BackgroundCleaner.getOrCreate(session, log, fastDir, FastMode.BACKGROUND);
+ try {
+ // failOnError=false: fastDelete must not throw; error is reported as a warning.
+ bc.fastDelete(target, false, false, false);
+
+ Event event = mock(Event.class);
+ when(event.getType()).thenReturn(EventType.SESSION_ENDED);
+ // Must not throw; error is logged as a warning.
+ captor.getValue().onEvent(event);
+ verify(log, atLeastOnce()).warn(any(CharSequence.class), any(Throwable.class));
+ } finally {
+ makeWritableRecursively(tempDir);
+ }
+ }
+
// -----------------------------------------------------------------------
// failOnError — background path cannot structurally fail the build
Review Comment:
Fixed in 77af0ea.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@maven.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] fix: clarify that failOnError has no effect in fast mode (fixes #352) [maven-clean-plugin]
Posted by "gnodet-bot (via GitHub)" <gi...@apache.org>.
gnodet-bot commented on code in PR #355:
URL: https://github.com/apache/maven-clean-plugin/pull/355#discussion_r4120943734
##########
src/test/java/org/apache/maven/plugins/clean/BackgroundCleanerTest.java:
##########
@@ -346,16 +346,15 @@ void scanForLeftoversIsNoOpWhenFastDirAbsent(@TempDir Path tempDir) throws IOExc
}
// -----------------------------------------------------------------------
- // failOnError — background path cannot structurally fail the build
+ // async path logs warnings instead of throwing
// -----------------------------------------------------------------------
/**
* Background deletion failures must be logged as warnings without throwing.
*
- * <p>{@code failOnError} has no effect when {@code fast=true}: a session-end listener cannot
- * structurally fail the build — Maven catches whatever a listener throws and downgrades it to
- * a warning. This test verifies that errors are reported as warnings and that {@code onEvent}
- * returns normally.</p>
+ * <p>When {@code failOnError=false}, the deletion is offloaded to the background executor
+ * thread. This test verifies that errors in that path are reported as warnings and that
+ * {@code onEvent} returns normally.</p>
Review Comment:
💡 **Stale Javadoc:** This paragraph still conditions the background offloading on `failOnError=false`, but `failOnError` no longer has any effect in fast mode — the deletion is *always* background. Suggested replacement:
```suggestion
* <p>In fast mode, the deletion is always offloaded to the background executor thread.
* This test verifies that errors in that path are reported as warnings and that
* {@code onEvent} returns normally.</p>
```
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@maven.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] fix: honour failOnError in fast mode by running deletion synchronously (fixes #352) [maven-clean-plugin]
Posted by "gnodet-bot (via GitHub)" <gi...@apache.org>.
gnodet-bot commented on code in PR #355:
URL: https://github.com/apache/maven-clean-plugin/pull/355#discussion_r4112161957
##########
src/test/java/org/apache/maven/plugins/clean/BackgroundCleanerTest.java:
##########
@@ -345,6 +345,73 @@ void scanForLeftoversIsNoOpWhenFastDirAbsent(@TempDir Path tempDir) throws IOExc
assertNotNull(bc);
}
+ // -----------------------------------------------------------------------
+ // failOnError=true — synchronous deletion that fails the build
+ // -----------------------------------------------------------------------
+
+ /**
+ * When {@code failOnError=true} and the deletion fails, {@link BackgroundCleaner#fastDelete}
+ * must throw an {@link IOException} synchronously so that the build can be failed.
+ * This verifies that {@code failOnError} now works correctly in fast mode (fixes #352).
+ */
+ @Test
+ @DisabledOnOs(OS.WINDOWS)
+ void failOnErrorThrowsWhenDeletionFails(@TempDir Path tempDir) throws Exception {
+ Path fastDir = tempDir.resolve(".clean");
+ Path target = createDirectory(tempDir.resolve("target"));
+ Path subDir = createDirectory(target.resolve("subdir"));
+ createFile(subDir.resolve("file.txt"));
+ // Make the directory read-only so deletion of its contents fails (force=false).
+ Files.setPosixFilePermissions(subDir, PosixFilePermissions.fromString("r-xr-xr-x"));
+
+ Log log = mock(Log.class);
+ Session session = mockSession(null);
+
+ BackgroundCleaner bc = BackgroundCleaner.getOrCreate(session, log, fastDir, FastMode.BACKGROUND);
+ try {
+ // failOnError=true must cause fastDelete to throw synchronously.
+ org.junit.jupiter.api.Assertions.assertThrows(
+ IOException.class,
+ () -> bc.fastDelete(target, false, false, true),
+ "fastDelete with failOnError=true must throw when deletion fails");
+ } finally {
+ makeWritableRecursively(tempDir);
+ }
+ }
+
+ /**
+ * When {@code failOnError=false} and the deletion fails, {@link BackgroundCleaner#fastDelete}
+ * must return normally (error is logged as a warning at session end, not propagated).
+ * This is the existing behaviour for the asynchronous path.
+ */
+ @Test
+ @DisabledOnOs(OS.WINDOWS)
+ void failOnErrorFalseDoesNotThrowWhenDeletionFails(@TempDir Path tempDir) throws Exception {
+ Path fastDir = tempDir.resolve(".clean");
+ Path target = createDirectory(tempDir.resolve("target"));
+ Path subDir = createDirectory(target.resolve("subdir"));
+ createFile(subDir.resolve("file.txt"));
+ Files.setPosixFilePermissions(subDir, PosixFilePermissions.fromString("r-xr-xr-x"));
+
+ Log log = mock(Log.class);
+ ArgumentCaptor<Listener> captor = ArgumentCaptor.forClass(Listener.class);
+ Session session = mockSession(captor);
+
+ BackgroundCleaner bc = BackgroundCleaner.getOrCreate(session, log, fastDir, FastMode.BACKGROUND);
+ try {
+ // failOnError=false: fastDelete must not throw; error is reported as a warning.
+ bc.fastDelete(target, false, false, false);
+
+ Event event = mock(Event.class);
+ when(event.getType()).thenReturn(EventType.SESSION_ENDED);
+ // Must not throw; error is logged as a warning.
+ captor.getValue().onEvent(event);
+ verify(log, atLeastOnce()).warn(any(CharSequence.class), any(Throwable.class));
+ } finally {
+ makeWritableRecursively(tempDir);
+ }
+ }
+
// -----------------------------------------------------------------------
// failOnError — background path cannot structurally fail the build
Review Comment:
Stale Javadoc: this section header (and the Javadoc at lines 419-425) still says _"failOnError has no effect when fast=true"_ and _"a session-end listener cannot structurally fail the build"_. That was the old behavior; this PR specifically fixes it. The test now exercises the `failOnError=false` async path, so the doc should be updated to match (e.g. _"failOnError=false: async path logs warnings instead of throwing"_).
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@maven.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] fix: honour failOnError in fast mode and warn on conflicting configuration (fixes #352) [maven-clean-plugin]
Posted by "gnodet-bot (via GitHub)" <gi...@apache.org>.
gnodet-bot commented on code in PR #355:
URL: https://github.com/apache/maven-clean-plugin/pull/355#discussion_r4120797117
##########
src/main/java/org/apache/maven/plugins/clean/CleanMojo.java:
##########
@@ -274,6 +273,12 @@ public void execute() {
Cleaner cleaner =
new Cleaner(matcherFactory, logger, isVerbose(), followSymLinks, force, failOnError, retryOnError);
if (fast && session != null) {
+ if (failOnError) {
+ logger.warn("Fast clean is enabled with failOnError=true (the default): file deletion will run"
+ + " synchronously in the calling thread so that errors can fail the build immediately."
+ + " To enable fully asynchronous deletion, set failOnError=false"
+ + " (errors will then be reported as warnings at session end).");
+ }
Review Comment:
⚠️ **Warning-level log on every default build is too noisy.**
`failOnError=true` is the default, `fast=true` is the recommended mode — this warning fires on **every single build** that uses fast clean without explicit `failOnError=false`. That's not an exceptional condition; it's the expected default configuration.
Concerns:
- Users who intentionally want the default behaviour get an undismissable warning on every build
- The message reads like a suggestion to change config ("set failOnError=false"), which is misleading — the default should be the safe choice, not something that generates warnings
- This will generate noise in CI logs and likely trigger user reports
Options:
1. **Remove the warning entirely** — the Javadoc on `fast` and `failOnError` already documents the interaction. Users who read the docs know what they're getting.
2. **Downgrade to `debug`** — visible with `-X` for troubleshooting, silent otherwise.
3. **Log `info` once per session** (not per module) — if you want visibility, guard it with a session-scoped flag so multi-module builds don't repeat it N times.
Option 2 or 3 would be my recommendation. A `warn` on the default config path is a code smell.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@maven.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] fix: honour failOnError in fast mode by running deletion synchronously (fixes #352) [maven-clean-plugin]
Posted by "gnodet (via GitHub)" <gi...@apache.org>.
gnodet commented on PR #355:
URL: https://github.com/apache/maven-clean-plugin/pull/355#issuecomment-5848455977
Both review findings addressed in 77af0ea:
1. Fixed stale `@link` in `BackgroundCleaner.java` (line 57): updated to 4-parameter signature.
2. Updated test Javadoc in `BackgroundCleanerTest.java` (lines 416–425): reflects the new `failOnError=false` async-path semantics.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@maven.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] fix: clarify that failOnError has no effect in fast mode (fixes #352) [maven-clean-plugin]
Posted by "gnodet (via GitHub)" <gi...@apache.org>.
gnodet commented on code in PR #355:
URL: https://github.com/apache/maven-clean-plugin/pull/355#discussion_r4122458340
##########
src/it/fast-delete-default/verify.groovy:
##########
@@ -24,4 +24,7 @@ if ( new File( basedir, "target" ).exists() )
}
File buildLog = new File(basedir, 'build.log')
-return buildLog.text.contains('mvn-background-cleaner')
+// The old thread-name check ('mvn-background-cleaner') was brittle. Instead,
Review Comment:
Good point, removed the stale references to the old thread-name in all four verify scripts. Fixed in b94bdb5.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@maven.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org