#1987: Fixed GUI not launching for snapshot versions#2036
Conversation
…/--enableLogging flag to enable the printing of logs to the terminal for debugging purposes.
Coverage Report for CI Build 28702549520Coverage increased (+0.05%) to 71.879%Details
Uncovered ChangesNo uncovered changes found. Coverage Regressions5 previously-covered lines in 3 files lost coverage.
Coverage Stats💛 - Coveralls |
…broken-for-snapshots' into fix/devonfw#1987-Gui-commandlet-broken-for-snapshots # Conflicts: # cli/src/test/resources/ide-projects/gui/_ide/installation/gui/pom.xml
maybeec
left a comment
There was a problem hiding this comment.
Thanks for tackling the SNAPSHOT GUI-launch bug. Switching to context.newProcess() and registering the freshly installed mvn on the IDEasy-managed PATH is a clean approach, and it's good to see a JUnit test covering both process modes. 👍
Reviewing only the diff against the coding conventions (inline suggestions attached where there is an easy fix):
-
(Medium) A failed launch now reports success (
Gui.javaL96-102). Previously an exception fromrunToolpropagated and the command failed; nowcatch (Exception e)logs and returns normally, soide guiexits successfully even when the GUI never started. Logging the full exception is fine per the Catching and handling Exceptions section, so this isn't a convention breach — but for a CLI a failed launch should arguably surface a non-zero exit, andcatch (Exception e)is very broad (it would also swallow programming errors). The inline suggestion wraps-and-rethrows asCliExceptionwhile keeping your helpful hint. -
(Low) Comment wording and length (
Gui.javaL67-71). Per the Code-Documentation section, implementation comments should factually explain the why. The current text is first-person/speculative ("I tried ... withPathEntry()", "tested on a Mac; potentially ... on Windows"), and L69 (~205 chars) is much longer than the wrapping used elsewhere in the file. A shortened, factual version is suggested inline. -
(Low)
-Uon every launch (Gui.javaL82).--update-snapshotsforces a remote check on everyide gui, adding latency and requiring network even for released (non-SNAPSHOT) versions. Consider applying it only in snapshot mode. -
(Nit) Field visibility (
Gui.javaL30). Other commandlet property fields are declaredpublic final(e.g.AbstractUpdateCommandlet,CreateCommandlet);enableExtendedLoggingis package-private. Making itpublic finalkeeps it consistent — suggestion inline.
Nice work overall — none of these are blocking.
|
|
||
| private static final Logger LOG = LoggerFactory.getLogger(Gui.class); | ||
|
|
||
| final FlagProperty enableExtendedLogging; |
There was a problem hiding this comment.
Other commandlet property fields are declared public final (see e.g. AbstractUpdateCommandlet, CreateCommandlet). For consistency:
| final FlagProperty enableExtendedLogging; | |
| /** {@link FlagProperty} to enable logging of the GUI process to the terminal. */ | |
| public final FlagProperty enableExtendedLogging; |
| /* Register the freshly installed mvn on the IDEasy managed PATH so that the IDEasy controlled maven is used to launch | ||
| the GUI instead of any maven that happens to be on the system PATH. We install via installTool (software repository | ||
| only) and therefore have to register the bin directory ourselves (install() would normally do this). I tried to achieve this alternatively via .withPathEntry(), however, this did not work as expected. | ||
| This was tested on a Mac; potentially, withPathVariable() works correctly on Windows. | ||
| */ |
There was a problem hiding this comment.
Per the Code-Documentation conventions, implementation comments should factually explain the why. This drops the first-person/speculative wording and wraps the long line to match the rest of the file:
| /* Register the freshly installed mvn on the IDEasy managed PATH so that the IDEasy controlled maven is used to launch | |
| the GUI instead of any maven that happens to be on the system PATH. We install via installTool (software repository | |
| only) and therefore have to register the bin directory ourselves (install() would normally do this). I tried to achieve this alternatively via .withPathEntry(), however, this did not work as expected. | |
| This was tested on a Mac; potentially, withPathVariable() works correctly on Windows. | |
| */ | |
| /* | |
| * Register the freshly installed mvn on the IDEasy-managed PATH so the IDEasy-controlled maven (from the software | |
| * repository) launches the GUI instead of any maven on the system PATH. installTool only installs into the software | |
| * repository, so we register the bin directory here (install() would normally do this). | |
| */ |
| try { | ||
| mvn.runTool(processContext.withPathEntry(javaInstallation.binDir()), processMode, args); | ||
| } catch (Exception e) { | ||
| LOG.error( | ||
| "Failed to launch the GUI. If maven states issues with dependency resolution, check whether the maven M2 repo is enabled in your project.", | ||
| e); | ||
| } |
There was a problem hiding this comment.
As written, any failure is logged and then swallowed, so ide gui exits successfully even when the GUI never launched. Wrapping-and-rethrowing keeps your hint but surfaces the failure to the caller (and narrows the catch to RuntimeException):
| try { | |
| mvn.runTool(processContext.withPathEntry(javaInstallation.binDir()), processMode, args); | |
| } catch (Exception e) { | |
| LOG.error( | |
| "Failed to launch the GUI. If maven states issues with dependency resolution, check whether the maven M2 repo is enabled in your project.", | |
| e); | |
| } | |
| try { | |
| mvn.runTool(processContext.withPathEntry(javaInstallation.binDir()), processMode, args); | |
| } catch (RuntimeException e) { | |
| throw new CliException( | |
| "Failed to launch the GUI. If maven reports issues with dependency resolution, check whether the maven M2 repo is enabled in your project.", e); | |
| } |
…commandlet-broken-for-snapshots # Conflicts: # CHANGELOG.adoc
…i-commandlet-broken-for-snapshots # Conflicts: # CHANGELOG.adoc
This PR fixes #1987
Implemented changes:
<repository>definition to the gui-launcher pom file--enableLogging/-lflag to the GUI commandlet. This will launch the GUI inProcessMode.DEFAULTrather thenProcessMode.BACKGROUND_SILENT; this way all internal JavaFX/Maven logs etc are printed to the terminal, making debugging easier.Testing instructions
Please add conscise, understandable instructions on how a reviewer can test/verify the functionality of your contribution here:
1. Testing the snapshot fix:
a. Team-Review:
ide upgrade --mode=snapshotb. Retesting after Merge:
ide upgrade --mode=snapshotide guiTesting the new
--enableLoggingflag:a. Team-Review:
-l/--enableLogging(see step 4 in the GraalVM build guide)b. Retesting after Merge:
ide upgrade --mode=snapshotide gui --enableLoggingoride gui -l(small L)Checklist for this PR
Make sure everything is checked before merging this PR. For further info please also see
our DoD.
mvn clean testlocally all tests pass and build is successful#«issue-id»: «brief summary»(e.g.#921: fixed setup.bat). If no issue ID exists, title only.In Progressand assigned to you or there is no issue (might happen for very small PRs)with
internal