I've refactored IDE/License/Release part of the scripts to a standalone repository: https://github.com/vlsi/vlsi-release-plugins
Gradle PR is updated: https://github.com/apache/jmeter/pull/469 The net diff is 1959 files changed, 4901 insertions(+), 10246 deletions(-) In other words, 5000 lines removed, and lots of new features added. Isn't that cool? Unfortunately, the my build plugins are "pending approval" on a Gradle Plugin Portal, so if you want to try the new Gradle build, you need to clone vlsi-release-plugins. However, linking two projects together is super-simple: you just need to have jmeter and vlsi-release-plugins folders side by side, and jmeter/settings.gradle.kts does the linking (it has `importBuild(...)`). The new build scripts help with License validation as per https://www.apache.org/legal/resolved.html As you've seen it helped me to identify a couple of violations which are currently ignored via failOnIncompatibleLicense.set(false) Here's how licenses are declared: https://github.com/vlsi/jmeter/blob/gradle/src/licenses/build.gradle.kts#L30 Note: the build script automatically extracts license/notice files from jar files, so only missing files should be placed to JMeter source control. I've created a set of issues so downstream projects would hopefully bundle license files so we could remove them. Vladimir> Most of the time it is figuring out "if the test is a unit test that Vladimir> requires just a couple of classes" or "if it is an integration test" that Vladimir> requires full JMeter installation. Here's an example of recent changes that required certain updates for the new folder layout: https://github.com/apache/jmeter/pull/469/commits/61da645a1beadcc9190f96ccf327d66c00a62a23 Basically those tests were located in "core" package, however they used GUI classes, and classes from components. I think it is nice that new layout prevents this kind of accidental class misuse. Vladimir
