I would say we have to keep the client (jenkins-cli.jar) and Java API
more or less untouched to keep things compatible for clients and
plugins. As already noted on CERT list, I lean towards removing the
remoting/channel support in favor of sshd/ssl (provided we do not have
to reimplement all the commands and clients) - which seems doable.
Breaking the handful of implementations that rely on channel seems
tolerable to me.
I strongly argue against command rewrite, have a look at our effort to
move from @CLIMethod to CLICommand (which only involves a subset of
commands). It took years, was a risky and heavy change and it is still
not done.
The idea of bridging REST API and CLI commands sounds appealing (write
once, invoke in 2 different ways!) but it seem to follow the pattern of
@CLIMethod. It is extra easy/convenient but is exactly as easy to break
it with a seemingly innocent change (especially if you only care for,
say, REST and your client depend on CLI). Putting aside than noone want
to add 5 more tests to make sure one annotation does what we hope it
does so we end up exposing use-cases noone ever bothered to cover by
tests. This is an old CLI struggle. Also, I do not think we can take
advantage of all the features of REST/CLI.
--
oliver
--
You received this message because you are subscribed to the Google Groups "Jenkins
Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/jenkinsci-dev/c4792149-cccb-7c11-9c0b-3341ac945283%40gmail.com.
For more options, visit https://groups.google.com/d/optout.
