On Thu, Dec 15, 2016 at 2:58 AM, Oliver Gondža <[email protected]> wrote: > 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.
If JENKINS-26463 is implementable, this just means it all becomes a plugin, which we could deprecate. With the Remoting transport deleted, most of the security maintenance burden goes away. > 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). So I think you are arguing against any kind of automatic exposure of REST endpoints as CLI commands, which I do not think anyone was proposing to begin with. At least, my two proposals were, briefly: · retain the CLI API as is, but provide an alternate HTTP-based transport (and, optionally, corresponding generic client) · deprecate the CLI altogether, and only do REST (again, optionally, creating a dedicated client for the most common REST operations in core) -- 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/CANfRfr27EzKUoJjBCBqDN_7xJBiUS-tbbhpNcKVkzPL11RdTxA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
