This is an automated email from the ASF dual-hosted git repository. kwin pushed a commit to branch feature/clarify-dependency-policy-of-bundles in repository https://gitbox.apache.org/repos/asf/sling-site.git
commit de476c68ba1fd2e91f6cfd70c68f2b09d4a3bb45 Author: Konrad Windszus <[email protected]> AuthorDate: Wed Dec 6 17:20:25 2023 +0100 Clarify dependency policy of Sling bundles --- .../development/dependency-management.md | 28 ++++++++-------------- .../jbake/content/project-information/security.md | 4 ++++ 2 files changed, 14 insertions(+), 18 deletions(-) diff --git a/src/main/jbake/content/documentation/development/dependency-management.md b/src/main/jbake/content/documentation/development/dependency-management.md index c8e30d72d..1b0daba83 100644 --- a/src/main/jbake/content/documentation/development/dependency-management.md +++ b/src/main/jbake/content/documentation/development/dependency-management.md @@ -15,22 +15,21 @@ Maven provides projects with a nice feature called dependency management. In Sli After working with this some time and trying to upgrade various dependencies we came to the conclusion, that using Maven dependency management is not going to work out in the Sling 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. +Why? Maven's dependency management is aimed at traditional applications, 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 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 the `Import-Package` header. This makes perfect sense, because it is expected, that the artifact required at least the given package version. +Why's that? The Maven Bundle Plugin (or rather the underlying [Bnd library](https://bnd.bndtools.org/) 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 the `Import-Package` header. This makes perfect sense, because it is expected, that the artifact required **at le [...] When using Maven dependency management, upgrading any dependencies in the parent POM may automatically increase 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 the following. +As a consequence, we dropped dependency management in the parent POM (almost) completely and state the following. ## Dependency Management - The parent POM only does dependency management for build time dependencies and a very limited number of API dependencies used Sling wide. These dependencies are: * All plugin dependencies. That is `pluginManagement` is still used. Maven plugins are actually build time dependencies and therefore have no influence on the actual deployment. @@ -39,28 +38,21 @@ The parent POM only does dependency management for build time dependencies and a The `<dependencyManagement>` element currently contains the following managed dependencies: -| Group ID | Artifact ID | Version | Scope | -|---|---|---|---| -| org.osgi | org.osgi.core | 4.1.0 | provided | -| org.osgi | org.osgi.compendium | 4.1.0 | provided | -| javax.servlet | servlet-api | 2.4 | provided | -| javax.jcr | jcr | 1.0 | provided | -| org.slf4j | slf4j-api | 1.5.2 | provided | -| org.apache.felix | org.apache.felix.scr.annotations | 1.9.8 | provided | -| biz.aQute | bndlib | 1.50.0 | provided | -| junit | junit | 4.11 | test | -| org.jmock | jmock-junit4 | 2.5.1 | test | -| org.slf4j | slf4j-simple | 1.5.2 | test | +* OSGi spec chapter dependencies (in sling-bundle-parent) +* Some testing libraries (like JUnit) +* Some common JSRs (Servlet, JCR, JSR-330) +* SLF4J +For details refer to the `pom.xml` of [sling-bundle-parent](https://github.com/apache/sling-parent/blob/master/sling-bundle-parent/pom.xml) and [sling](https://github.com/apache/sling-parent/blob/master/sling-parent/pom.xml). All dependencies per module are fully described in terms of version, scope, and classifier by the respective project. -The version of the module dependency should be selected according to the following rule: The lowest version providing the functionality required by the module (or bundle). By required functionality we bascially mean provided API. +The version of the module dependency should be selected according to the following rule: **The lowest version providing the functionality required by the module (or bundle)**. By required functionality we basically mean provided API. Generally there is a constant flow of releases of dependent libraries. In general this should not cause the dependency version number of a using module to be increased. There is one exception though: If the fixed library version contains a bug fix, which has an influence on the operation of the module, an increase in the version number is indicated and should also be applied. ## References -* [Dependency Management](http://markmail.org/message/5qpmsukdk4mdacdy) -- Discussion thread about reducing Maven Dependency Management +* [Dependency Management](https://lists.apache.org/thread/gbx1t3kfcvqkoljb8mk7ymow94kn2m2o) -- Discussion thread about reducing Maven Dependency Management * [SLING-811](https://issues.apache.org/jira/browse/SLING-811) -- The actual issue governing the changes to the project descriptors diff --git a/src/main/jbake/content/project-information/security.md b/src/main/jbake/content/project-information/security.md index f4c676941..46c939492 100644 --- a/src/main/jbake/content/project-information/security.md +++ b/src/main/jbake/content/project-information/security.md @@ -12,6 +12,10 @@ We strongly encourage folks to report such problems to our private security mail *Please note that the security mailing list should only be used for reporting undisclosed security vulnerabilities in Apache Sling and managing the process of fixing such vulnerabilities. We cannot accept regular bug reports or other queries at this address. All mail sent to this address that does not relate to an undisclosed security problem in the Apache Sling source code will be ignored.* +In Sling OSGi bundles we have long had a policy of depending on the lowest possible version of a library/API, to ensure that our bundles are deployable in the widest possible range of environments. Therefore the responsibility of +ensuring that the environment is secure lies with the assembler and/or deployer of the application, which should make sure that the OSGi bundles they deploy are secure. As such, **we don't consider vulnerable dependencies of our bundles as security issues** by themselves. Usually the dependencies used by Sling [are semantically versioned](https://docs.osgi.org/whitepaper/semantic-versioning/index.html) and therefore security related version updates are fully binary backwards-compatible. +Further detail and some exceptions from that policy are outlined in [our wiki](https://cwiki.apache.org/confluence/display/SLING/Dependabot). + If you need to report a bug that isn't an undisclosed security vulnerability, please use our [public issue tracker](https://issues.apache.org/jira/browse/SLING). Questions about:
