Hi all, Maven provides projects with a nice feature called dependency management. In Sling we currently use this feature to declare the non-Sling dependencies of modules in the parent POM.
After working with this some time and trying to upgrade various dependencies I come to the conclusion, that using Maven dependency management is not going to work out in our scenario. Why ? Maven's Dependency Management is aimed at traditional applicaitons, which are glued together statically during the build process. For this environment, dependency management is a great thing, since it guarantees a consistent application setup. In a dynamic application setup as provided by an OSGi framework the static dependency management of Maven does not help. Actually it even causes problematic results with respect to backwards compatibility when using the Maven Bundle plugin. Why's that ? The Maven Bundle plugin is constructs the bundle manifest and will generally automatically create the Import-Package header. If the providing library (from maven's dependency list) has Export-Package headers with version numbers, the Maven Bundle plugin will insert the respective version numbers for Import-Package. This makes perfect sense, because it is expected, that the artifact required at least the given package version. When using Maven Dependency Management, upgrading any dependencies in the parent POM may automatically increse the version numbers in the Import-Package headers and hence may cause any such bundle to fail resolution if deployed - even though the bundle did not change and does not really require a new version of the dependency. So, in the case of OSGi deployment, Maven's Dependency Management actually interferes with the OSGi framework dependency management. As a consequence, I suggest we drop dependency management in the parent pom (almost) completely and state, that #1 each module must fully describe its dependencies Some dependencies should probably be considered globally valid and will still be available through dependency management: JCR API (1.0) Servlet API (2.4) OSGi APIs (should generally be R4 based) #2 each dependency version must be to the lowest possible number This ensures that Import-Package version numbers will not increase needlessly. Dependency version numbers should primarily be based on API-functionality. Any higher version required due to bug-fixes in the implementation is not an issue for a module to care about. #3 keep dependency management for plugins (plugin management) Plugin management is concerned with the build process only and it makes perfect sense to keep this support and functionality. Regards Felix
