On 27/10/2019 19:52, Philippe Mouawad wrote:
Hello, Although at first it might look more complex when used to ant, in the end IME it improves many fields: - IDE configuration - dependency management - The description looked helpful to me and the grouping was also welcome As of me, I find this part (build) has clearly improved following gradle migration and should ease contributions as gradle and maven are the 2 standards nowadays. Milamber can give his feedback on release management, but from an external eye it looks simpler and more productive to me.
Yes, it's more easy with the gradle script to prepare the release candidate (RC) (thanks Vladimir again!). Before, with the ant release way, ~21 command lines to execute to prepare the Vote email After, with the gradle way, 1 command line(*) : ./gradlew prepareVote -Prc=4 -Pasf -PuseGpgCmd (I don't tested the command(s) to release after a successfully vote, so I don't know the number of commands to execute currently)
(*): to have only this 1 cmd line, you need to fill some requirements around git repo (gitbox/github), credentials (.netrc), username/password (~/.gradle/gradle.properties) and pgp key, but only for the first process on your machine.
Note: After the release of 5.2 (final), I will update the wiki page about the release creation to document this new (easy) process.
Milamber
Regards On Sunday, October 27, 2019, Vladimir Sitnikov <sitnikov.vladi...@gmail.com> wrote:sebb>AFAICT there are 74 actual tasks, plus 3 pattern rules sebb>..., and no helpful description That is not fun. Please refrain from replying with "no helpful description" in case you provide no samples. You have started the email thread with "cannot work out how to do `ant package` with gradle". I suggested the task in the very first reply (which was sent within 15 minutes by the way): createDist - Copies JMeter jars and dependencies to projectRoot/lib/ folder Do you really think the description is not helpful? Do you really think the description from ant is any better? package Compile everything and create the jars The very same createDist task is visible in ./gradlew tasks output, so it is not something hidden. Vladimir> Do you have suggestions on improving the description? sebb>No idea what description you mean. The description for createDist task in the build script. The current description is as follows createDist - Copies JMeter jars and dependencies to projectRoot/lib/ folder I'm sure it properly explains the task, however, it seems you've missed it somehow in "gradlew tasks" output. sebb>There is a lot of irrelevant output that appears first. Would you please care to pin-point the exact lines and the amount of "a lot"? sebb>It produces 182 lines for me, and includes quite a lot of irrelevant I'm afraid you are counting it wrong. Please count manually (line by line from the interactive console). Or use -q option if you happen to count with `wc` as follows: "gradlew -q tasks | wc -l". `-q tasks` produces 125 lines for me which not much longer than 101 of `ant -p` sebb>Of which half are description and introduction The "introduction" is printed every time, so you are not playing a fair game if you skip counting half of Ant's output, while you include full Gradle output (especially taking into account that you count invisible lines like "> Task :buildSrc:"). Please be consistent. sebb>That was not really necessary before, as the list was relatively short I'm afraid you are not quite right here. The new list is longer because it contains may new features: * license management: renderLicenseForBinary, renderLicenseForSource * autoformat source code: spotlessApply / style * verify source code style: spotlessCheck * pom file generation: generatePom * publish jars to local Maven repository (== $home/.m2): publishToMavenLocal * reports on the dependency tree ("Help tasks") * understandable tasks for building artifacts: distTar / distTarSource / distZip / distZipSource * code coverage report * preview site and so on sebb>ant -p is quite usable when displayed on the console sebb>a lot of them are similar (e.g. the compile-xxx tasks) The two statements contradict each other. There's no much sense in printing individual compile-* tasks every time. $ ant -p | grep lib To create a nightly build (separate bin/src/lib jars): ^^^ not a single task suggests the way to populate lib/ folder $ ant -p | grep jar To download additional jars needed for building the code and documentation: ant download_jars To create a nightly build (separate bin/src/lib jars): check_jars Check that all required jar files are present download_jars Download any missing jar files generator_jar Create the test tree generator jar install Install JMeter. (Compiles code and creates jars) maven_upload Upload Maven jars and poms (and sigs if present) to Nexus. package Compile everything and create the jars package-and-check Compile, create jars and apply checkstyle before committing code run_gui Run the JMeter GUI off the jar files It does not clarify how "install" is different from "package" It does not clarify which tasks are needed to populate lib/ folder. It does not clarify the required order of the task execution. In other words, the very same use case "populate lib/ folder" is simpler with Gradle (download_jars is obsolete and it is automatic with Gradle), Gralde's task is easier to discover and its description is easier to understand. Vladimir
