Has Maven some security parameter to limit the number or depth of dependencies downloaded to the local repository when building a pom?
Imagine an artifacts repository hacked in a way that, for every artifact dummy-1.0 requested, it serves dinamically a dummy-1.0 which has a dependency on dummy-1.1, and so on.
Has Maven some security mechanism to avoid such an infinite loop?
(I haven't found it explicitly on Maven's documentation nor googling it).
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
My team is migrating our code to an Azure environment and Microsoft's own article on the subject describes how to use Maven in an Azure environment:
https://learn.microsoft.com/en-us/azure/devops/java/labs/mavenpmvsts/?view=vsts
One of Maven's best practices is to avoid defining repository elements within the pom file and use a repository manager configured within the settings.xml instead.
The Microsoft article instructs otherwise: they say to add the repository url right in the pom file.
I would have been okay with it if the repository element was defined only in the distributionManagement section, but that is not the case. The article defines the url in a repositories element outside of the distribution context.
My understanding of the repository element of the pom.xml file is that it overrides the source of artifacts used for fetching dependencies. The problem I see defining this in the pom file is that it could have adverse effects depending how the library is being reused.
Use case example:
1) Shared library is created with repository url defined in pom
2) Shared library is deployed. POM file containing url and JAR file are published.
3) Artifact repository is moved, renamed or copied, url is changed.
4) Later on, a new application using that shared library is created, but uses the new repository url. The URL in the application pom is now different from the one in the shared library's previously published pom.
Because Maven uses a dependency graph and inheritance, what I would expect to happen is that when we build the new application:
1) maven will read the application pom file and begin exploring the dependency graph by downloading pom files for each of the application's dependencies from the URL found in the application's pom. In this case, the only download is the shared library's pom.
2) maven will explore transitive dependencies and read the shared library's pom. Reading the shared library's pom, the repository section will take precedence over the application's pom in the context of the shared library's dependencies. The shared library's dependencies poms would be downloaded from the old URL.
3) maven will continue like that and download all the pom files until the dependency tree has been built.
4) depending on project configuration, maven will go through the graph it built to download the jars and etc using the same rules.
In this use case, maven would download artifacts from both the old source and the new source. If the old source no longer exists or isn't accessible in this build context, the project cannot be built. This is why it's best to avoid setting repository urls in a pom file.
Or so I thought.
I wrote a scripted demo with local repositories to show my team exactly what would happen and to my surprise, even though Maven does download the shared library's pom file containing a different repository url, the repository tag does not seem to be overriding the one from the application being built. Logs show all artifacts being downloaded from the source specified in the "top" application pom.
So my question to Stack Overflow is two fold:
1) Why am I wrong? Did I misunderstand Maven's inheritance, dependency graph building and behavior?
2) Shouldn't Maven download the shared library's dependencies from the url specified in the repository tag, if specified? I'm sure there are some cases where the artifacts must come from a private repo. (ex: org.geotools)
3) Does anyone have experience setting up Maven on Azure? Did you follow Microsoft's guide or found a way to move repository urls to your settings.xml in an Azure environment?
In order to include a specific maven dependency, I included its repository in my pom. Because of this, maven will check every repository for every artifact. This repository is rather slow so I would rather have maven only reach out to it when checking for the dependencies that it provides.
Is there a way to limit maven to check a repository for certain artifacts? Perhaps certain group IDs?
I doubt that you can impose such filters, but Maven asks the repositories in a certain order until it finds the artifact. As we handle this problem through Nexus, I am not experienced in this, but the question How to set order of repositories in Maven settings.xml gives (maybe outdated) information about this.
We are currently migrating from Nexus to Artifactory and one thing we are missing is an API call to resolve maven dependencies in artifactory. Nexus has this endpoint /service/local/dependency?r=snapshots,releases&c=&e=pom&s=compile&f=list&g=<my.group>&a=<my-artifact>&v=<my-version> which gives a compiled list of all, including transitive, depdendencies.
We need this because we (mis)use maven as a generic deployment/versioning system to create artifacts (zip files of shell scripts actually) and to manage depenedencies. These dependencies are also necessary for production deployments.
Since we migrate from Nexus we don't have builds accessible and I am not yet sure if we want to use them. Is there a way to get a rest endpoint like the nexus one in Artifactory? Maybe a user plugin? Any hints on how this could be done?
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.