On Sun, 27 Oct 2019 at 15:10, 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.
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
