cziegeler commented on code in PR #149: URL: https://github.com/apache/sling-site/pull/149#discussion_r1431172707
########## 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. Review Comment: This change looks good ########## 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 least** the given package version. Review Comment: This change looks good -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
