In Our Project Nexus is used as Jar repository and we are having the below entry in the settings.xml .
<mirror>
<!--This sends everything else to /public -->
<id>nexus</id>
<mirrorOf>*</mirrorOf>
<url>http://*.*.*.*:7003/nexus/content/groups/public</url>
</mirror>
When ever a new jar is loaded in nexus it is uploaded in the path as per the entries present in the pom.xml .
<dependency>
<groupId>com.pqr.xyz.abc</groupId>
<artifactId>xyz</artifactId>
<version>2.2.0.0.4.1</version> OR <version>LATEST<version>
</dependency>
So, if the jar is uploaded in nexus every time with a new version then the it is getting picked when we are doing the maven update for our project which is having the entry of the version as mentioned above (either the specific version or LATEST.
But if we update the same version folder in nexus with the updated jar then maven update is not picking the latest jar, it keeps the old jar in the .m2 repository even if we do force update then also.
So we think that if the jar is replaced in the same folder in nexus then it will not be updated if the folder already exists in .m2 repository?
Is there any way to take the latest jar every time even if the same folder is updating in nexus via maven update?
You have a misunderstanding of maven concepts regarding versioning of artefacts. There is a big difference between SNAPSHOT and release versions and I suggest to read these documentations: Release and Snapshot and Repositories settings
Back to your issue, the solution is to remove from your local maven repository the artefact that was updated on nexus. You have 2 options:
List item manual delete the folder ${user.home}/.m2/repository/com/pqr/xyz/abc/xyz/2.2.0.0.4.1/ (this assume your local repository in under your home directory)
Use dependency plugin - purge local repository to remove local artefacts. You can find an example here
In your expose you didn't mention why you have to update a release jar in nexus. Conceptually, this smells. I advise to reconsider your release procedure and to avoid updates on releses versions. It's better to create a patch/minor version instead of updating a release. Put in place of a client, when a client should check if a release was updated and based on what? A downloaded file timestamp is not reliable.
Related
This question is a little different than the other "checking for latest dependency version" type questions.
Let's say we have a project, DepProjA, that builds and publishes an artifact for our other Java apps to import as a dependency. For example, AppProj1 lists DepProjA as a dependency in its pom.xml file.
<dependency>
<groupId>com.mycompany.depproj</groupId>
<artifactId>depproja-lib</artifactId>
<version>feature-addthisfeature</version>
</dependency>
As you may notice, DepProjA, publishes "feature" versions of this JAR with the version named after the working branch name. This is so that other teams can test these particular feature updates before they are published as an official version update. If a bug is found and the fix is pushed under the same branch, the "feature" artifact is updated. However,when we rebuild AppProj1 to try and pull and utilize that latest artifact, it seems to be using the previous local version instead.
Is there an option, either in the pom.xml, or the mvn CLI options, so that maven will always pull down the latest artifact instead of using whatever version is cached? I know I can do a "blanket approach" like purging cache and such, but looking for something that targets specific dependencies. Kind of similar with Docker images where the tag itself won't change, but the underlying SHA can be updated when a new version of that tag is published.
An alternate idea I don't even know is possible: When publishing an artifact, is there a way to add custom metadata or labels that I could then reference? For example, I add a "cicdlabel" that could reference the pipeline ID that published the latest version. Then, I could change that in the application's dependency info when I know there is a change:
<dependency>
<groupId>com.mycompany.myproject</groupId>
<artifactId>myproject-lib</artifactId>
<version>feature-addthisfeature</version>
<cicdlabel>12345</cicdlabel>
</dependency>
In Maven by design released artifacts are immutable.
You can not update the same release version of artifact in Maven central.
It ensure that your build is reproducible, when we change content of released artifact the same build can break in the future.
In your case you should use SNAPSHOT versions for your artifact, and SNAPSHOT version can be updated.
You can use updatePolicy for your repository configuration in your settings.xml.
Yo can use mvn -U .. for update SNAPSHOT versions on every build.
I have the following maven dependency in my web application POM, which in turn should pull other dependencies:
<dependency>
<groupId>com.my.libraries</groupId>
<artifactId>my-libs</artifactId>
<type>pom</type>
<version>1.6-SNAPSHOT</version>
</dependency>
NOTE I had release 1.5 for my-libs artifact previously pulled during an older build. But I have later upgraded the version to 1.6-SNAPSHOT. mathlibrary artifact wasn't present in 1.5 release.
I am expecting some jars to be present as part of my-libs artifact verson 1.6-SNAPSHOT which wasn't present in 1.5 - the pOM is below:
<!-- all the usual POM descriptionsm for my-libs -->
<groupId>com.my.libraries</groupId>
<artifactId>my-libs</artifactId>
<version>1.6-SNAPSHOT</version>
<packaging>pom</packaging>
<!-- continues... all normal stuff, nothing to see here :'/ -->
<dependency>
<groupId>com.my</groupId>
<artifactId>mathlibrary</artifactId>
<version>1.0</version>
</dependency>
<!-- continues -->
I expected that mathlibrary jar would be pulled if I do mvn package for my project. But when I looked at the lib folder for my webapplication the jar wasn't there. I then checked my .m2 directory contents and it seems that only version 1.5 is present, so 1.6-snapshot wasn't automatically installed. From here, I am thinking that if a release version is pulled before, it doesn't pull the next SNAPSHOT?
After I manually installed my-libs artifact using mvn clean install - on the next build for my web application it pulled the jars correctly. Does this mean that my package phase is defined not to automatically pull the SNAPSHOT dependencies? or is this something expected (i.e. I have to manually run install phase it if it's not a release version) ?
Use mvn package pulls all SNAPSHOT dependencies from your local repository (and also updates your local repository from a remote repository every 24 hours, if the artifact comes a remote one).
I do not really understand what you mean by "manually installed my-libs" because there is no automatic way to install artifacts (except for CI servers, that install/deploy on checkin). If you want to use an artifact (like my-libs), you need to build it and put it in the local repository -- and you do this by using mvn install.
Answer to your question depends on which packaging you are using in your pom.xml and on which plugins have executions tailored to the packge phase. When dependencies are processed, Maven usually resolves them, which means that corresponding jar files will be in your local repository.
Getting jar files in your target folder (as is, or unpacked) is a result of some plugin's work (such plugin would execute a mojo at prepare-package or package phase (usually). So, make sure you use proper packaging (such as war) or e.g. "assembly" plugin (which can repack dependencies for you).
To make your dependency artefacts available for resolution and further use, you should either deploy them to a remote repository, or install them to local repository.
After reading #JFMeier answer on this, I did the following:
1) Removed all release/snapshots from my .m2 directory.
2) Changed my web app POM to use 1.5 release for my-libs
3) Kicked off the build.
4) Once the build finishes, I confirm that mylibraries jar hasn't been deployed in my final web application directory in tomcat's WEB-INF\lib
5) Repeated steps 2-4 - BUT changed the version to 1.6-SNAPSHOT for my-libs.
6) Now I can see the expected result.
Maven is only getting into repository (either global or local) when you make a mvn install. With Maven Install, Maven checks if all the POM libraries are present in your project and downloads from repositories into your project if some are missing. If you do a Maven package, it only packages the libraries present in your project.
For some reason, the jar GAV in local pom.xml can't be changed,like a snapshot, its version is always 1.0-SNAPSHOT.
But in the remote repo, it may be covered by other mates.
For the index is not changed, the MyEclipse can't update to the latest jar,and comes somes problems.
I konw that it can update to the latest jar in IDEA,how should I do in MyEclipse?
If you are using the m2e-Plugin you can update the maven dependencies of the project via Alt-F5 and then set the check mark on 'Force Update of Snapshots/Releases'
How do I prevent Maven 2 from searching remote repositories for specific dependencies that are in the local repository only?
How do I prevent Maven 2 from searching remote repositories for specific depedencies that are in the local repository only
Well, actually, Maven won't unless:
they are SNAPSHOT dependencies in which case this is the expected behavior.
they are missing a .pom file in which case you can provide it or generate it (see questions below).
Related questions
How do I stop Maven 2.x from trying to retrieve non-existent pom.xml files for dependencies every build?
Maven install-file won’t generate pom.xml
set up nexus as a repository manager.
add addtional remote proxied repositories if necessary
add your local hosted repository (hosted on the nexus server)
define a group of repositories in the correct search sequence with your local repo's first.
change your builds to point at the nexus group url (use mirrorOf=* in your settings.xml)
run your build and let nexus manage the local vs remote dependency resolution
Use fixed version numbers in your POM for your remote dependencies or the local versions you want to fetch from the local repository.
Maven tries to be friendly and fetch the latest and greatest of whatever which has no version number specified.
For a quick fix to not be waiting for the internet to be downloaded each time you build you can use mvn -o to force an offline build, and then it will not lose time trying to fetch new versions.
The answer of #crowne is also very good advice, especially setting up your own nexus and making sure all remote repos are configured there so you will never have unpleasant surprises when a repo dissappears some day.
To prevent Maven from checking remote repositories at all, you can use the -o flag. Otherwise, Maven will check that any snapshot dependencies are up-to-date. You can use a dependency manager such as Nexus to get fine-grained control over dependency resolution. The repository section in your pom.xml or settings.xml file also has an updatePolicy element that allows you to configure how often Maven will check for updated dependencies.
What I want to do is to force Maven to download the 'maven-metadata.xml' for each artifact that I have in my local repository.
The default Maven behaviour is to download only metadata from remote repositories (see this question).
Why I want to do that:
Currently I have a remote repository running in a build machine. By remote repository I mean a directory located in the build machine that contains all dependencies that I need to build my Maven projects. Note that I'm not using a repository manager like Nexus, the repository is just a copy of a local repository that I have uploaded to my build machine.
However, since my local repository did not contain the 'maven-metadata.xml' files, these metadata files are also missing in the build machine repository. If I could retrieve the metadata files from the central repository, then it would be possible to upload a working remote repository to my build machine.
You don't want to get the metadata from the public repositories, it will contain all the versions available of a given artifact, whereas your repository will have some subset of the releases.
It's worth pointing out that you really would be better off with a repository manager. The following steps allow you to generate your artifact metadata once. But if your needs change, you'll have to repeat the process or update the files manually, so why not just use a manager? Nexus can run standalone and has a very small footprint.
Even if you're not planning on using Nexus for a repository manager, you can still use it to generate your metadata.
First install Nexus.
Locate the nexus work directory (by default ${user.home}/sonatype-work.
Copy your local repository contents to the nexus-work/releases sub-directory.
Start Nexus and connect to the Nexus home page in the browser (by default http://localhost:8081/nexus)
Log in using the admin account (password admin123)
Click on the repositories link on the left hand side.
Select the Releases repository, right-click and click Rebuild Metadata
In a few moments you should have the metadata generated for all the artifacts. You can then copy them to wherever you need them to be and uninstall Nexus.
The default repositories are defined in the super pom.xml that all poms inherit from by default.
If by local you mean you want to only use ~/.m2/repos/* then work in offline mode. Add <offline>true</offline> to your settings.xml
If by local you mean your local server, you could install a repository manager like Nexus, modify your settings file to use nexus under "mirrors" like this:
<mirror>
<id>central-proxy</id>
<mirrorOf>central</mirrorOf>
<url>my/local/nexus/server</url>
</mirror>
And disable remote repositories you don't want in Nexus.
One thing I found is someone was doing an initial search of jarvana and had placed this within the pom, causing a metadata error message to occur. This ...
<!-- <repository>
<id>jarvana</id>
<url>http://www.jarvana.com/jarvana/browse/</url>
</repository> -->
..fixed it and the error went away.
Repository manager is great but I don't want install and run it on my laptop. I just want to save resource.
So, my solution is below:
install repository as artifactory (https://www.jfrog.com/artifactory)
run materialize thru this server (localhost:8081)
run materialize thru remote server (center.maven.org)
download cache content of artifactory
merger to folder: folder download from step 4 and folder at ~/.m2/repository.
Now I have a repository offline with full content (binary, source, xml, md5, sha1)