Right now, the client API is only exposed in 2 of the three. Here's a proposal of what we should do:
[ ] Migrate sbt.protocol package into api artifact (we'll have to compile for every major version of sbt we support).
api artifact would depend on the xsbti interface module directly, as well as expose its own interfaces.
Keep the 'remote protocol' bits somewhere separate, if we can.
[ ] Make the ui-interface compatibility plugin, sbt-server and sbt-client directly depend on the api artifact (ok for now because everything is sbt 0.13 + scala 2.10.x)
[ ] Formalize definition and registration of remote serialization formats somehow.
[ ] Define a key in the ui-interface that allows "local" clients to connect to the server and issue commands/listen to changes. Should only use interfaces defined in the api library.
[ ] Make api artifact 'binary maintenance friendly' so we aren't screwed if we have to change interfaces.
Here are the spots where we may need to use client-server APIs:
Right now, the client API is only exposed in 2 of the three. Here's a proposal of what we should do:
apiartifact (we'll have to compile for every major version of sbt we support).apiartifact would depend on the xsbtiinterfacemodule directly, as well as expose its own interfaces.ui-interfacecompatibility plugin,sbt-serverandsbt-clientdirectly depend on the api artifact (ok for now because everything is sbt 0.13 + scala 2.10.x)ui-interfacethat allows "local" clients to connect to the server and issue commands/listen to changes. Should only use interfaces defined in theapilibrary.apiartifact 'binary maintenance friendly' so we aren't screwed if we have to change interfaces.Quick review on tasks from @pvlugter