I have created https://issues.apache.org/jira/browse/SLING-811 to track this.
Regards Felix Felix Meschberger schrieb: > 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 > >
