We are evaluating Artifactory to be used as our local/remote repository. Our application uses a custom cxf-2.6.6 jar. We've manually deployed the cxf jar into libs-release-local. But each time we do a local build, Artifactory downloads a version of cxf 2.6.6 from the remote maven repository into ext-release-local. As a result there will be two copies of cxf 2.6.6.jar and unfortunately our local build uses only the downloaded cxf instead of the one we deployed.
Both libs-release-local & ext-release-local are mapped to the same virtual repository libs-release, so this is strange. Even if I delete the cxf from ext-release-local it downloads again. How do I restrict this? I could probably deploy the cxf into ext-release-local (I haven't tried)?
But then isn't it a bug? Please advice.
You can control the resolution order of a virtual repository: Admin -> Repositories -> Edit (Virtual repository) -> Drag & drop repository names in the "Selected Repositories" box.
The "Resolved Repositories" box will reflect the order in which the resolution is performed.
Generaly speaking the search/resolution order when requesting artifacts from a virtual repository is always: local repositories, remote repository caches and finally remote repositories themselves.
If you are using Artifactory 2.6.0 or newer, you can use the Trace Artifact Retrieval feature to emulate an artifact retrieval request from the specified location and returns verbose output about the resolution process.
Related
I have an installed dependency in my local repository. The remote repository where the dependency came from is now down for some reason. When I try to compile the project Maven says that it can't resolve dependency. But why???
When you have these error, simply clean the _remote.repositories that indicate maven where the dependency comes from. You will find this file for each artifact inside your M2_REPO.
Maven will compare the local POM's timestamp (stored in a repository's maven-metadata file) to the remote. When maven does this depends on the updatePolicy that can be defined in your settings xml.
Either set this to never (discouraged) or skip this check (only when a remote repository appears to be down) by using the -o option (offline); then maven will not check remote repositories.
I keep getting this error when I call 'tomcat:run'.
The plugin 'org.apache.maven.plugins:maven-tomcat-plugin' does not exist or no valid version could be found
My company hosts mvn repositories locally via 'activeprofile'. Is this preventing mvn from acquiring the plugin from the WWW location? If so, how can I activate that too...
Cleared up after I deleted the repository in ~\.m2 (%userprofile%\.m2). Maybe poor interaction b/t various maven/tomcat eclipse plugin
The company repos (assuming they are using a repo manager) controlles what is in it ...so this has to be changed.
My company hosts mvn repositories locally via 'activeprofile'. Is this preventing mvn from acquiring the plugin from the WWW location?
It's impossible to answer this question, it all depends of the configuration of your maven client and/or the corporate repository.
If so, how can I activate that too...
Assuming your company does not allow accessing the central repository, bypassing this policy is not a good idea. You should discuss your requirement with the people administering the repository.
I am running into a maven problem that's killing all my hairs.
So at the beginning all my maven project works fine. And then when I switched to a new computer today and trying to compile them all.
The first error I see from Eclipse is IO error reading jar files from the local maven repository. Then I googled and someone suggested this is some corrupted files, simply delete them and let maven rebuild the repository.
That solves the problem for a while. And then it keeps popping up again and again.
I got tired and removed the whole local repository and did everything all over again. Then I found out the cause:
The maven remote repository is BAD.
So here is part of the console messages.
[INFO] Unable to find resource 'org.apache.ws.commons.axiom:axiom-dom:jar:1.2.8'
in repository eclipse-repo (http://repo1.maven.org/eclipse)
Downloading: https://maven-repository.dev.java.net/nonav/repository//org.apache.
ws.commons.axiom/jars/axiom-dom-1.2.8.jar
373b downloaded (axiom-dom-1.2.8.jar)
[WARNING] *** CHECKSUM FAILED - Checksum failed on download: local = '2c6102c2c3
70e0b993e897e981618ed448651147'; remote = '
The file contains an http redirect.
301 Moved Permanently
Moved Permanently
The document has moved here.
Apache Server at maven-repository.dev.java.net Port 443
I am stuck. How can I get the real dependency jars? How can I tell maven to avoid this? This is really annoying.
There is king of bug in maven, simply because maven does not skip taking an artifact if one
of the maven repo sends a 301(MOVED PERMANANTLY) and it simply take that message and write it as the pom file. Simply if the maven repo sends 404 it skip that repo and go for another, but here with 301 it just dump the message as the pom file and later on this failes.
I assuming you're using Maven 2.2.1? If yes try, to downgrade to Maven 2.2.0 or use additional setting. In 2.2.1 was change in wagon implementation.
Maven 2.2.1 aims to correct several critical regressions related to the selection of the HttpClient-based Wagon implementation for HTTP/HTTPS transfers in Maven 2.2.0. The new release reverts this selection, reinstating the Sun-based - or lightweight - Wagon implementation as the default for this sort of traffic.
However, Maven 2.2.1 goes a step further to provide a means of selecting which provider - or implementation - the user wishes to use for a particular transfer protocol.
So, try run maven with additional params.
mvn -Dmaven.wagon.provider.http=httpclient clean install
One answer: avoid dev.java.net. It's often broken in one way or the other. If you need things from there, install them in a local repository manager.
I've seen this error with IntelliJ IDEA 13.1.5 and Ubuntu 14.04.
Maven 2.2.? saves the 301 response body as a jar file in the ~/.m2 cache, which causes problems later on during the build.
The fix for me was to install Maven 3. Instructions for Ubuntu 14.04 are here:
http://www.sysads.co.uk/2014/05/install-apache-maven-3-2-1-ubuntu-14-04/
I'm converting an Ant build system to use a local Nexus mirror (1.3.6), and can't seem to get Nexus to proxy Jarvana repository. One of our dependencies is jython 2.5, which is available only on Jarvana.
I had no problem configuring other repository proxies, such as java.net at http://download.java.net/maven/2/
For Jarvana I've tried
www.jarvana.com/
www.jarvana.com/jarvana/
www.jarvana.com/maven2/
www.jarvana.com/maven/2/
www.jarvana.com/browse/
In all cases, the browse pane shows .index and .meta folders, and the .index is populated with nexus-maven-repository-index-* files, but searching for jython returns only the earlier (2.2 and prior) versions from Maven Central.
Am I using the wrong URL, and if so what URL should I be using?
Jarvana offers maven repository search capabilities and maven repository browse capabilities, but it does not offer a direct URL for its repository files. This is because all Jarvana files come from the maven central repository, so every file in Jarvana should be available in the maven central repository.
As an example, Jython 2.5 is available in the central repository at:
repo1.maven.org/maven2/org/python/jython/2.5.0/
Update: I did a bit more digging and it looks like the repository URL for Jarvana is http://www.jarvana.com/jarvana/browse. I've just added Jarvana as a proxy repository with that URL and successfully downloaded Jython 2.5.
I tried to configure the Maven plug in (version 4) to add the JBoss Maven repository at http://repository.jboss.com/maven2/ following the guide at http://wiki.netbeans.org/MavenBestPractices#section-MavenBestPractices-UtilizingAndManagingMavenRepositories.
The new repository appears in the list of Maven repositories, but I can not see any items (artifacts), updating the index does not help.
It looks like a problem with the Maven plug in. Maybe it requires an ".index" subdirectory which is not available on the JBoss server.
The JBoss repository has a Nexus index at http://repository.jboss.com/maven2/.index/. I think the problem is that Netbeans might not be making use of this index. I would recommend installing Nexus, adding the JBoss repo to a public group and then pointing your Netbeans instance at a local instance of Nexus.
Download Nexus from http://nexus.sonatype.org
Install it by unpacking the tar.gz or zip on your machine
Fire it up by running bin/jsw//nexus start
Go to http://localhost:8081/nexus
Log in as the default admin user: admin/admin123 is the username/password
Click on Repositories
Click the Add... button
Add a new repository for the JBoss repositorywith a remote location of: http://repository.jboss.com/maven2/
Save the new repository. (You will also want to make sure that Download remote index is selected)
Add the repository to your public group by clicking on the public group and dragging the new JBoss repository to the selected repositories.
Configure your ~/.m2/settings.xml file to have the same contents as: http://www.sonatype.com/books/nexus-book/reference/maven-sect-single-group.html
At that point, all of your repository requests are going to flow through Nexus. Nexus already ships with proxy repositories for Central. So all you did was to add in the JBoss repository and then add it to the public group. Once you do this, you'll find that your builds are going to be much, much faster.