When maven is packaged, a series of problems are caused by slow clean

    I don't know if you have noticed that maven's clean process is a bit slow. When there are multiple modules that need to be packaged with this, the clean time cannot be underestimated. Then someone killed clean, and it was used for a period of time without any problems. Then everyone felt that this version had problems, so they uploaded many previous packages to this version. A lot of problems were caused by not deleting the target. The interview is to use java to traverse the folder to delete it, but it is still very slow. So I thought of calling the command of the operating system to delete the folder to operate. The plan is as follows:
    

private void commandDelFolder(String folderPath, Writer writer) {
        String[] cmds = new String[3];
        boolean isWindows = PropertyHolder.get().isWindows();
        if (isWindows) {
            cmds[0] = "cmd.exe";
            cmds[1] = "/c";
            cmds[2] = " rd /s /q " + folderPath;
        } else {
            cmds[0] = "/bin/sh";
            cmds[1] = "-c";
            cmds[1] = " rm -rf " + folderPath;
        }
        try {
            Process process = Runtime.getRuntime().exec(cmds);
            exeProcess(process, writer);
        } catch (IOException e) {
            logger.error(e.getMessage(), e);
            throw new GenerateException(e);
        }
    }

    After using it, the deletion speed is very fast, and the folders with hundreds of megabytes are deleted in a few seconds. It has been used for a long time without any problems, but the test side often uses the service environment, the service environment and the bat environment, and their configuration files are different. Check other problems and find that there are "file name directory name or volume label in the log" "Incorrect syntax" prompt, thinking that this kind of problem is very serious, quickly check this problem, first add the debug port, tried several methods without success, no way, only print cmds through log.info, Later, it was found that there was indeed a problem with the path. When the service was started, I spelled some more things, and then modified the configuration file of the service environment. Thinking that I may be taking an unusual path, otherwise, if others took the path in this way, they should not have reported an error long ago.