fusesource / jansi

Jansi is a small java library that allows you to use ANSI escape sequences to format your console output which works even on windows.
http://fusesource.github.io/jansi/
Apache License 2.0
1.11k stars 140 forks source link

Fix build for linux-arm64 and linux-riscv64 #274

Open Glavo opened 1 year ago

Glavo commented 1 year ago

This PR fixes the following issues

gnodet commented 12 months ago

@Glavo as I mentioned last week, I'm planning to rebase JANSI on top of JLine. Jansi will provide the same easy to use API for simple applications, and JLine will provide the underneath access to the console. The switch is imho mandatory in order to not duplicate the work / maintenance on both projects. The new JNI provider for jline is available at https://github.com/jline/jline3/pull/870 and the PR for jansi will look like https://github.com/fusesource/jansi/pull/276.

Would you mind retargeting this PR to https://github.com/jline/jline3 ?

Glavo commented 12 months ago

The switch is imho mandatory in order to not duplicate the work / maintenance on both projects.

Sorry, I don't agree with this.

jline is a powerful library, but many programs don't need these features, so they just use jansi. Many of them are cornerstones of the Java ecosystem, such as Maven and Gradle.

I can understand the idea of reducing duplicate code, but I wish jansi as a standalone library could include these features. Can we make jline deprecate the jna backend and force dependency on jansi? This way we can implement them in jansi without maintaining duplicate code. I believe that after these PRs are completed, jansi will be enough to take on this responsibility.

gnodet commented 12 months ago

The switch is imho mandatory in order to not duplicate the work / maintenance on both projects.

Sorry, I don't agree with this.

jline is a powerful library, but many programs don't need these features, so they just use jansi. Many of them are cornerstones of the Java ecosystem, such as Maven and Gradle.

I can understand the idea of reducing duplicate code, but I wish jansi as a standalone library could include these features. Can we make jline deprecate the jna backend and force dependency on jansi? This way we can implement them in jansi without maintaining duplicate code. I believe that after these PRs are completed, jansi will be enough to take on this responsibility.

The point, which I agree with, is to have a standalone and small library for Jansi. The jansi providers are definitely missing some important pieces to be used by JLine. However, we could refactor the JLine providers a bit to make them a better fit for Jansi, without having to duplicate code or bring too much unused stuff in Jansi. I think the way to go is to merge Jansi into JLine, we could then easily refactor the internal parts without impacting the jansi or jline API to suit both needs.

gnodet commented 12 months ago

The switch is imho mandatory in order to not duplicate the work / maintenance on both projects.

Sorry, I don't agree with this. jline is a powerful library, but many programs don't need these features, so they just use jansi. Many of them are cornerstones of the Java ecosystem, such as Maven and Gradle. I can understand the idea of reducing duplicate code, but I wish jansi as a standalone library could include these features. Can we make jline deprecate the jna backend and force dependency on jansi? This way we can implement them in jansi without maintaining duplicate code. I believe that after these PRs are completed, jansi will be enough to take on this responsibility.

The point, which I agree with, is to have a standalone and small library for Jansi. The jansi providers are definitely missing some important pieces to be used by JLine. However, we could refactor the JLine providers a bit to make them a better fit for Jansi, without having to duplicate code or bring too much unused stuff in Jansi. I think the way to go is to merge Jansi into JLine, we could then easily refactor the internal parts without impacting the jansi or jline API to suit both needs.

Have a look at https://github.com/jline/jline3/pull/871 This can definitely be refactored, but it provides a standalone jansi jar and removes all code duplication. We just need to move the line a bit lower if we want to avoid bringing too much in jansi. But it provide a single point for console providers implementation, selection, auto-detection.