jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: Gradle equivalent of 'ant package'?
Date Mon, 28 Oct 2019 08:52:57 GMT
On Sun, 27 Oct 2019 at 15:10, Vladimir Sitnikov
<sitnikov.vladimir@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.

The Ant -p command provides an introductory description which shows
how to use it.
gradle does not provide any such details.

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

OK, I now understand what description you mean; generally they are OK.

Hopefully you also understand what I mean when I say that gradlew does
not provide and introduction and overall description.

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

If you use gradlew tasks |more, you get lots of lines of the form:

> Task :buildSrc:compileKotlin NO-SOURCE
> Task :buildSrc:compileJava NO-SOURCE
> Task :buildSrc:compileGroovy NO-SOURCE

etc.

If not using more, then the screen is updated for a while before the
help is displayed.

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

If I use -q then I agree, the initial lines don't appear, but you did
not say to use that.

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

But the Ant introduction is useful.

> 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

Yes, there are more taks, but that does not change the fact that the
Ant output was usable without any grouping.

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

They are not contradictory; also it may be useful to know what the
component names are.

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

The ant -p output is not designed for grepping, and generally does not
need it because the list is relatively short.

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

That is tangential, but it was deliberately a separate task with Ant,
because some of the jars had a separate license that needed agreement.
Hopefully the license issue is no longer the case.

> Gralde's task is easier to discover and its description is easier to
> understand.

There are two aspects to this:
- how to migrate from Ant to Gradle
- how to find individual Gradle tasks

The former question is where this thread started.
I don't think the migration aspect has been documented yet.
I think it needs to be addressed before the release is published.

It's wrong to produce a new release that uses a completely new build
system (and directory structure) without providing migration
information.
AFAICT there is none at present.



> Vladimir

Mime
View raw message