don't fail if fuzzOut isn't specified

[loosebazooka]

fixes #412

[vlsi]

The task should be Sync rather than Copy to remove stale files if some of the classes are removed from build to build

[vlsi]

Suggested change

	into(dest).from(sourceSets.main.get().runtimeClasspath)
	into(dest)
	from(sourceSets.main.get().runtimeClasspath)

[loosebazooka]

is this more idiomatic?

[vlsi]

I think so
They describe two different things:

1. where to store the data
2. which data to pick

For instance, if you would ever add the second from, then into(...).from(..).from(..) would look too long, while the following is fine:

into(...)
from(...)
from(...)

[vlsi]

Consider this:

    into(dest)
    into("abcd") {
        from(sourceSets.main.get().runtimeClasspath)
    }

=>

% tree build/fuzzOut
build/fuzzOut
└── abcd
    ├── animal-sniffer-annotations-1.21.jar
    ├── annotations-4.1.1.4.jar
    ├── bcpkix-jdk18on-1.72.jar
    ├── bcprov-jdk18on-1.72.jar

[loosebazooka]

hrmm.. I messed something up

[loosebazooka]

ah we can't use Sync because the fuzzer builder is putting other things in the directory before gradle executes
but it's a clean build each time, so this should be a safe operation

[vlsi]

Copying is inherently unsafe (sometime later one might end up with multiple bc-java jars having slightly different versions), so I would prefer:
a) explicitly mention which files should be preserved by sync. See https://github.com/apache/jmeter/blob/50e2015613752fbd0ceedc84440d0bea27848b91/src/dist/build.gradle.kts#L247-L255

or

b) document the reasons for having copy here

[loosebazooka]

I mean (a) seems a bit much, we know it's a clean build, so the concerns don't exactly apply. Yes technically that could happen, but it wont. Added in some comments.