* back-to-back, as there is typically some work being done between the builds,</li>
     * <li>give file system events a chance to arrive; otherwise we might detect them during
     * the build, and invalidating the VFS,
     * <li>let VFS cleanup (that happens between builds) finish.</li>
     * </ul>
     */

                        queue.abortAllAndFail(t);
                    }
                    // Notify other threads that the item is finished as this may unblock further work
                    // or this might be the last item in the queue
                    coordinationService.notifyStateChange();
                });
            } finally {
                stats.finishMarkFinished();
            }
        }
    }

For example, if your Github account is named `foo` and your plugin is named `bar`, a suitable plugin ID might be `com.github.foo.bar`.
Similarly, if the plugin was developed at the `baz` organization, the plugin ID might be `org.baz.bar`.

Plugin IDs should adhere to the following guidelines:

- May contain any alphanumeric character, '.', and '-'.

            .withContext("These workspace directories are not supposed to be modified once they are created. " +
                "The modification might have been caused by an external process, or could be the result of disk corruption. " +
                String.format("The inconsistent workspace will be moved to '%s', and will be recreated.", failedWorkspaceLocation.getAbsolutePath()) +

            } catch (Exception e) {
                String message = "Unable to expand " + getDisplayName() + "\n"
                        + "  The tar might be corrupted or it is compressed in an unexpected way.\n"
                        + "  By default the tar tree tries to guess the compression based on the file extension.\n"

        //this way we avoid potential runaway daemons that steal resources on linux and break builds on windows.
        //We might leave that in if we decide it's a good idea for an extra safety net.
        int maxTimeout = 2 * 60 * 1000;
        if (daemonParameters.getIdleTimeout() > maxTimeout) {
            daemonParameters.setIdleTimeout(maxTimeout);

        // TODO:ADAM - restrict this to the specific path for the target tool
        invocationContext.addPath(visualCpp.getPath());
        invocationContext.addPath(sdk.getPath());
        // Clear environment variables that might effect cl.exe & link.exe
        clearEnvironmentVars(invocationContext, "INCLUDE", "CL", "LIBPATH", "LINK", "LIB");

        invocationContext.setArgAction(commandLineToolConfiguration.getArgAction());

        String configurationName,
        ComponentIdentifier componentId
    ) {
        // We hard-code the exception here since we do not currently support dynamically describing this type of failure.
        // It might make sense to do this for other similar failures that do not have dynamic failure handling.
        ConfigurationNotConsumableFailure failure = new ConfigurationNotConsumableFailure(configurationName, componentId.getDisplayName());

        result.assertHasErrorOutput("""None of the following functions can be called with the arguments supplied:${' '}
public operator fun DependencyCollector.invoke""") // Don't care what the other options are, just that it's the right name
    }

For instance, this plugin can be used to define a group of Integration Tests, which might run much longer than unit tests and have different environmental requirements.

NOTE: The JVM Test Suite plugin is an <<feature_lifecycle.adoc#sec:incubating_state,incubating>> API and is subject to change in a future release.