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
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?
In out project we are using using deployed war file in /archiva-2.2.0/repositories/internal/com/xyz/1-SNAPSHOT/proj-1-20160204.122021-15.war path using shell script to copy to jboss. However finding the latest build timestamp and build number is very difficult. Is there a way to avoid using timestamp while storing it in archiva like proj-1-SNAPSHOT.war?
I have already read about <uniqueVersion>false</uniqueVersion> whcih is not supported in maven 3.
I am using archiva-2.2.0, maven-3.3.9.
Maven repositories wasn't designed to distribute deployable components, your continuous integration environment should take care of this. Jenkins has eg Archive Artifacts (native) and Copy Artifact Plugin which you can use to store and recover binaries in your pipelines.
But you can workaround this behavior changing the version of the war to a stable one - removing the -SNAPSHOT suffix. This will lead you with a predictable URL.
I am posting this as it is a new finding, if I wget http://xx.xx.xx.xx:8083/repository/internal/com/xyz/1-SNAPSHOT/proj-1-SNAPSHOT.war. I get the latest deployed artifact in the archiva repository. So archiva does a 302 redirect to point to url of http://xx.xx.xx.xx:8083/repository/internal/com/xyz/1-SNAPSHOT/proj-1-20160204.122021-15.war location and downloads the latest build. I am not sure if this works for other repositories like nexus or artifactory etc.
Ofcourse I will need a cron job to periodically clear of the stale snapshot artifacts.
We have a situation where we need to customer the sonar zip created by the sonar-application maven project. In the past we have done this by referencing the zip thru a maven dependency. In this case many of the other sub-projects for sonar 3.5.1 have been deployed, to the CodeHaus Nexus repository, but not the sonar-application artifact. In fact, it hasn't been deployed since version 1.4.x. I was hoping someone can tell me why this is.
Indeed zip file is not uploaded as a maven artifact. It's available at http://dist.sonar.codehaus.org/
apparently my Nexus is rejecting every deploy I throw at him if the artifact has not -SNAPSHOT in the version.
Data:
name of the failing artifact: entando-core-engine-experiment-bundles_with_bootstrap.jar where experiment-bundles_with_bootstrap is the version as in the version element of the pom.xml
hosted repository policy on my Nexus: Snapshot, allow redeploy and so on (classic conf for snapshots)
deployer: Jenkins 1.481
same Jenkins job, but entando-core-engine-SNAPSHOT.jar ---> SUCCESS
I need this naming convention because I'm building one of the several experiments we run internally, as opposite to the canonical develop branch which produces a proper entando-core-engine-SNAPSHOT.jar
Any advice?
I'm totally lost.
The thing is that usually your Nexus is configured not to allow a redeployment of a release. A release from Maven point of view is an artifact where it's version it NOT -SNAPSHOT. In contradiction a SNAPSHOT is intended to be deployed several times into nexus.
This sounds like you don't using the release plugin of Maven nor the Release PLugin of Jenkins.
Nexus is a repository manager that uses different repository formats, with the main format being the Maven repository format. Changing the names of artifacts on the server is not possible since it violates the format. They have to be located in the directory structure established by groupId, artifactId and version and use the artifactId-version-classifier.packaging for the file names.
If you need a different file name on the server you have to look at a different repository format (bad idea). If you need the filename on the client just download from the correct name and rename..
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.