Duplicate dependencies issue
BEAM until 4.10:
- no differentiation between system modules and plugin modules
- all are aggregated by the main POM like this:
- 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
BEAM >= 4.10.1:
- 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 (
- 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 (
- 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
Discussion of 'provided'-scope:
- 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-readerin 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
- 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