Developer Use Case: Experiencing something “fast” when developing server-side workspace agent components

[benoitf]

Let say I’ve a server-side component running inside the workspace agent.
I want to do an update of this component.

For now:
I update java code, I generate maven module, I generate a new workspace agent assembly, I recompile workspace master to include the workspace agent or I manually update the workspace agent in my binary, then I restart a workspace from scratch and then my new server side service is updated.

Expectation for a developer is to have something “fast”:
Update java code, save, see the new code refreshed in the agent

So several options here:

1. Option Update DTD for GWT-module descriptors #1 use of “localhost” machine for the agent
   • So for example, use Eclipse IDE WTP or other to start a tomcat with a war file
   • Update the code, class is regenerated by Eclipse IDE, then wtp update the class of the exploded war, war is restarted in Tomcat, then service is ready again.
2. Option2 : Allow “exploded archive” of the agent.
   • Instead of mounting a workspace agent zip, mount a folder, add hot deploy option to Tomcat running as the workspace agent.
   • Update class in the exploded war then it updated the folder, which is also mounted in the workspace agent then it notifies the workspace agent to restart Tomcat webapp and here we have the change

[benoitf]

for wtp, link to #1676

[TylerJewell]

@benoitf - closing because we have other issues that are tracking related items.

[benoitf]

@TylerJewell I don't see such issues about related items. For me the current open issues don't allow fast "hot-deployment"/redeploy of only the impacted library

[gorkem]

I do not think option 1 is acceptable. Che development should be done with Che. Reopening, I think we should reconsider this one from a self-hosting of Che development perspective.

[skabashnyuk]

Not relevant anymore.