#1724: Create GUI commandlet

[laim2003]

This PR fixes #1724

Implemented changes:

• Added Gui commandlet
• Added gui-launcher module to project (in order to provide the gui module as a dependency to the cli, while not requiring the gui to automatically included in the cli release from the beginning)

---

Checklist for this PR

Make sure everything is checked before merging this PR. For further info please also see
our DoD.

• When running mvn clean test locally all tests pass and build is successful
• PR title is of the form #«issue-id»: «brief summary» (e.g. #921: fixed setup.bat). If no issue ID exists, title only.
• PR top-level comment summarizes what has been done and contains link to addressed issue(s)
• PR and issue(s) have suitable labels
• Issue is set to In Progress and assigned to you or there is no issue (might happen for very small PRs)
• You followed all coding conventions
• You have added the issue implemented by your PR in CHANGELOG.adoc unless issue is labeled
  with internal

Checklist for tool commandlets

Have you added a new «tool» as commandlet? There are the following additional checks:

• The tool can be installed automatically (during setup via settings) or via the commandlet call
• The tool is isolated in its IDEasy project, see Sandbox Principle
• The new tool is added to the table of tools in LICENSE.asciidoc
• The new commandlet is a command-wrapper for «tool»
• Proper help texts for all supported languages are added here
• The new commandlet installs potential dependencies automatically
• The variables «TOOL»_VERSION and «TOOL»_EDITION are honored by your commandlet
• The new commandlet is tested on all platforms it is available for or tested on all platforms that are in scope of the linked issue

[laim2003]

@hohwille I had following thoughts:

• (If i understand correctly) it doesnt make sense to add the tool to the table of components/tools as this is not a third-party based tool like others.
• Does it make more sense to include the commandlet in com.devonfw.tools.ide.tool.gui (current state) or in com.devonfw.tools.ide.commandlet?
• Does TOOL_VERSION etc. make sense here? The version is automatically equal to the rest of IDEasy anyway

[coveralls]

Coverage Report for CI Build 24878769465

Coverage decreased (-0.09%) to 70.595%

Details

• Coverage decreased (-0.09%) from the base build.
• Patch coverage: No coverable lines changed in this PR.
• 15 coverage regressions across 6 files.

Uncovered Changes

No uncovered changes found.

Coverage Regressions

15 previously-covered lines in 6 files lost coverage.

File	Lines Losing Coverage	Coverage
com/devonfw/tools/ide/commandlet/CommandletManagerImpl.java	8	90.26%
com/devonfw/tools/ide/git/repository/RepositoryCommandlet.java	3	70.98%
com/devonfw/tools/ide/io/HttpDownloader.java	1	62.79%
com/devonfw/tools/ide/os/WindowsPathSyntax.java	1	73.01%
com/devonfw/tools/ide/tool/ide/IdeaPluginDownloader.java	1	68.09%
com/devonfw/tools/ide/tool/ide/IdeToolCommandlet.java	1	78.33%

---

Coverage Stats

Relevant Lines:	15295
Covered Lines:	11255
Line Coverage:	73.59%
Relevant Branches:	6800
Covered Branches:	4343
Branch Coverage:	63.87%
Branches in Coverage %:	Yes
Coverage Strength:	3.11 hits per line

---

💛 - Coveralls

[hohwille]

@laim2003 thanks for your PR. 👍
Since you are still in draft mode, I only did a quick scan review to give you some guiding hints.

[hohwille]

Does it make more sense to include the commandlet in com.devonfw.tools.ide.tool.gui (current state) or in com.devonfw.tools.ide.commandlet?

Yes, com.devonfw.tools.ide.tool.gui makes perfectly sense to me.

[hohwille]

Does TOOL_VERSION etc. make sense here? The version is automatically equal to the rest of IDEasy anyway

No, since Gui commandlet is not a ToolCommandlet lots of the DoD checklist for that does not apply here. Simply leave those unchecked and ignore them.

[laim2003]

TODO: GO through the .workflow files for GitHu actions and update all java versions as discussed in the daily

[hohwille]

@laim2003 thanks for your PR. Nice work 👍
I left some comment. One is IMHO a real bug I found, the rest are just improvements.
Please have a look and address the comments, then we can merge.

[hohwille]

I just wanted to merge this PR and include it into our PR but found one last problem.

(If i understand correctly) it doesnt make sense to add the tool to the table of components/tools as this is not a third-party based tool like others.

Not entirely correct. We always need to document our dependencies and check their licenses.
This e.g. means that we now make the GUI available without our product that requires JavaFx.
Here we are using openJFX what seems to be licensed under GPL with classpath extension:
https://openjfx.io/

As a first thing we need to add the license to our aggregated license in this PR.
Further, we need to clarify if the copy-left applies here and we need to change the license of our GUI from ASL to GPL.
I hope the latter is not needed, but I would therefore conclude that we take the time to properly clarify this before merging this PR what means the GUI feature will miss our release today and has to be moved to the next release.

BTW: We could also support the azul-fx edition in IDEasy and use that instead of default java edition to avoid having openjfx as dependency.

[hohwille]

For license of OpenJFX see also:

• https://github.com/openjdk/jfx
• https://github.com/openjdk/jfx/blob/master/LICENSE

[hohwille]

Linking this library statically or dynamically with other modules is making

a combined work based on this library. Thus, the terms and conditions of
the GNU General Public License cover the whole combination.
As a special exception, the copyright holders of this library give you
permission to link this library with independent modules to produce an
executable, regardless of the license terms of these independent modules,
and to copy and distribute the resulting executable under terms of your
choice, provided that you also meet, for each linked independent module,
the terms and conditions of the license of that module. An independent
module is a module which is not derived from or based on this library. If
you modify this library, you may extend this exception to your version of
the library, but you are not obligated to do so. If you do not wish to do
so, delete this exception statement from your version.

So even though IANAL this clearly implies the copy-left.
We could consider making openjfx optional in our pom for the gui module,
then we can add it again to gui-launcher module and declare that GPL since a GPL product can be derived from ASL code but not vice versa.
In the end this still makes our GUI that we launch a GPL product if we choose OpenJFX.
Still this seems for me the easiest and simplest solution and I have no problem with that.
But we have to stick to the rules and not violate license terms so we cannot merge until all that is done and properly documented.

[laim2003]

Are you sure that we need to adjust the license? Because JavaFX is also licensed under the GPL with the Classpath Exception, which should apply to our case. As I understand it, we would only need to change the license of the GUI module if we were making changes directly to the JavaFX library itself, which we are not doing:

As a special exception, the copyright holders of this library give you
permission to link this library with independent modules to produce an
executable, regardless of the license terms of these independent modules,
and to copy and distribute the resulting executable under terms of your
choice, provided that you also meet, for each linked independent module,
the terms and conditions of the license of that module.

In principle, we only have a dependency relationship with JavaFX.