Maven Download Snapshot Dependencies
Quinten Moye
I am trying to use external library inside my maven project. Since I want the project to build out of the box on any machine, I don't want to use mvn install solution. I have therefore defined local repository in my pom.xml:
The problem is when I replace the jar in libRepo (without updating version number since it is just another snapshot) that this updated jar is not used (old version from .m2 directory is used instead) even for mvn -U clean installHow to make maven to update this jar?
EDIT:According to What exactly is a Maven Snapshot and why do we need it? maven shall try to find newer version of SNAPSHOT dependency, "even if a version of this library is found on the local repository". What is wrong with my setting?
[EDIT] I understand that Maven handles dependencies with scope system differently. I'm not sure whether this makes sense or not (if it uses the dependency to compile, it surely can use it to run?)
Set up a local repo server for your company and deploy the dependency to it. That will take a few hours but a) you will get a local cache of all your dependencies, making your initial builds faster and b) it will make setup for additional developers much faster.
Maven will never read the jar present inside any library folder. You must first understand how maven works. The only place where maven looks for jar is the localRepository (.m2), if absent it searches the other repository, mentioned in your POM.xml
I tried to use both maven deploy and nexus-staging-maven-plugin. The result is the same. I can see the artefacts in Nexus but cannot reference them with their version. One note is that when I try the following I got a response like
The first time you execute this (or any other) command, Maven will need to download all the plugins and related dependencies it needs to fulfill the command. From a clean installation of Maven, this can take quite a while (in the output above, it took almost 4 minutes). If you execute the command again, Maven will now have what it needs, so it won't need to download anything new and will be able to execute the command much more quickly.
You've probably already noticed a dependencies element in the POM we've been using as an example. You have, in fact, been using an external dependency all this time, but here we'll talk about how this works in a bit more detail. For a more thorough introduction, please refer to our Introduction to Dependency Mechanism.
The dependencies section of the pom.xml lists all of the external dependencies that our project needs in order to build (whether it needs that dependency at compile time, test time, run time, or whatever). Right now, our project is depending on JUnit only (I took out all of the resource filtering stuff for clarity):
With this information about a dependency, Maven will be able to reference the dependency when it builds the project. Where does Maven reference the dependency from? Maven looks in your local repository ($user.home/.m2/repository is the default location) to find all dependencies. In a previous section, we installed the artifact from our project (my-app-1.0-SNAPSHOT.jar) into the local repository. Once it's installed there, another project can reference that jar as a dependency simply by adding the dependency information to its pom.xml:
What about dependencies built somewhere else? How do they get into my local repository? Whenever a project references a dependency that isn't available in the local repository, Maven will download the dependency from a remote repository into the local repository. You probably noticed Maven downloading a lot of things when you built your very first project (these downloads were dependencies for the various plugins used to build the project). By default, the remote repository Maven uses can be found (and browsed) at You can also set up your own remote repository (maybe a central repository for your company) to use instead of or in addition to the default remote repository. For more information on repositories you can refer to the Introduction to Repositories.
Let's add another dependency to our project. Let's say we've added some logging to the code and need to add log4j as a dependency. First, we need to know what the groupId, artifactId, and version are for log4j. The appropriate directory on Maven Central is called /maven2/log4j/log4j. In that directory is a file called maven-metadata.xml. Here's what the maven-metadata.xml for log4j looks like:
From this file, we can see that the groupId we want is "log4j" and the artifactId is "log4j". We see lots of different version values to choose from; for now, we'll just use the latest version, 1.2.12 (some maven-metadata.xml files may also specify which version is the current release version: see repository metadata reference). Alongside the maven-metadata.xml file, we can see a directory corresponding to each version of the log4j library. Inside each of these, we'll find the actual jar file (e.g. log4j-1.2.12.jar) as well as a pom file (this is the pom.xml for the dependency, indicating any further dependencies it might have and other information) and another maven-metadata.xml file. There's also an md5 file corresponding to each of these, which contains an MD5 hash for these files. You can use this to authenticate the library or to figure out which version of a particular library you may be using already.
To troubleshoot this issue, I do NOT have mavenLocal() as a repository, have projectB-SNAPSHOT as a changing module, and my configuration resolution strategy does not have caching turned on for changing modules.
Can you please provide your repository configuration or a reproducible example project? As mentioned in the other thread, Gradle will take the snapshot from the first repository where it finds it. It will not check other repositories.
The following log output is what I would expect to see:
[DEBUG] [org.gradle.api.internal.artifacts.ivyservice.ivyresolve.RepositoryChainComponentMetaDataResolver] Attempting to resolve component for foo.bar:foo-bar:0.0.3-SNAPSHOT using repositories [maven]
Reproducible builds. This rule means no SNAPSHOT dependencies, no SNAPSHOT parents, and no SNAPSHOT plugin versions. A snapshot version is not immutable, which means that code which depends on a snapshot may build today, but not build tomorrow, if the snapshot is later changed. The best way to avoid this conundrum is to never depend on SNAPSHOT versions. Snapshot are best used for testing only; they can be used transiently, but their use should never make it onto the main integration branch (i.e., master) of a project. See also Using snapshot couplings during development.
Luckily, the Maven Release plugin can help you automate the whole process of upgrading your POM version number and tagging a release version in your version control system, and all of this with a single maven command. You can even automate the entire release process by running the command in a cronjob or a Continuous Integration system. Amazing!
The SNAPSHOT suffix means that each time I deploy this version, a new snapshot will be deployed into my local Maven repository. Anyone who wants to use the latest, bleeding-edge SNAPSHOT version can add a SNAPSHOT dependency in their project. Snapshots, by definition, tend to be fairly unstable beasts.
First of all, you need to be working with a SNAPSHOT release. However, when you are ready to release your new version, you should remove any references to snapshots in your dependencies. This is because a release needs to be stable, and a build using snapshots is, by definition, not always reproducible. Maven will not accept any snapshot references and force the user to change it during the release process. If you answer is no (as below) to the question of resolving dependencies or not, Maven will fail your build.
So I took nifi 1.4.0 archetype to generate project. I created some custom procesor on my own, which does not have any extra dependencies, and validated, that it works in nifi. All good. Now lets move on to nifi code.
I took ValidateRecord file, and copy-pasted it into our project. I copy pasted also all dependencies from pom.xml module ValidateRecord is in. Our maven project and ValidateRecord maven project has now same parent, same dependencies. Both builds just fine.
When I tried to deploy it, it fails, because of missing dependencies, for example on nifi-record. I build our project using mvn clean install in root project. Built nar file does NOT contain respective jar (nifi-record). When I build nifi, also nifi-standard-processors does not contain this jar. I'd consider it normal, since maven parent prescribes provided. We have this dependency in pom.xml:
Similar to our APT Repository Internals and YUM Repository Internals posts, this post aims to illustrate the inner workings of a Maven repository. Read on if you have ever been curious as to how mvn compile figures out which dependencies to download and how to retrieve them in order to build your project.
Unlike other repository formats (APT, YUM Rubygems, there is no main index file that enumerates all possible artifacts available for that repository. Maven uses the coordinates values for a given dependency to construct a URL according to the maven repository layout.
One of the core features of Maven is its ability to handle Transitive Dependencies. That is, to find and download the dependencies of your dependencies, and their dependencies also, recursively, until they are all satisfied.
Just how your own Maven project has a pom.xml file listing its main dependencies, those dependencies also have a remote pom file serving a similar purpose. Maven uses this file to figure out what other dependencies to download. When a coordinate does not contain a classifier, it is considered a primary artifact and is expected to have a pom available.
A Maven repository is wherever these constructed artifact URLs live. Most of the time, this is a Web server with a /maven2 document root, but it can actually be any protocol Maven has a transport plugin for.
df19127ead