Mevenide2IDEAProjectModules

Architecture proposal for the Mevenide2 IDEA plugin 

This is just an initial proposal for modules of the Mevenide 2 for IDEA project. So far I have identified 6 main components which could be separated into single modules under the IDEA parent module:

1. IDEA component (Maven Reloaded => Dependency Management, dependency analysis, classpath issues, module dependencies)
2. Build component (MAIDEA (aka Maven2 Integration => Run Maven from IDEA)
3. Repository component (Searching local and remote repos)
4. Project component (create Maven 2 project from scratch or from existing sources => archetype)
5. Continuum component
6. Archiva component??

I also would like to suggest a tool for architecture management. I have made good experiences with SonarJ which comes free of charge for open source projects.

Modules and update management

I really would like to make these modules as independent from each other as possible. It would be great if those modules are themselves some kind of plugin which rely on a core module (or plugin) providing base functionality for all other child modules. Even more better it would be to have an update mechanism for each module.

The core module should provide at least the following mechanisms:

• Externalizing of configuration settings (reading and writing)
• Initialization of child modules (plugins)
• Presentation and control of configuration dialog

The child modules register themselves in the core module (implementing special interfaces) and should provide at least the following features:

• Configuration dialog form (the view)
• business logic (e.g. run maven, repository search, continuum support, etc..)

In principle, all they have to provide (and implement) is defined in the IDEA class: com.intellij.openapi.components.ProjectComponent. As a matter of fact, the interface(s) provided by the core plugin should almost never change!

I think there are a few possibilities to achieve this. However each of it seem to have its drawbacks:

1. Make all modules a separate IDEA plugin depending on a core plugin (all modules can be updated separately)

Advantages:

• Plugins (and therefore modules) can be updated via the standard IDEA update mechanism
• Plugins can rely on other plugins by using standard plugin.xml features
• The core plugin bundles most of the necessary libs (maven-embedder, etc.) which don't have to be bundled again in the other plugins

Disadvantages:

• Each module will be represented as a single plugin in the Plugin Manager and has to be updated accordingly
• The dependency management between plugins doesn't offer some kind of version ranges. This means, that if the core module is updated (and maybe interfaces have changed), the user has to update all depending modules manually (not sure about this, have to check)
• Furthermore, if some child module A was updated and there is need to update the core plugin as well, other child modules relying on the core have to be updated manually (have to check this one too)

2. Implement module management for a single IDEA plugin (all modules can be updated separately)

Advantages:

• Total control of modules and their dependencies (versions, update mechanism, etc..)
• The Mevenide plugin is the only plugin appearing in the plugin manager
• Modules can be updated separately by using a self implemented module update manager

Disadvantages:

• The implementation of a module management and update mechanism is very complex
• The consistency of the IDEA update mechanism is lost. The plugin manager is not the only place to update plugins

3. Create a single IDEA plugin (modules can not be updated separately)

Advantages:

• Lower complexity than alternative 2.
• The Mevenide plugin is the only plugin appearing in the plugin manager

Disadvantages:

• The plugin must be updated all at once, even if only bugs were fixed in a particular module
• The user has to take all or nothing

Recommendation

In my opinion alternative 1 seems to be the best choice. The only negative thing I can see is that each module appears as a plugin in the plugin manager and must be updated manually. Another minor drawback would be the missing version management in the plugin dependencies, but the lack of version management is acceptable.

Alternative 3 might also be a good choice. Although it is lacking the feature of update management for each module we can start designing it as mentioned in the section about update management and decide later if we want to implement our own update manager or use the standard IDEA way (which leads to alternative 1).

Any comments or suggestions are highly appreciated.