Maven Module Dependency Problems

Duplicate dependencies issue

no differentiation between system modules and plugin modules
all are aggregated by the main POM like this:
<module>beam-ui</module>
<module>beam-envisat-reader</module>
plugin versions need to appear in the parent POM's dependency management, so that plugins depending on other plugins don't need to manage the versions themselves, which otherwise could easily lead to duplicate artifacts with different versions.
So, changes in the plugins must be reflected in the parent POM's dependencies. This again changes the parent module's version number, which again must be reflected in all aggregated modules.

See image below for an overview of the architecture

Idea: separate system-level modules from plugin modules
parent POM containing repository management, distribution management, build information, and metadata information
Version: currently '1', independent from release versions, because changes are only rarely expected

beam-system POM: aggregator for system level modules (<module>beam-ui</module> etc)
dependency management for system level modules, ceres modules, and third-party libs (JAI, JDOM etc)
Version: currently '4.10.4-SNAPSHOT'; must correspond to current BEAM version
all system-level modules inherit that version

beam-plugins POM: aggregator for all plugins (<module>beam-envisat-reader</module> etc)
knows no version whatsoever
has version 1-SNAPSHOT, which is never changed; thus, adding a plugin will not force other plugins to increase their version number

beam-plugin-parent POM: serves as parent to all plugins without having a reference to them at all
it solely provides the dependency management for the BEAM system level modules, ceres modules, and third-party libraries
it uses version ranges for the BEAM and ceres modules; thus:
- the latest version available is used
- no duplicate artifacts with different versions can occur in the assembly
Version: currently '1.0', independent from release versions, because changes are only rarely expected
the plugin modules are all versioned independently

See image below for an overview of the new architecture

we have a problem regarding duplicate versions we could solve using the scope 'provided' for dependencies from plugins to other plugins
using scope 'provided', the needed dependencies are considered to be present in the assembly
if some plugin had a dependency to, say, beam-envisat-reader:1.4, while the container has a dependency to beam-envisat-reader:1.5, we would end up having duplicate versions of beam-envisat-reader in the assembly. Using the scope 'provided', only the container version would be used --> no duplicate versions
the same holds for 3rd party libraries, so, 3rd party libs should have scope 'provided', too

however, 'provided' draws problems when modules shall be tested from the IDE without BEAM environment
real-world example: main class showing some GUI, depending on module org.esa.beam.blue-marble-worldmap
in such a case, the classpath is not complete, because 'provided'-artifacts are not put onto the classpath

such problems are easily solved by updating the runtime-configuration of the main class being used
see below for instructions on how to add dependencies on the class path in IDEA 11:
- open the project structure dialog (Ctrl-Alt-Shift-S)
- choose 'Project Settings' -> 'Modules'
- on the right, choose tab 'Dependencies'
- click the '+'-button, choose 'jars or directories'
- choose the jar you want to add to your classpath, e.g. from your local maven repository
- choose 'Ok'
- You're done! Note that this configuration solely affects your IDEA configuration, no maven files will be touched