Developer Use Case: Developing a hello world IDE plug-in and testing it (using it)

[benoitf]

Remark: It should be straightforward, intuitive, with user only focusing on its plugin and easy.

For now, it’s very hard for a developer to onboard :

• developer needs to clone che
• Do not know easily what modules to recompile (of course there is documentation but as usual, it would be easier it is was like “easy”)
• Layout of a plugin: ? what are the mandatory files, how should I structure the directories
• Need to insert something into assembly gwt.xml (but which one ? agent ? server ?)
• Need to add maven dependency in some pom.xml
  • Need to figure out why maven dependency should be using a dependency management (mastering maven)

So to sum-up:

• when we develop a plugin we should not have to clone the source of the product itself.
  • I don’t clone eclipse IDE, I don’t clone chrome repository, Firefox, etc when creating a plugin for these tools
• Developer should have templates (like maven archetype)
• Installing and running this plug-in should be “easy”

1. Option Update DTD for GWT-module descriptors #1 develop Che with Che:
   • wizard entry like ‘Creating plug-in’ inside Che
   • having menu, icons, view or perspective dedicated to plug-in extensions when user create an Eclipse Che IDE plug-in inside Che
2. Option Package docker runner in Che #2 : maven centric
   • BOM of Che.
   • Maven plug-in to build Che assembly
     • Only specify modules to add in a pom.xml, packaging-type: che-plugin or che-assembly, then specify che.version to use and at the end we have a custom Che.
     • If we want to check with another che version, we only have to change the che version of the bom
3. Option Update README.md #3 : Eclipse IDE or IntelliJ
4. Providing plug-in with new wizard, provide runtime configuration for super dev mode

[TylerJewell]

Closing this one - for now - as we are working on archetype approach and we will see how far we can extend that.