Junit5: Publish default scope 'test' in junit-bom

[marcphilipp]

In order to prevent users from accidentally introducing compile dependencies on JUnit artifacts, we should set the default scope to test for all artifacts in the junit-bom.

Deliverables

• [ ] Set scope to test for all artifacts.
• [ ] Check that the scope defined in a BOM is actually applied in a project that imports the BOM.

[sbrannen]

I've done a bit of research, and I have discovered contradicting opinions.

Some people say that defining a default scope in the dependencyManagement section of a BOM is a _best practice_; whereas, other people suggest that no scope be defined in the dependencyManagement section.

As a concrete example, the spring-boot-dependencies BOM does not declare <scope>test</scope> for spring-boot-starter-test. Consequently, when generating a Spring Boot project at http://start.spring.io, the resulting pom.xml contains the following (with an explicit declaration of <scope>test</scope>).

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-test</artifactId>
    <scope>test</scope>
</dependency>

@snicoll, what is your take on the matter?

Should the junit-bom declare <scope>test</scope> for all artifacts in the junit-bom?

Or could that cause problems for people who are actually authoring extensions for JUnit and need <scope>compile</scope> (granted, we know that extension authors would explicitly have to specify compile scope if we make the change proposed in _this_ GitHub issue)?

[snicoll]

Should the junit-bom declare test for all artifacts in the junit-bom?

I guess you know my answer to that, right? We don't because we believe that it has to be explicit. Not adding a default scope means compile in Maven land. Most dependencies don't have a scope because users know this and that they have to add a scope only when it deviates from the default.

If you read a project that uses a bom that overrides the default scope for a dependency, not having the scope doesn't mean the same thing anymore. But you have to be aware of that fact to be able to register. It is way too confusing and I highly recommend you not to do this.

(Also, projects that integrate with JUnit for adding additional features would have to flag those dependencies with <scope>compile</compile> and that looks really weird to me).

[sbrannen]

I guess you know my answer to that, right?

Well.... let's just say I had a sneaking hunch what your answer might be, but I wanted to be certain. 😉

It is way too confusing and I highly recommend you not to do this.

Understood.

Thanks for taking the time to chime in with your wisdom. Much appreciated!

@junit-team/junit-lambda, in light of this, I vote to close this issue and leave the BOM _as is_. Thoughts?

[marcphilipp]

Agreed.

[sbrannen]

OK, since I've received 2 * 👍 plus my own, I am closing this issue.

[bobtiernay-okta]

Unrelated, but curious if others in this issue believe this holds true for general reactor builds. That is, you should never declare a <scope/> in _any_ <dependencyManagement/> element.