Any pom in dependencyManagement will lead to 403 in maven company mirrors #1819
Comments
|
Here is an example: After removing the reactor root itself from the reactor root's |
|
@bmarwell Thank you for reporting this. @jjiwooLim Sara, can you please look into this? |
|
As a workaround, we disabled the 403 on internal groupIDs in nexus. A 404 works with this plugin. However, a blocked route is a common setup for company repositories/mirrors. |
|
Hi @bmarwell and continue with the installation. I tried setting up the Nexus repo with the routing rule and also with the access control to force return code 403. However, instead of throwing NPE, it threw a warning like expected and the build was successful. Full stacktrace: I see that our stack traces look slightly different but I am not sure where the difference comes from. |
|
Hi, maybe because I do have splitRepo enabled? All configuration options are here: Intro: https://maven.apache.org/resolver/local-repository.html Please also note I am adding a my reactor's root pom there, maybe that is a difference, too? I am using both Maven 3.9.8 and Maven 4.0.0-beta, that might be yet another difference. |
|
@jjiwooLim Is there any code change we can do to help here? I see you have not been able to recreate, right? |
|
I don't quite grasp the use case for this "additional user feature" magic (dependencyManagement -> dependency[type=pom] -> mangle artifactId to "features"). Here in my installation, for this fabricated artifact coordinates, nexus server returns HTTP 200 with an entity describing an error (go figure) and liberty-m-p doesn't have a chance to ignore it before it blows up the install-feature command. As a workaroung I'm downgrading liberty-m-p to 3.4 (before introduction of this "additional user feature") since I don't have enough power to change the nexus server, nor the dependencyManagement at project's pom.xml. It would be nice to have some switch to turn off this magic. |
|
@jjiwooLim Please see the latest update from an external user where they are forced to down level their LMP version to avoid a "blow up" error. We need to fix this somehow. |
|
Here are some excerpts from full Features declared nowhere, introduced by magic(in itself already problematic since it took me a long time to track down what those features were and where were they even mentioned, before realizing they were invented by LMP) Download and validation and failure to validate (here just once for "net.corp.my.bridge:features:1.7.0")Earlier I said that nexus returned HTTP 200 along with an entity describing an error. Actually I cannot be 100% sure it is an HTTP 200; all I can say for sure is that the contents of Wrap up and final blow upFull log |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hi,
I just stumbled over this odd behaviour:
Source:
ci.maven/liberty-maven-plugin/src/main/java/io/openliberty/tools/maven/InstallFeatureSupport.java
Lines 152 to 171 in 7f57aff
However, in a lot of company environments, this might lead to the following behaviour:
my.company.app:featureswas not foundThis is not an unlikely situation.
I like to specify all my project's modules in
<dependencyManagement>and I consider it surprising behaviour for a plugin to "make up an artifact" and to fail the build if a 403 of a made-up artifact is being encountered.I do not even see a documentation which says "for every pom we encounter in dependencyManagement, the articfactId is replaced with "features" and then reseolved". Is this really an undocumented feature?
The text was updated successfully, but these errors were encountered: