I quickly drafted such an enforcer rule in https://github.com/apache/sling-maven-enforcer-rules/pull/2 <https://github.com/apache/sling-maven-enforcer-rules/pull/2>.
> On 23. Jun 2022, at 16:39, Konrad Windszus <[email protected]> wrote: > > What about a custom Maven enforcer rule “requireDependencyScope” (enabled in > sling parent) which would fail the build, in case a module relies on the > default scope/scope from the depMgmt? > That way for every dependency you have to make a distinct decision? > > Konrad > >> On 23. Jun 2022, at 16:31, Stefan Seifert >> <[email protected]> wrote: >> >> i'm for 2. as well - i'm following this best practices for years in all my >> projects. >> for consistency reasons i would also treat the testing dependencies the same >> (we have edge cases where testing dependencies are used as compile >> dependencies as well, e.g. for sling mocks). >> >> however, doing this switch now is dangerous, as you will get different >> dependency scopes probably without any warning or build failure if you >> carelessly update to latest parent POMs. >> >> stefan >> >> >>> -----Original Message----- >>> From: Konrad Windszus <[email protected]> >>> Sent: Thursday, June 23, 2022 4:17 PM >>> To: [email protected] >>> Subject: Sling Parent: Set scope in dependencyManagement? >>> >>> Hi, >>> Currently sling-(bundle)-parent always also managed the scope (in most >>> cases “provided”) for (almost all) its managed dependencies: >>> >>> https://github.com/apache/sling- >>> parent/blob/e42fd6e5fac8ed9becf722b5241d01d3147338c4/sling- >>> parent/pom.xml#L939-L1001 <https://github.com/apache/sling- >>> parent/blob/master/sling-parent/pom.xml#L939-L1001> >>> https://github.com/apache/sling- >>> parent/blob/e42fd6e5fac8ed9becf722b5241d01d3147338c4/sling-bundle- >>> parent/pom.xml#L208-L315 <https://github.com/apache/sling- >>> parent/blob/e42fd6e5fac8ed9becf722b5241d01d3147338c4/sling-bundle- >>> parent/pom.xml#L208-L315> >>> >>> IMHO managing the scope in the depMgmt is an anti-pattern [1], as it makes >>> it very hard to override the scope. Each consumer should decide on its own >>> which scope a dependency should have. >>> One concrete example being https://github.com/apache/sling-org-apache- >>> sling-testing-osgi-mock/blob/master/core/pom.xml >>> <https://github.com/apache/sling-org-apache-sling-testing-osgi- >>> mock/blob/master/core/pom.xml> which depends on a lot of OSGi dependencies >>> which usually have scope “test” for consuming bundles, but the transitive >>> dependency scope is actually overwritten to “provided" due to the use of >>> our sling-parent. Removing the scope though is potentially backwards- >>> incompatible though. >>> >>> So what should we do in the future? >>> >>> 1. Stay with declaring the scope in the depMgmt (and also add “provided” to >>> the few one, where scope is not yet managed) >>> 2. Remove scope from all dependencies except for pure testing dependencies >>> (junit, ….) >>> >>> I would tend to implement option 2. >>> WDYT? >>> >>> Thanks, >>> Konrad >>> >>> [1] - https://stackoverflow.com/a/20750041 >
