[Extension Proposal] Enforcer extension

[gastaldi]

Description

The idea of this extension is analogous to the Maven Enforcer Plugin: introduce Build Items to control certain environmental constraints such as Quarkus version, JDK version, and OS family along with many more built-in rules and user created rules.

Also a potential solution for #37169

Interested in this extension, please +1 via the emoji/reaction feature of GitHub (top right).

Repository name

quarkus-enforcer

Short description

Control certain environmental constraints and fail the build if they don't match

Repository Homepage URL

https://docs.quarkiverse.io/<REPOSITORY_NAME>/dev/

Repository Topics

• quarkus-extension
• enforcer

Team Members

• @gastaldi

Additional context

No response

[quarkus-bot]

/cc @aloubyansky (extension-proposal), @gsmet (extension-proposal), @maxandersen (extension-proposal)

[aloubyansky]

How would that work as an extension?

[gastaldi]

@aloubyansky I thought of introducing a MinimumQuarkusVersionBuildItem which other extensions could produce and we perform the check here in a build step, failing the build (or logging a warning) if the expected version doesn't match

[aloubyansky]

This is a kind of static config validation. Ideally this kind of validation should be performed before the augmentation process starts.

[gastaldi]

Right, I haven't yet checked if it might need some changes in core to allow that, but I agree

[aloubyansky]

We have a few other validation checks in this category that are performed in build steps.
@dmlloyd would you like to get them moved to pre-augmentation phase?

[aloubyansky]

I think it may justify some changes in core.
Specifically, we could introduce a proper config validation phase.
That would include version alignment checks (currently we check platform member bom version alignment), possibly capability requirements check (required and provided + conflicts).

[dmlloyd]

I think that would make sense.

[geoand]

What problem is this new extension going to solve?

[gastaldi]

@geoand one use case is that extensions could specify the minimum Quarkus version they require to function (because they use an APi introduced from that version onwards). This would hopefully avoid CNFE and method signature errors during the application's build time

[geoand]

That makes perfect sense, but is an extension the proper way to do this, or would the changes in the core that Alexey mentions suffice?

[gastaldi]

I am not sure yet what changes in core would need to be done to support this. My initial idea was so that extensions would produce BuildItems for the environment they would require and we'd consume them and fail the build if there is a mismatch

[geoand]

My feeling is that we could support this functionality without an extension, as it would essentially be static information that does not have to interact with the rest of the build - just prevent it if need be :)

[maxandersen]

Like others I'm not following how this would be useful as independent extension or are you assuming core will depend on it?

[gastaldi]

Because an extension would (in theory) not require changes in core and would work when an extension depending on it is included in an app using any existing Quarkus version

[aloubyansky]

@gastaldi do i remember correctly that you mentioned there was a "min Quarkus version" field in extension metadata already? Could you please link to an example? Thanks.

[gastaldi]

@aloubyansky sorry I wasn't clear, I meant that we have the built-with-quarkus-core: "3.8.4" in the quarkus-extension.yaml metadata, not the minimum Quarkus version an extension supports

[aloubyansky]

ok, so the question is how extensions would declare their Quarkus version compatibility compatibility requirements.
Build items or metadata. Both would be pretty much be fixed at extension build time, which is a limitation when it comes to not yet released Quarkus versions.
Either way, I would prefer metadata as the source of this data.

[geoand]

Either way, I would prefer metadata as the source of this data.

Definitely +1

[gastaldi]

How about we introduce a quarkus-core-compatibility: [3.8.4,) metadata featuring a version range that could be checked somewhere in core?

Default would be [${built-with-quarkus-core},)

[aloubyansky]

A version range would be a natural first step. BTW, don't we have the next Quarkus major version as the upper limit when displaying extensions on code.quarkus or even in the registry?

I don't think we want to default to [${built-with-quarkus-core},) exactly, since that will put a limit on the micro version, which is updated often. We should probably be defaulting to major.minor.0, which seems to be too limiting too considering the frequency of releases. Tricky...

[gastaldi]

Maybe use streams instead (no patch version). In theory we shouldn't introduce API changes in patch releases, but who knows :)

[maxandersen]

@gastaldi streams does not exist on quarkus extension level its a platform level thing. And there are multiple platforms with possible different versions ranges.

@aloubyansky using build with quarkus core as the fallback default if nothing else seems fine to me? or are you saying default should be the major/minor of built-with-quarkus-core, ie. if build with 3.10.2 we default to [3.10,] to say 3.10 and future ? that could work.

[aloubyansky]

Yes, I was thinking of quarkus-core major.minor as a start.

[gastaldi]

Yes, I was thinking of quarkus-core major.minor as a start.

+1, that's what I meant when I said to use streams

[gastaldi]

Closing as the requires-quarkus-core seems to suffice for now