GRPC library content type breaks Nexus artifact storage #45685
Comments
|
/cc @alesj (grpc), @cescoffier (grpc) |
|
Is it related to gRPC or to the artifact resolver? |
|
From the report, it seems that the resolver is not using the right mime type. But the resolution is delegated to Maven/Gradle. Not sure we can do anything |
|
I'm not sure, Nexus is downloading the file just fine for Maven but when Nexus runs its validation on the mimetype it fails and doesn't put it into its cache and those artifacts are not available. Changing Nexus to NOT be strict about the mimetype makes it work which I'm fine with. I wasn't sure how the mimetype gets set on the artifact themselves which I think is what Nexus is looking at. Something in the metadata? Anyway, not sure how to fix it I just wanted to bring it up in case other Nexus users hit this. |
|
@tmulle just for testing purposes, would it work if you added |
|
@aloubyansky It doesn't work if I try adding the direct dependency. Again, the issue isn't the artifact isn't pulled by Maven. It's that Nexus is saying the metadata for that file is incorrect. Now, I don't know if that's true or not. I don't know how Nexus is determining what the metadata type should be. But the fact it works for other artifacts seems to me that Nexus is doing the correct validation check.
Like I said earlier, turning off the STRICT metadata check in the |
|
I'm trying to clarify which resolver fails to download it: the Quarkus one, the Maven one or both. |
|
@aloubyansky Ah ok, then YES when used a direct dependency maven fails to resolve the artifact itself just as before but with slightly different failure messages. Technically, Maven IS resolving the artifact because it pulling it from Maven central via Nexus it's just that the metadata inside those artifacts is midentified as "so" instead of "exe"? Here is the output from both direct dependency and without (normal). Before each run, I did a Normal Transitive Dependency - Causes Nexus Metadata errorPOM <dependencies>
<dependency>
<groupId>io.quarkus</groupId>
<artifactId>quarkus-grpc</artifactId>
</dependency>
<dependency>
<groupId>io.quarkus</groupId>
<artifactId>quarkus-arc</artifactId>
</dependency>
<dependency>
<groupId>io.quarkus</groupId>
<artifactId>quarkus-junit5</artifactId>
<scope>test</scope>
</dependency>
</dependencies>OUTPUTDirect Dependency - Causes Nexus Metadata errorPOM<dependencies>
<dependency>
<groupId>io.quarkus</groupId>
<artifactId>quarkus-grpc</artifactId>
</dependency>
<dependency>
<groupId>io.quarkus</groupId>
<artifactId>quarkus-arc</artifactId>
</dependency>
<dependency>
<groupId>io.quarkus</groupId>
<artifactId>quarkus-junit5</artifactId>
<scope>test</scope>
</dependency>
<dependency>
<groupId>io.grpc</groupId>
<artifactId>protoc-gen-grpc-java</artifactId>
<version>1.65.1</version>
<classifier>linux-aarch_64</classifier>
<type>exe</type>
</dependency>
</dependencies>OUTPUT Both methods cause Nexus to fail to store the artifact with this setting turned on on the repository and gives the error. Checkbox to turn on/off validation of MetaData: Turning it OFF (Unchecked) everything works fine, ON gives the error. 
ERROR
Hope this helps! That's all the info I have. |
|
@cstamas you may be interested in this one |
|
Basically you need override. I was involved in Nx2 and I know how to do it, but in Nx3.... let me check |
|
Related class seems same (and comes from Nx2), but Nx3 is full OSGi, so unsure where this change can be done, javadoc may give some help: |
|
@cstamas Thanks..unfortunately it looks like in 3.x adding new mime types is a pain and not very user friendly based on searching on the net. The quickest and easiest way to fix this is to just disable the "strict" checking of metadata on the repository in Nexus. That's what I did and things work fine. I'll close this with this comment since it seems to be on the Nexus side. Thanks all for looking into it, I just wanted to get the information out there for anyone else using Nexus 3.x as their mirrors of Maven central. |
Describe the bug
This isn't directly a Quarkus bug, but the GRPC library it uses in relation to Nexus/Maven.
We use a corporate Nexus proxy of Maven central as well as our internal libraries.
When trying to build with GRPC libraries in Quarkus I got the following error which ultimately caused Nexus to not store the artifact in the repo.
Turning off
strictmeta/mime-type validation on the Nexus repo fixes it, but it looks like the mimetype of GRPC is incorrect?I know most people probably don't use a Nexus Proxy and go straight to Maven Central, I just thought I'd bring it up to help those of us that do and save a day of troublshooting like it took me.
Expected behavior
Looks like Nexus thinks the mimetype should be one of:
expected [application/x-executable, application/x-dosexec, application/x-msdownload]Actual behavior
It Detected content type [application/x-sharedlib]
How to Reproduce?
Turn on
Validation of mimetypefor your repository storage for the Maven Central repo and try to build and you should see an error similiar to:Output of
uname -aorverlinux and osX
Output of
java -versionNo response
Quarkus version or git rev
3.17.5
Build tool (ie. output of
mvnw --versionorgradlew --version)maven
Additional information
No response
The text was updated successfully, but these errors were encountered: