Quarkus: Declaring dependencies scopes in BOM is a bad practice

[aheritier]

It is impossible to override what you decided and sometimes you could have wrong.
Example: I create some reusable test code where junit or any test framework is a compile dependency instead and not a test one.

[kenfinnigan]

That's likely a bug for the test frameworks. Could you list those frameworks and maybe provide a PR setting the scope to "test" for them?

We need to align versions to ensure that what a users uses is what we've built against, which is especially important when compiling to native executable

[aheritier]

it's not on the test framework side @kenfinnigan it was just a sample.
As soon as you define a scope in a dependencyManagement (via the BOM import) all declarations of these dependencies will have this scope and thus you presume to know what your users will do with them.
It's better to define the scope at the dependency level inside the project and you only use the dependencyManagement to inject the version.

ex: https://github.com/spring-projects/spring-boot/blob/master/spring-boot-project/spring-boot-dependencies/pom.xml

With a sample it will be probably more easier

if in depMgt you have

<dependency>
  <groupId>foo</groupId>
  <artifactId>foo</artifactId>
  <version>1.2.3.4</version>
  <scope>test</scope>
</dependency>

In the deps you have

<dependency>
  <groupId>foo</groupId>
  <artifactId>foo</artifactId>
  <scope>compile</scope>
</dependency>

Then when Maven will resolve the POM it will use:

<dependency>
  <groupId>foo</groupId>
  <artifactId>foo</artifactId>
  <version>1.2.3.4</version>
  <scope>test</scope>
</dependency>

Because the depMgt resolution is based on groupId/artifactId (and classifier AFAIR).

@snicoll do I say something wrong in term of maven behavior and bad practice ??

[snicoll]

Bill of Materials should only define the groupId/artifactId/version of the modules that you are responsible for. It should not define a scope indeed.

[vorburger]

I agree with this view, based on having learnt to lesson the hard way... I used to think that putting e.g. <scope>test for e.g. JUnit & Co. in BOM was a Good Idea, but ultimately it's more confusing than useful - just putting the scope to where it's used is clearer.

[gsmet]

So I agree with that.

Note that the provided scope for our extensions should stay. It will go away at some point but for now, we want to keep it in the pom.

Note that we will need to check all the dependencies that are currently marked with test scope in Quarkus and in the quickstarts (doc + code).

[cescoffier]

It's only the test scope that need to be removed.