jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Milamber <>
Subject Re: Gradle equivalent of 'ant package'?
Date Sun, 27 Oct 2019 19:11:48 GMT

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/ 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.


> Regards
> On Sunday, October 27, 2019, Vladimir Sitnikov <>
> 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

View raw message