Malformatted output of gradlew-commands

[CSchoel]

It seems that the gradlew commands to start the server and the client do not work properly on all shells/gradle versions. On my system, the output looks as follows:

Stage: Input the serverip, before pressing enter:

[cslz90@cswork MopeSWTP]$ ./gradlew startConsoleClient

> Task :startConsoleClient
Serverip:
<<====<==<=========----> 75% EXECUTING [17s]
> :startConsoleClient
127.0.0.1

Stage: Select command

[cslz90@cswork MopeSWTP]$ ./gradlew startConsoleClient

> Task :startConsoleClient
Serverip:
<==<===<=<=========----> 75% EXECUTING [10s]
Serverport:
<<==<=========----> 75% EXECUTING [17s]
 INFO [main] (MopeLSPClient.java:49) - Client->setServer
 INFO [main] (ConsoleClientLauncher.java:51) - Client listening
1: Initialize server
2: Get compiler version
3: Load File
4: Load model
5: Check Model
6: Initialize Model
7: Add Folder to ModelicaPath
8: Show ModelicaPath
9 : Exit
> INFO [pool-1-thread-1] (MopeLSPClient.java:36) - Client->showMessageRequest
<=========----> 75% EXECUTING [4m 17s]
> :startConsoleClient

I am using bash and other relevant software versions are the following:

[cslz90@cswork MopeSWTP]$ ./gradlew --version

------------------------------------------------------------
Gradle 7.0.2
------------------------------------------------------------

Build time:   2021-05-14 12:02:31 UTC
Revision:     1ef1b260d39daacbf9357f9d8594a8a743e2152e

Kotlin:       1.4.31
Groovy:       3.0.7
Ant:          Apache Ant(TM) version 1.10.9 compiled on September 27 2020
JVM:          15.0.2 (Oracle Corporation 15.0.2+7)
OS:           Linux 5.10.42-1-MANJARO amd64

[CSchoel]

@manuEbg I assigned you, because you are the Scrum Master. You can delegate this issue as you like.

[CSchoel]

To clarify: The program works fine, but is extremely confusing to use due to the intermittent lines added by gradle.

[manuEbg]

On my System the Output looks the same. I don't really considered this a problem since a user would use the Jars, which don't have this outputproblem, and a developer would probably use IntelliJ 😊

[CSchoel]

Well, here you have a developer, who prefers to use the shell directly. :wink: And also your README instructs the user to use the command ./gradlew startMopeServer directly.

It turns out that this is indeed normal behavior of gradle, which can be disabled by adding the argument --console plain to the gradlew command. You don't have to change anything in the code, but I think you should add this argument to the README (and a short half-sentence that explains why it is there).

[manuEbg]

@IlmarB please Update the Readme like stated in this Comment:)

Well, here you have a developer, who prefers to use the shell directly. 😉 And also your README instructs the user to use the command ./gradlew startMopeServer directly.

It turns out that this is indeed normal behavior of gradle, which can be disabled by adding the argument --console plain to the gradlew command. You don't have to change anything in the code, but I think you should add this argument to the README (and a short half-sentence that explains why it is there).

[IlmarB]

okay, will do

[IlmarB]

done

[CSchoel]

I don't know where it went, but the README.md does not include the hint to use --console plain anymore.

[CSchoel]

Actually, thanks to Git, I now know what happened:

The change was introduced here 2223b69049a9247556c5f2806d0e76c3736c243a and here 238824bd1b4a6459e645a588d2d9f1e38257923c, but then reverted here a07ae40bf79c1b8f42e277a53155b6739bfa2d1f.

And this is a prime example, while small commits with meaningful messages are important. I have no clue what was the actual purpose of the "readme update" (a07ae40bf79c1b8f42e277a53155b6739bfa2d1f). From the contents, I suppose it should actually add additional console commands to the readme. However, it accidentally also reverted the changes for this issue and completely deleted the section "Instructions to build the server- and console-jar-files".

Tip for the future: Never use git add ., or really any git add command, without excactly knowing what changes you are staging. For this purpose I alwas use git gui, which shows an overview of all staged and unstaged changes and also lets me split a large change set into smaller ones if required. (Right-click on changes -> stage/unstage lines/hunk)

[CSchoel]

@IlmarB , please have a look at this and fix the README.md.