Embed Javadoc of dependencies in application

[Rylern]

This PR makes the jpackage gradle task put the Javadocs of all dependencies alongside the Javadocs of QuPath when creating the executable (in Content/app/docs for MacOS for example).

This adds 279.8 MB to the size of the executable, so it may be better to skip some dependencies.

[alanocallaghan]

Might be an idea to do releases with & without javadocs as I guess many users won't use scripting at all

[petebankhead]

Great! Yes, I think we shouldn't increase the download by too much. My suggestion is to use a command line flag e.g. -Pdocs=all to activate this. Possible options:

• all - all javadocs, devs building locally may (rarely) want this
• none - don't include any javadocs
• qupath - jars that include qupath as the first element in the name only (should include extensions)
• default - curated list of jars; I'd say qupath + JTS + ImageJ as a starting point

I think the default list should only add ~10MB or so.

This also allows the gradle to be simplified and mergedJavadocs can be removed as a task (in preparation for a nicer javadoc viewer).

Note: Currently, I can't build this PR fully with ./gradlew jpackage because I get either

The specified installation directory '/path/to/qupath/qupath-app/build/install/QuPath-0.6.0-SNAPSHOT' is neither empty nor does it contain an installation for 'QuPath-0.6.0-SNAPSHOT'.

or (if I delete that directory)

Entry lib/qupath-gui-fx-0.6.0-SNAPSHOT.jar is a duplicate but no duplicate handling strategy has been set. Please refer to https://docs.gradle.org/8.7/dsl/org.gradle.api.tasks.Copy.html#org.gradle.api.tasks.Copy:duplicatesStrategy for details.

[Rylern]

I added the command line flags and removed the mergedJavadocs task.

About the error, I wasn't able to reproduce it but I added a duplicate handling strategy that should fix it.

Opening the results of the new task with the javadoc viewer seems to work correctly.

[petebankhead]

When I build QuPath with ./gradlew jpackage I'm only getting the non-core QuPath jars (qupath-bioimageio-spec and qupath-fxtras).

I also don't see any javadocs if I call ./gradlew run; it would be nice if they could be available, but it isn't crucial since the normal use will be via jpackage builds.

Lastly, when I open the Javadoc viewer, I see this:

It resolves if I click on the link: the expected page loads at that point.

I'm not sure if these can/should be addressed within the current PR - happy to merge this one now if you like, so that we can switch to the new Javadoc viewer and resolve anything that remains at that point.

[Rylern]

When I build QuPath with ./gradlew jpackage I'm only getting the non-core QuPath jars (qupath-bioimageio-spec and qupath-fxtras).

Does it also happen with ./gradlew clean jpackage? Since it's a Copy task it's safer to clean before.

I also don't see any javadocs if I call ./gradlew run; it would be nice if they could be available, but it isn't crucial since the normal use will be via jpackage builds.

Added with last commit.

Lastly, when I open the Javadoc viewer, I see this:

There is an automatic redirection that is not triggered on the old Javadoc viewer. It seems to work on the new Javadoc viewer, can you check if it also works on your side?

[Rylern]

I also don't see any javadocs if I call ./gradlew run; it would be nice if they could be available, but it isn't crucial since the normal use will be via jpackage builds.

Actually this increases the startup time by a few seconds each time I run QuPath after changing something, which is quite annoying. Should we remove that feature?

[petebankhead]

Would there be a way to associate it with a task that isn't required for run (e.g. assemble or processResources), which puts the docs into the required place - but wouldn't be called for someone calling ./gradlew run alone?

Not sure if this is an option, but ./gradlew run --dry-run shows the tasks that will be run.

If it's not straightforward, I agree that the delay of a few seconds is more annoying than the benefit for the javadocs - so better not to generate them.

Edit: simpler alternative to the above might be to just require a separate task to be called if the javadocs should be generated (but which jpackage probably still depends upon, either directly or indirectly).

[Rylern]

You can call the newly created task directly (./gradlew clean getJavadocs)