Our builds generate a lot of errors like:
Unable to determine if resource XXXX exists in http://download.java.net/maven/2
I know this repository is gone, but I cannot locate the reference to it. If I look at the effective POM using Eclipse, the only repositories other than our internal one are:
http://repo1.maven.org/maven2
http://public.dhe.ibm.com/ibmdl/export/pub/software/websphere/wasdev/maven/repository
and the pluginRepository is
https://repo.maven.apache.org/maven2
The errors does break anything, but it would be nice for them to go away. Any ideas on what might be referencing this java.net URL? Perhaps some Maven plugin?
Related
Is there a way in Gradle to explicitly define where certain artifacts should be coming from?
We have a legacy project which is being on-boarded to use a proper artifact repository manager, instead of a network share. However, we have multiple repositories from which artifacts are being downloaded. We'd like to be able to fine-grain where certain artifacts should be coming from, until we can fully on-board to the artifact repository manager in question.
Is something like this possible?
Yes that is possible as of Gradle 5.1
https://docs.gradle.org/5.1/release-notes.html#repository-to-dependency-matching
Repository to dependency matching
It is now possible to match repositories to dependencies, so that Gradle doesn't search for a dependency in a repository if it's never going to be found there.
See the docs for more details: https://docs.gradle.org/5.6.2/userguide/declaring_repositories.html#sec::matching_repositories_to_dependencies
So there is a dependency that my project needs, and it is in our internal artifactory, however, after adding the dependency, it started throwing the following error:
Failed to read artifact descriptor for
org.codehaus.fabric3.api:commonj:jar:1.1.0: Failure to find
org.codehaus.fabric3.api:parent-pom:pom:1.0 in
http://maven/artifactory/libs-snapshot was cached in the local
repository, resolution will not be reattempted until the update
interval of art_central has elapsed or updates are forced -> [Help 1]
I realized that the parent of that dependency ( org.codehaus.fabric3.api:parent-pom:pom:1.0) is not in our internal artifactory.
I know my question might not sound logical and it doesn't make much sense but; is there any way to exclude the parent or make this dependency not look for the parent? I already try with the tag.
Thanks in advance!
You can exclude a specific file from being searched on a remote repository by using the include/exclude parameters of the remote repository.
https://www.jfrog.com/confluence/display/RTF/Common+Settings#CommonSettings-IncludesandExcludesPattern
By adding this file, Artifactory will not search for it on the specific repository.
I lately had some issues with some Maven dependencies and came across the error: "Failed to read artifact descriptor ...".
My question is not really about the error but more about the artifact descriptor itself. I would like to know what the actual problem is or what's creating the problem and I did not really find an explanation for what artifact descriptors are, so I wondered if someone could help me.
In other words, it's the POM. The POM is the Maven specific file that describes an artifact.
Maven 3.3.9 uses Eclipse Aether behind the scenes (which has been incorporated into Maven 3.5.0 itself as part of the Maven Resolver API), and it provides the class ArtifactDescriptorReader, explaining:
Provides information about an artifact that is relevant to transitive dependency resolution. Each artifact is expected to have an accompanying artifact descriptor that among others lists the direct dependencies of the artifact.
The Javadoc of its sole readArtifactDescriptor method is:
Gets information about an artifact like its direct dependencies and potential relocations.
So when you have an error that goes like "Failed to read artifact descriptor...", it means that the POM could not be read, or could not be resolved. Typically, it follows from network issues where the downloaded POM was corrupted, where Internet access is proxied and Maven isn't rightly configured, etc.
First, I am not a maven user. I need this library: https://github.com/ansell/JenaSesame but only the source code is available. The readme shows this information:
Repository
http://openjena.org/repo-dev
Group: org.openjena
Artifact: jena-sesame
But when I browse to that location I get a 404. How can I grab that artifact from that repository? I'm willing to install maven if I have to to get it; I just need the compiled library jars.
I have already searched the maven central repository at http://search.maven.org , and it is not there.
Any publicly-accessible repository should be viewable in a browser, and as such you should be able to download any JAR file contained within. The URL you've listed, openjena.org/repo-dev [1], looks more like a development repository. There are plenty of repositories around the world that are internal repositories, so this looks like one that hasn't been set up for public consumption.
It looks like they have binary releases available for download here: http://www.apache.org/dist/jena/ Have you looked there for what you're after?
[1]: Now a spam domain - visit https://jena.apache.org/ instead.
According to the Maven documentation:
You can force Maven to use a single repository by having it mirror all repository requests. The repository must contain all of the desired artifacts, or be able to proxy the requests to other repositories. This setting is most useful when using an internal company repository with the Maven Repository Manager to proxy external requests.
To achieve this, set mirrorOf to *.
This StackOverflow question also suggests that setting mirrorOf is sufficient to block an external repository, so why does the Sonatype documentation suggest overloading central with an unreachable URL?
The bogus URL is really irrelevant - you can set it to the original one if you need to, or the URL of your repository manager - as long as the mirrorOf is applicable, it won't be used.
The reason these examples redefine central is to set policies on artifact requests to the default repositories. By default, Maven does not enable snapshot requests to central, and uses default update and checksum policies. Redeclaring central allows these to be overridden - in this case, to enable snapshot artifacts and plugins, and the mirror then redirects all of these to the repository manager. This avoids the need to declare the repositories in your POM (as long as all users have their settings correct).
I wrote that so I can tell you what I was thinking ;-)
The central repository definition needs to be updated to enable snapshot retrieval for at least one repo, otherwise Maven won't even ask the repository manager (pointed to by the mirrorOf) for any snapshots.
While not required, I like to change the definition of the url to be an invalid one also so if there is a misconfiguration somewhere else in the system, it becomes immediately obvious what is happening. Otherwise Maven may still reach out to Central and mask the problems. It's essentially a fail-fast setup.
There's more information on this topic in an old blog I wrote
maven needs project dependencies to be available locally for it to run. It does not care about how it is made available - whether manually installed (using mvn install:install-file), through a mirror or by from central repository. It will fail to run if it is unable to find dependencies.
The sonatype documentation that you are referring to is on using nexus to mirror/proxy repositories. The url specified should be a valid nexus url and cannot be unreachable.
The same is suggested in the SO question as well.