yes, this sounds like a reasonable solution. it's surprising that there is not already such an enforcer rule ready-to-use.
stefan >-----Original Message----- >From: Konrad Windszus <[email protected]> >Sent: Thursday, June 23, 2022 4:39 PM >To: [email protected] >Subject: Re: Sling Parent: Set scope in dependencyManagement? > >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 <Stefan.Seifert@diva- >e.com.INVALID> 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
