Pair programming plugin

[rnavagamuwa]

What does this PR do?

This PR adds the pair programming feature for Eclipse che.

New Behavior

This content may also be included in the release notes.

Tests written?

No

To make the demo up and running:

1. Create a workspace from a custom stack. Provide the following Dockerfile to your stack:

   FROM rnavagamuwa/fluxworkspace
   

2. Start the workspace, Open in IDE

3. Create a project.

4. Create a custom command

   • name: flux
   • commandline: sudo service rabbitmq-server start && cd /home/user/flux-master/node.server && npm start

5. Start the flux command

6. Open a file to edit

7. Open a new browser windows to the same workspace, open the same file to edit

[codenvy-ci]

Can one of the admins verify this patch?

[codenvy-ci]

Can one of the admins verify this patch?

[TylerJewell]

@rnavagamuwa - this is one of the most impressive GSOC projects I have seen. I hope that you feel that the learning exercise is worth it. Why did you close the PR?

We should start gathering a set of requirements on what will be needed to improve in order for this PR to be accepted and placed into the core project.

My initial thoughts:

1. We need to see the dockerfile that you use as a base for the workspace.
2. Please document all of the non-standard software installed into the workspace that you requrie.
3. We may want to talk a little to @tolusha about packaging up some of the post-ws software into an agent, which is a new concept. Users will be allowed to "add an agent" to a ws, which will be software that can run inside. Maybe "pair-programming" would be the agent here.
4. Any sense of disk and memory requirements for running the system?

[rnavagamuwa]

@TylerJewell Plugin stopped working when I added some new commits. And also some required classes were deprecated. That's why I closed the PR. I checked that with @vparfonov and he has sent a PR to remove the deprecated tag. After fixing these issues I'll send another PR ASAP. Yes this was a great experience and I learnt a lot. 😄

Regarding your thoughts

1. I'm adding a new stack library and will provide the url to the docker file in my next PR.
2. I'm writing a blog post as my final submission, so I'll document everything and post the url to the blog post with the PR.
3. @sunix also wanted me to split the plugin into two. One will be the pair-programming plugin and the other one will be the communication protocol. In this case it's Eclipse Flux. So anyone can use any protocol for pair-programming. I didn't have enough time to split the plugin, so thought of sending the PR without that.
4. Yeah, I have used this feature with 2GB of ram. But I think 1GB would be enough. Will check this and and add to the documentation.

[TylerJewell]

@rnavagamuwa - you need to prepare yourself that the pull request process can take many weeks. There may be many changes that you have to make along the way to improve the pull requests before it gets accepted. That is part of the learning process.

Generally, once you open the PR, you can continue to make commits. You do not need to close the PR for every commit. Keep the PR open and track your changes and keep the discussion moving forward.

For a PR to be accepted, it will have to meet coding standards, it will have to be properly documented, you'll have to meet IP requirements & any CQs. This is part of the software development process - and it's a good learning exercise.

[rnavagamuwa]

@TylerJewell Yeah , I do understand that it's not a good thing to close and re submit new PRs. Since you have mentioned that the merging process may take a longer time than I expected, thought of sending the PR with the current state. New PR: #2131 😄