Hello! I'm having issue with what I believe are tr...
# community-support
m
Hello! I'm having issue with what I believe are transitive dependencies. Could I have some help figuring out why my dependencies aren't being resolved via maven central? Details in the thread
Here's the main issue:
Copy code
> Could not resolve all files for configuration ':diarcRosCompileClasspath'.
   > Could not resolve org.apache.commons:com.springsource.org.apache.commons.logging:1.1.1.
     Required by:
         project : > rosjava_core:rosjava:0.0.0
      > Could not resolve org.apache.commons:com.springsource.org.apache.commons.logging:1.1.1.
         > Could not get resource '[private repo]/org/apache/commons/com.springsource.org.apache.commons.logging/1.1.1/com.springsource.org.apache.commons.logging-1.1.1.pom'.
            > Could not HEAD 'private repo]/org/apache/commons/com.springsource.org.apache.commons.logging/1.1.1/com.springsource.org.apache.commons.logging-1.1.1.pom'. Received status code 500 from server: Unable to fetch artifact resource.
I have project A that publishes to my maven local. Its pom seems to be valid:
Copy code
<dependency>
      <groupId>org.apache.commons</groupId>
      <artifactId>com.springsource.org.apache.commons.logging</artifactId>
      <version>1.1.1</version>
      <scope>compile</scope>
    </dependency>
Project B consumes this jar and uses it in another task. In project B, I have my repos organized like so:
Copy code
repositories {
  mavenCentral() // main maven archive
  mavenLocal() // local maven archive
  maven { // archive
    name = "[private archive"
    url = uri("[private archive]")
    isAllowInsecureProtocol = true
  }
}
My main question is, why can't this dependency resolve from maven central? Even declaring it as an explicit dependency instead of a transitive one doesn't solve the issue - it always fails at my private repo even though it's last in the order.
c
Gradle will skip over repos that don’t have the requested content (and, not all content is mandatory - those HEAD requests check for existence); however, if there are errors communicating with the repo those become failures, such as
Received status code 500 from server: Unable to fetch artifact resource.
- for some reason your private repo is failing on these requests.
m
Does it not then attempt to resolve from the other repos?
c
not if there is a hard failure; the correct responses for a HEAD request are 200 (if the content exists) or 404 (if it does not), you’ll need to track down why your private repo is misbehaving.
m
Will do, thanks so much!! In the meantime, is there a way to exclude my private repo when trying to resolve these dependencies? Or a way to manually specify to look in mavenCentral in project B in my top level dependencies?
Also, I thought that the order mattered for the repository list. Shouldn't it attempt maven central first?
c
you can look into Repository Content Filtering; if your private repo is not an aggregate/proxy for upstream repos you’ll likely want to only allow your packages to be resolved from the private repo.
The order does matter - its likely that the requested content is not in any of those repos (perhaps its optional, or perhaps its in a Spring-specific repo).
I feel like it should resolve with this, no?
c
that’s the root of it - would need to check if the specific artifact is indeed present underneath that.
it is listed as being in a “Spring Lib Release” repo, so perhaps Maven is simply providing some metadata, requiring that you also use a Spring repo for that.
that’s also a Very Dated (2009) artifact - likely worth tracking down where that is getting pulled in from and uplifting it.
It references https://repo.spring.io/libs-release/, which doesn’t seem to contain that package (or, really, many packages, certainly nothing recent).
m
Yeah I was flipping through that as well... Alright, I'll try lifting the version. Thanks so much for your help.
👍 1
v
Don't confuse
<http://mvnrepository.com|mvnrepository.com>
with Maven Central, both have nothing to do with each other directly
<http://mvnrepository.com|mvnrepository.com>
is a page that indexes multiple Maven repository servers so that you can search where in the supported repositories you can find a specific dependency
Only if the detaily there say it is on "Central", it is on Maven Central
And be sure you understand that using
mavenLocal
like that is an extremely bad idea
It is broken by design in Maven already, and it makes your builds slow and flaky at best
m
We're just using mavenLocal for testing published jars, which will later be put on the private repo. Thanks for the heads up though!
v
Better use some dedicated different local repository, or at least use a content filter 🙂
m
I've been a down a bit of a rabbit hole with this. I tried updating dependencies until something broke, which made me take a step back. Even if the dependency is old, it still does resolve on project A. Why wouldn't it resolve on project B??
Could it have something to do with repo B using newer versions of these libraries? I feel like the error message would be different then. Or is the 500 error the cause of all of this?
v
The 500 error means, that it was not found in the previous repositories and that this private repository is misbehaving. If it would have been found in a previous repository, that repository would not have been asked. But if it is asked and gives not an expected answer, it fails the build as the configured repository is broken.
m
As a test, I added my private repo to project A, which does build properly. After adding, I start getting the same 500 errors
c
Are you perhaps defining repos per-project, instead of globally in settings.gradle.kts?
As a test, I added my private repo to project A, which does build properly. After adding, I start getting the same 500 errors
Yes, as would be expected for a misbehaving repository.
v
Not if all repositories would have been resolved from previous ones
m
It's last in the order
Repos are defined globally
v
But maybe there is some dependency that is not found, but searched for in a lenient artifact view which makes it ok that it is not found, but 500 is not not-found but error
Or something like that
You probably need to debug to find out
c
we did establish before that the artifact in question isn’t in maven central - unless there’s other repositories defined it’s not found elsewhere, then hitting your private repository which should return 404 but returns a 500 error.
v
Or you just fix your misbehaving repository
👆 1
m
I'm not in charge of that repository but the fix is being worked on. Just looking for a relatively quick workaround, you know how deadlines are.
If it's not in maven central then how is it resolving the jar? I do see it in my external dependencies
In fact, I can copy the jar over manually and see if that works but that's a bit more hacky than I'd like
c
You’ll need to track down where its coming from. Or, don’t use a circa-2009 dependency with questionable lineage.
m
Agreed. I know where it's coming from, I can update it. This starts a chain of updating dependencies until I have to start editing source code, which is when I took a step back.
I know there are best practice solutions out there, and I would love to do them in the coming weeks. For now, I'm trying to figure out why my private repo is even being searched.
v
Which repos do you have declared in A?
Which version is trying to be resolved?
How do you declare that dependency?
m
I found a subproject that had a declared repo: https://plugins.gradle.org/m2/org/
Which has all of the old apache artifacts