Eclipse plug-in rework

The current plug-in is based on the core of an older Zero CLI. This can lead to problems when trying to use cooperatively Eclipse and the CLI. For example:

• Executables aren't marked executable during resolves Update dependencies with the plug-in correctly downloads the latest modules, but the expand doesn't execute chmod (e.g. bug 3567). As a result, executables fail to run on *nix (zero, zso, appbuilder).
• Bootstrapped module groups lack site.xml If a module group is created by the plug-in, then the site.xml is missing -- which renders the module group broken from the CLI. (bug 5348)
• Several issues are addressed in a Getting Started section. Of these, we should address:
  • Point Eclipse to your CLI repository - Depending on how users are allowed to install/configure a CLI, the repository settings need to reflect exactly what they are using.
  • Configure the remote repository chain - Same point as above. sMash has three repos which could be read from the site.xml and then used to populate the list.

Goals of the rework

We are looking to improve consistency between the plug-in and the CLI and to improve maintainability of the plug-in.

We are not looking to change the role of Eclipse in the sMash development story. Specifically, App Builder is preferred for application development (largely scripts and UI); Eclipse is available for deep Java development and debugging.

Design points for the plug-in

• CLI is a pre-req for the plug-in. Users configure the plug-in with a pointer to the CLI install directory. Execution will be similar to App Builder: The plug-in invokes sMash operations via the CLI.
• Plug-in will not support create/delete of module groups; CLI is used for those operations.
• Plug-in cannot "switch" the CLI to another module group.

Roadmap

The first release should support:

• Create new sMash applications (user can select module group)
• Resolve runs automatically
• Update can be invoked explicitly on a project
• Run/debug sMash applications

• Edit ivy.xml with standard Eclipse editors
• No repository management
• Switch is handled via CLI
• No samples plug-in

From there, we'll look at prioritizing other features

• Specialized ivy.xml editor
• Repository manager (including way to change module group being managed)
• Replacement for the samples plug-in? Perhaps extend the "New sMash application" wizard with an optional "create from repository" w/ search and optional linkto.

Comments and open questions

• Forcing one module group per workspace seems like a reasonable limitation (for the first version). There is anecdotal evidence that folks are already doing this to manage sMash vs. trunk builds. And the current plugin environment does not play nicely if you need to load sMash and silverstone artifacts at the same time. Besides that, the problems below could be avoided which will allow us to get something out quickly and with the least amount of changes.
  • Will the workspace resolver do the right thing if there are applications pointing at different module groups? Allowing users to select mg per project will guarantee that multiple module groups will be in play.
  • The repository dialog will have to be updated to support multiple module groups eventually. However, if there is only one per workspace, we can reuse what's there and (using AppBuilder as our model) pretty easily retool it to call out to the CLI.
• We already have a specialized ivy.xml editor which should be agnostic to the other changes being considered. Why will that not work?
• It would be nice to eventually have a sMash JUnit launch which will handle the setting of java.library.path for us.

Work Items

Item	Priority	Status	Notes
Implement zero.cli.api	1	Started	Design and implementation will change as Eclipse is dissected and rebuilt.
Move plugins to DEVTOOLS	1	Done	Bug 5622
Resolve action	1	Done	Port implementation to new CLI API.
Update action	1	Done	New feature
New application	1	Done	Port implementation to new CLI API.
Remove example plugin	1	Done	Bug 5315
Resolved container	1	Done	Port implementation to new CLI API.
Local container	1	Done	Port implementation to new CLI API.
Application launch	1	Done	Continue using run for now. Need to add back missing Source tab.
ivy.xml editor	1	Done	Port implementation to new CLI API.
Update dependencies	1	Done	This button should be replaced by a call to "modulegroup update".
Manage repository	1	Done	Port implementation to new CLI API. Add update dependencies button.
Resolve automatically	1	Started	Requires Bug 6100
Preference page	1	Done	Change to allow user to point to CLI root directory. Also need module group selection.
Remove config editor	2	Done	Bug 6092
Marker resolution	2		Remove build.xml resolution handler.
GC view	2	Done	Bug 4231, Bug 5693
Markers	2	Started	Port implementation to new CLI API.
Export wizard	2	Started	Port implementation to new CLI API. Fix Bug 5837
Help	2	Done	We do not provide any Eclipse help. Remove all help crust from the plugin.xml.
Web browser action set	3	Done	Remove.
Create example from...	4		Future: Allow users to create examples from repository artifacts.
Import wizard	4		Future: Special import wizard which creates .project and .classpath files. Then we can remove these from the app template
JUnit launch	4		Future: JUnit launch that would configure java.library.path based on the natives value from resolved.properties.

Other

The items below correspond roughly to Eclipse extensions found in zero.eclipseui/plugin.xml and zero.eclipse.core/plugin.xml.

1. Project actions
   1. Resolve
   2. Update
2. New wizards
   1. New application
   2. New example
3. Classpath containers
   1. Resolved libraries
   2. Local libraries
4. Application launch
5. Editors
   1. ivy.xml
   2. config
6. Debug
   1. GC view
   2. Eliminate separate Java/PHP termination
7. Action sets
   1. WebSphere sMash
      1. Update dependencies
      2. Manage repository
      3. Resolve automatically
   2. Web browser
8. Preference page
9. Export wizard
10. Import wizard
11. Help
12. Marker resolution
    1. ivy.xml
    2. build.xml
    3. Resolve project
13. Markers
14. Project nature