jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vladimir Sitnikov <>
Subject Re: Gradle equivalent of 'ant package'?
Date Sun, 27 Oct 2019 15:09:51 GMT
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

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

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


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message