RFR: 8370100: Redundant .png files in Linux app-image cause unnecessary bloat [v2]

[Alexey Semenyuk]

On Mon, 27 Oct 2025 22:33:57 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

>> This is the same task but with a disabled action. Task graph doesn't allow multiple tasks with the same ID.
>> 
>> By default, the `LAUNCHER_ICONS` task copies launcher icon files to the app image. However, when bundling a native package, this action should not be executed because the `DesktopIntegration` class adds launcher icons to the package.
>> 
>> Before this change, jpackage copied launcher icon files twice when building a native package: in `LAUNCHER_ICONS` task and in `DesktopIntegration` class.
>> 
>> Function name `add()` is confusing. Should be `apply()` or `commit()`.
>
> Thanks for explanation. Make sense now. Should we do something like:
> 
> if (pkg.isEmpty()) {
> .task(LinuxAppImageTaskID.LAUNCHER_ICONS)
>                         .addDependent(BuildApplicationTaskID.CONTENT)
>                         .applicationAction(LinuxPackagingPipeline::writeLauncherIcons).add();
> }
> 
> Add task only for application image vs adding it always and then overwriting with noaction()?

We can do this, but this will complicate building the task graph by making the set of nodes and edges conditional.

It is simpler to build the graph unconditionally, but configure actions for the nodes conditionally.

E.g.: mac packaging task graph is way more sophisticated in terms of branching, see - [MacPackagingPipeline.build()](https://github.com/openjdk/jdk/blob/2f613911d58478913dc482e1500d3fbab74408b9/src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacPackagingPipeline.java#L104). but its initialization is quite stratighforward.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27928#discussion_r2467352699