Discussion: Openness to significant changes to the project?

Read the issue's proposals covering logging dependencies, SSH library support, optional JSON structure, Gradle, and GitHub Actions. There are no files or tests named, so first establish maintainer agreement and a concrete scope; done would require an agreed plan rather than the broad set of changes currently listed.

And by that I mean significant refactoring changes, not really changing functionality.

I'm using this library at work, and it suffers from a few problems:

• including a java logging library instead of only using slf4j-api
  • This is honestly a trivial fix. The slf4j-log4j library should be runtime scoped
• Uses an out of maintenance SSH library
  • I'd switch to sshj which is still receiving activity
  • Or instead, make it SSH library agnostic
  • I also want SSH-agent support, so that I don't have to do weird SSH RSA-only PEM format key things.
  • sshj supports modern algorithms and ssh key types
• doesn't support the optional JSON structure that the pyEZ library does
  • I'm not yet sure how to make this work, but I'd like to try :)

Not a problem, but a personal preference:

• I'd love to see it use gradle for the build system
  • I'm just a fan of gradle, as it gives us everything maven does, but also flexibility if we need it.
• github actions to do java matrix builds against 8, 11, and now 17
  • Would love to have some CI for all the java versions, to make sure it stays alive with modern JDKs
  • This is pretty trivial

How open is the project to some significant pull requests that change big things in the application?

What do folks think about the ideas I've listed here?