Ability to provide scope when adding an extension

[brunowego]

Description

Currently when adding new extension none scope is provided. Adding this ability will encourage users to user more scope:

<dependency>
  <groupId>io.quarkus</groupId>
  <artifactId>quarkus-jdbc-h2</artifactId>
  <scope>test</scope>
</dependency>

Implementation ideas

mvn quarkus:add-extension \
  -Dextensions='jdbc-h2:test'

[holly-cummins]

I think this is very closely related to #34021. It's not quite a duplicate since here the scope is user-specified, not configured by the extension. #34021 talks about both user-specified and extension-defaults.

For the example of H2, I'm not sure it makes sense for the extension to set a default scope of test, so I think we would need the ability for users to specify when adding. Keeping this open to ensure we cover both cases.

[holly-cummins]

Pasting this comment from #34021, since I've shifted the scope of that WI to reduce overlap with this one.

This WI should cover both:

• Allow users to pass a scope on quarkus ext add to add either a --test flag or a --scope=test
• Allow extensions to specify a default scope in their metadata, and honour it

I've noticed that we don't have a clean way to add test-scoped extensions using quarkus ext add, so people have to edit the pom directly, which @maxandersen tells me is definitely not the preferred way. :)

We could do either of the following

Update quarkus ext add to add either a --test flag or a --scope=test option. The first one is shorter, but potentially confusing because it could mean something like a dry run flag. Add a new metadata in quarkus-extension.yaml which defines a preferred scope (maybe preferred-scope: test) that defaults to compile. Then the ext add command can use this metadata to set the right scope.

Of those two, the metadata has less opportunity for user error, and it lets us display the correct command on http://extensions.quarkus.io/.

I noticed this for the pact extension, but some other extensions would also benefit from this, such as quarkus-jacoco and quarkus-junit5-mockito and quarkus-junit5-component.

@aloubyansky says

"We could consider configuring quarkus launch modes instead: prod, test, dev and then map that to the corresponding maven and Gradle classpath. Otherwise we may need to configure the target classpath/scope for each build system in the extension metadata. I can imagine there will be more requests for dev mode only dependencies if we go with launch modes, which would be easy in case of Gradle."

The dev mode case is a bit complex, so I will start with test scope, since there's a clean mapping between launch mode and maven/gradle scope. Implementation ideas

[holly-cummins]

See also #26700.