Maven stores locally in .m2 all downloaded builds for one SNAPSHOT version into the same directory by appending a timestamp and build number to an artifact name. So later I can take any build that is available from that directory.
Can I do the same with Gradle? Can I find a specific build artifact of a SNAPSHOT version?
Related
I have a problem with a Maven artifact from a predecessor.
He modified an external maven library and uploaded it under the same version name to the Nexus releases repo.
When I build my project I obviously get the official version and not the intended.
Locally I just overwrite my local .m2 repo with it.
But for our cicd server this is not an outcome, because I have no file system access, and because the situation might repeat itself.
There is no source code so rebuilding and reversioning would be cumbersome.
My question is: how can I force to get the artifact downloaded from the releases and not the default central repo, meanwhile getting all other dependencies come from the latter?
I want to use a project called projectA that I have in a maven repository as dependency of a projectB.
The mvn deploy of projectA is successful (I can see in the repository the projectA-0.0.1-20190902.072951-1.jar, projectA-0.0.1-20190902.072951-1.pom and maven-metadata.xml files), but when I specify the dependency in the pom.xml file of projectB, the project works but it downloads two JARs of projectA from the repository:
- projectA-0.0.1-20190902.072951-1.jar
- projectA-0.0.1-SNAPSHOT.jar and the same issue for every file downloaded by the dependency to this project.
I think that only one JAR is necessary, and I don't know what I need to put maybe in settings.xml or in the pom.xml file of any project to get only one JAR when the dependency is downloaded.
Thank you so much for your help!
In the past it was possible to tell Maven to deploy Non-unique Snapshot Deployments but in Maven 3
... snapshot artifacts will always be deployed using a timestamped version
So:
the files with the timestamps are the one you have deployed to your remote repo (mvn deploy ...) and then downloaded from there as dependencies
the ones with -SNAPSHOT are the result of the local builds (install goal)
If your concern is download traffic - that is not an issue. The -SNAPSHOT ones are not downloaded.
If your concern is disk space then you can have a cron job or use something like Build Helper Maven Plugin to remove old version artifacts from the local repository.
When I add a new Maven dependency that I've never used before, I will do Maven build and see the dependencies being downloaded into my local machine from Nexus. All is good.
I will then create another project, specify the same dependency with the same version, do a Maven build, and I will again see the dependencies being downloaded from Nexus into my local machine.
Why are my dependencies re-downloaded every time? Aren't these dependencies already installed in my local repository?
Maven will NOT download artifacts repeatedly. The only exceptions are if you are deleting your local repository (in ~/.m2/repository by default), you are configuring usage of a different local repository and if a new SNAPSHOT version is available.
I have trouble understanding, why maven has to check for updates each time we build a project.
The pom has specific version mentioned for each dependency. Once those versions are downloaded to the local repo, then maven can use that local copy to build the project. So why does maven have to check for updates when we build the project each time other than just using the local copy?
a side question.
can a maven artifact be changed after releasing it to a repo under a specific version?
As per Maven, an artifact mainly can be of two types - a RELEASE one and a SNAPSHOT one. RELEASE dependency(eg: 1.0.1, 2.3.0 etc) of an artifact is a source of truth. Means 1.0.1 version of a jar (say test.jar) will always be the same always. We will release artifacts to remote repository, whenever the product matures or after a sequence of bug fixes.
On the other hand, a development is on going in a project, then specified its version number as SNAPSHOT(eg: 2.0-SNAPSHOT, 1.1-SNAPSHOT etc).
Say if we specified test-2.0-SNAPSHOT.jar as dependency in our project pom. If we look at the remote repository (Nexus, archiva etc), we can see that it is not saved as version 2.0-SNAPSHOT rather it will be saved artifact version as date-timestamp-buildnumber format, the date-timestamp at which the artifact was built and uploaded to remote repo. (eg: test-2.0-20150105082634.jar)
So when ever the development team does the fix for an issue on a daily basis the updated jar with date timestamp will be in uploaded to the remote repo. So it is necessary for maven to do look up for the latest date timestamp of SNAPSHOT artifacts. Maven does this by maven-metadata.xml file in the artifact directory in the repo.
Hope this clarifies your query. Let me know, if you need any clarifications
We use mvn deploy:deploy to deploy an artifact to repository manager and a developer could have done just mvn install for the same artifact, so the artifact is present under M2_HOME\.m2\repository
Will the maven runtime retrieve the artifact from the repository manager if it was updated recently than the local repository copy?
Note: We use a maven repository manager based on Apache Archiva.
The answer depends on whether you're talking about a snapshot or a release build.
Release builds have a version that doesn't end with "-SNAPSHOT", and they're final and immutable. Once installed to any repository, Maven will never update them. To your question, that means that if a dev installs a release build locally, it will never be updated from any remote repository.
Snapshot builds are always eligible to be updated from any repository. By default, Maven checks once per day for new snapshot versions, so if someone installs a snapshot locally, that snapshot will exist until Maven does its next check for snapshot updates. Then, if a newer version is in any remote repository it checks, the local one will be overwritten. You can force maven to update snapshot artifacts with the -U command line option.