fix(locker): omit scope in locked deps

[frederikb]

Drop dependencyManagement entries for locked dependencies since they do not influence resolution and add noise.

Update ITs to assert that no scope is emitted in locker BOM and in-profile modes.

This will cause changes in the generated POM for all consumers who have specified for org.mvnpm and org.webjars dependencies.

Fixes #23

---

@ia3andy Did I understand your issue and reasoning correctly? That <scope> is transiently inherited anyway and thus specifying it in <dependencyManagement> is henceforth just noise?

I opted to simply adjust the existing ITs to ensure this behavior. One could of course explicitly check for the absence of <scope>, if you want.

for example via:

XmlAssert.assertThat(Files.readString(lockedPom))
    .withNamespaceContext([pom: "http://maven.apache.org/POM/4.0.0"])
    .as("check that dependency scopes are not added to the 'locker' dependencies")
    .doesNotHaveXPath("//pom:profile[normalize-space(pom:id)='locker']/pom:dependencyManagement/pom:dependencies/pom:dependency/pom:scope")

[ia3andy]

Thanks!

[ia3andy]

Why are they added and not removed?

[frederikb]

These are the original dependencies, not the "locked versions". Here, we must not change the defined scope as this is an explicit intent of the developer depending on how they will use the dependencies, i.e. served at runtime or transformed/bundled during build time.

I adjusted the original input pom.xml to therefore explicitly state <scope>s in order to showcase that with the applied template change we ensure that these scopes are not transferred to the definitions of the "locked versions" in the locker profile/POM <dependencyManagement> section.

Does that answer your question?

[ia3andy]

Cool thanks!