-
Notifications
You must be signed in to change notification settings - Fork 2.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Move to JLine 3.x to avoid Jansi 1.x dependency/usage #19510
Conversation
There's a good chance we will want to backport this so I would be in favor of not making too big changes here (and maybe have a followup PR later to remove JLine support). I have no idea how to test that this works though. I'll let @gastaldi chime in. |
This I'll also check tomorrow why our automated test(s) didn't catch this. |
I'm building this PR in my Windows VirtualBox and will let you know |
Ha! Turns out our CI (rightly) uses Maven 3.8.1[1]. I just downloaded this version to do a basic check and turns out 3.8.1 version of Maven ships with [1] https://github.com/quarkusio/quarkus/blob/main/.mvn/wrapper/maven-wrapper.properties#L1 |
@jaikiran looks like it's only mentioned in JIRA: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922&version=12349965 |
Yes, it looks like it first got upgrade in Maven 4.x and then was backported into 3.8.2 for this https://issues.apache.org/jira/browse/MNG-6239. It's probably not a bad thing though. This gives us a chance to move away from JLine 2.x. |
I can confirm this works: PS C:\temp> mvn io.quarkus:quarkus-maven-plugin:999-SNAPSHOT:create `
>> -DprojectGroupId="com.infosupport.pitstop.customermanagement" `
>> -DprojectArtifactId="customer-management" `
>> -DclassName="com.infosupport.pitstop.customermanagement.CustomersResource" `
>> -Dpath="customer-management"clear
[INFO] Scanning for projects...
[INFO]
[INFO] ------------------< org.apache.maven:standalone-pom >-------------------
[INFO] Building Maven Stub Project (No POM) 1
[INFO] --------------------------------[ pom ]---------------------------------
[INFO]
[INFO] --- quarkus-maven-plugin:999-SNAPSHOT:create (default-cli) @ standalone-pom ---
ago 19, 2021 12:15:07 PM org.jline.utils.Log logr
WARNING: Unable to create a system terminal, creating a dumb terminal (enable debug logging for more information)
[INFO] -----------
[INFO]
applying codestarts...
[INFO] >> java
>> maven
>> quarkus
>> config-properties
>> dockerfiles
>> maven-wrapper
>> resteasy-codestart
[INFO]
-----------
[SUCCESS] quarkus project has been successfully generated in:
--> C:\temp\customer-management
-----------
[INFO]
[INFO] ========================================================================================
[INFO] Your new application has been created in C:\temp\customer-management
[INFO] Navigate into this directory and launch your application with mvn quarkus:dev
[INFO] Your application will be accessible on http://localhost:8080
[INFO] ========================================================================================
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 3.297 s
[INFO] Finished at: 2021-08-19T12:15:08-03:00
[INFO] ------------------------------------------------------------------------ |
Excellent. Thank you for running the tests with this PR. I'll let the GitHub action jobs complete and in a separate personal branch of mine will trigger a GitHub job by upgrading to Maven 3.8.2 to see if there are any other issues that we need to be aware of. |
Not a big deal, but I wonder if we can somehow get rid of the warning: ago 19, 2021 12:15:07 PM org.jline.utils.Log logr
WARNING: Unable to create a system terminal, creating a dumb terminal (enable debug logging for more information) |
...pendent-projects/tools/devtools-common/src/main/java/io/quarkus/devtools/utils/Prompter.java
Show resolved
Hide resolved
This workflow status is outdated as a new workflow run has been triggered. Failing Jobs - Building 54690ea
Full information is available in the Build summary check run. Test Failures⚙️ Gradle Tests - JDK 11 Windows #📦 integration-tests/gradle✖
✖
|
FWIW, I'm working on updating to Maven 3.8.2. This is currently waiting for the Upgrade to Gradle 7.2 (sic!). Btw, we could add |
The failures in this PR look unrelated. As for adding jline:jline as a banned dependency, is that a common thing we do for outdated libraries? Given that the new version of JLine that we are using in this PR uses a completely different package namespace, is banning necessary? Hello @famod, I'll let you continue with the 3.8.2 work. I was merely interested in a complete run of this PR against 3.8.2, but it doesn't look straightforward given certain other unrelated dependency issues. |
It makes sense to ban it because it is incompatible with Maven 3.8.2, so +1 to that |
Done. I've updated the PR to ban |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for this but I really think that we should try to get rid of the warning WARNING: Unable to create a system terminal, creating a dumb terminal (enable debug logging for more information)
. We fight hard to get our output as clean as possible.
I'll take a look what this warning is about. |
@gsmet, Done. I've now updated this PR with a change that should prevent that warning message. |
Failing Jobs - Building 241d5b0
Full information is available in the Build summary check run. Test Failures⚙️ MicroProfile TCKs Tests #📦 tcks/microprofile-config✖
✖
✖
✖
✖
✖
✖
|
These latest Microprofile config TCK job failures with |
Yeah, I have seen them failing many times. /cc @radcortez |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Perfect, thanks.
Potential fix for #19491
As noted in that discussion, the JLine 2.x is EOLed and its usage it leading to issues described in that bug.
I've done absolutely zero testing of this change. I have only ensured that the whole build compiles and builds fine. I want to make sure there are no basic issues with this change and see how CI reacts. Tomorrow, I will try and get hold of the Windows box again and see if this fixes that original issue.
In the meantime, there are a couple of things to sort out:
CreateProjectMojoIT
testcase in the project. I wonder why it didn't catch this issue on our Windows CI setup