The platform maven resolver doesn't use the correct platform groupId when it's set via a maven property from a profile in the pom.xml #8382
Comments
|
/cc @quarkusio/devtools |
aloubyansky
pushed a commit
to aloubyansky/quarkus
that referenced
this issue
Apr 8, 2020
Unfortunately (or fortunately) it comes with a refactoring in the bootstrap maven resolver initialization.
Which also allowed me to add more tests to the TS (since previously a lot of the resolver parts where cached
using static variables and made it problematic).
One of the behavioral changes (that fixes the issues mentioned above) is that now, if the workspace discovery
is enabled (which now is the default) the resolver initialization will be performed in the context of the current
project (if there is one, this would usually be relevant when running tests), which includes repository configurations.
MavenRepoInitializer is now deprecated. Most of its logic has been copied to BootstrapMavenContext which is
initializing the relevant parts lazily whenever they are needed. MavenArtifactResolver which is the main resolver API
our build is using, is initialized from an instance of BootstrapMavenContext now. MavenArtifactResolver.Builder extends
BootstrapMavenContextBuilder which exposes a lot more options, if necessary.
aloubyansky
pushed a commit
to aloubyansky/quarkus
that referenced
this issue
Apr 8, 2020
Unfortunately (or fortunately) it comes with a refactoring in the bootstrap maven resolver initialization.
Which also allowed me to add more tests to the TS (since previously a lot of the resolver parts where cached
using static variables and made it problematic).
One of the behavioral changes (that fixes the issues mentioned above) is that now, if the workspace discovery
is enabled (which now is the default) the resolver initialization will be performed in the context of the current
project (if there is one, this would usually be relevant when running tests), which includes repository configurations.
MavenRepoInitializer is now deprecated. Most of its logic has been copied to BootstrapMavenContext which is
initializing the relevant parts lazily whenever they are needed. MavenArtifactResolver which is the main resolver API
our build is using, is initialized from an instance of BootstrapMavenContext now. MavenArtifactResolver.Builder extends
BootstrapMavenContextConfig which exposes a lot more options, if necessary.
viniciusfcf
pushed a commit
to viniciusfcf/quarkus-fork
that referenced
this issue
Sep 7, 2020
Unfortunately (or fortunately) it comes with a refactoring in the bootstrap maven resolver initialization.
Which also allowed me to add more tests to the TS (since previously a lot of the resolver parts where cached
using static variables and made it problematic).
One of the behavioral changes (that fixes the issues mentioned above) is that now, if the workspace discovery
is enabled (which now is the default) the resolver initialization will be performed in the context of the current
project (if there is one, this would usually be relevant when running tests), which includes repository configurations.
MavenRepoInitializer is now deprecated. Most of its logic has been copied to BootstrapMavenContext which is
initializing the relevant parts lazily whenever they are needed. MavenArtifactResolver which is the main resolver API
our build is using, is initialized from an instance of BootstrapMavenContext now. MavenArtifactResolver.Builder extends
BootstrapMavenContextConfig which exposes a lot more options, if necessary.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the bug
The platform maven resolver doesn't use the correct platform groupId when it's set via a maven property from a profile in the pom.xml
It works if the property is in the global properties, or defined with -D...
Quarkus version: 1.3.1.Final
The text was updated successfully, but these errors were encountered: