I added two SpringSource repositories to my Nexus instance
http://repository.springsource.com/maven/bundles/release
http://repository.springsource.com/maven/bundles/external
Configuration looks fine but I noticed that the index is always empty. So it is not possible to resolved depedencies for artifacts in this repository.
I can use Browse Remote to navigate to the artifact. So the artifact I need is in the repository but without an index, this is of no use it seems.
Also when I use search in Nexus I cannot find the artifact.
Why is there no index for these repositories?
How should these repositories be used?
These repositories do not publish search indexes, you can test for this by trying to retrieve "/.index/nexus-maven-repository-index.properties" through them:
http://repository.springsource.com/maven/bundles/release/.index/nexus-maven-repository-index.properties
Search indexes are an optional repository feature, they are not needed for artifact retrieval, they are used to support interactive search in UI's such as Nexus and m2Eclipse. Nexus will be able to pull artifacts from these repositories without issue, and as artifacts are downloaded they will be added to the local search indexes.
Related
I wonder if it's possible to define a Group Repository in Maven Nexus and tell it to get the artifacts from existing repositories, but only those with ID matching a certain prefix xxx.yyy
This way, not all the artifacts of a repository will be available at this group repository, but only those I want to publish.
If you are using Nexus 2.x professional, you can use procurement to define a restricted view on a repository, allowing only artifacts that fulfil certain rules. Your intended rule should be among the possible ones.
Say I have a "public" group in Nexus which contains two repositories "snapshotsA" and "snapshotsB". Both contain versions with the same Maven coordinates, like com.something:artifact:1.0.0-SNAPSHOT. How does Nexus resolve a SNAPSHOT reference? Does it look into both repositories to find the latest element? Or is it satisfied after finding the first one?
For groups in Nexus Repository 2.x, we resolve the first match in the group ordering, unless some sort of Repository Routing or Repository Target rules prevent that from being matched (for example if you know bad versions of that component exist in that repository by not treating components immutably, etc...)
In Nexus Repository 3.x this is currently simpler as we have not implemented Repository Routing. The first match in the group ordering is what you would get back.
Group repositories serve a list of repositories under the same URL. They fetch the maven-metadata.xml files from all the repositories they serve and create a merged representation of them. They also have a Lucene index via the maven-indexer (which is a library contributed as OSS by Sonatype to Apache that allows a repository manager, or tool, such as an IDE, to work with this index of artifacts contained in the repository). The index of group repositories is also a merged representation of the indexes of each of the repositories in the group.
As far as I'm aware, for Nexus 2.x, the file system is the first place to try and, if it fails, the Lucene index is queried in order to resolve from the respective proxy repository's remote host.
We're trying to proxy the IBM Maven repository on our company internal Sonatype Nexus. We added the repository address but the repo has not been populated even under direct request.
The Sonatype nexus' "Browse Index" tab is empty whereas the "Browse Remote" correctly shows the library tree. But when adding dependecies to a project's pom.xml file, the IDE says it cannot find the archetypes and the artifacts.
Is the IBM repository indexed? Is there something we're missing? We are using IBM RAD 9.5 and Sonatype Nexus™ 2.11.4-01
Many Maven repositories do not publish search indexes, they are entirely optional, and only used to support interactive search. They are not used by Maven for artifact retrieval. To see if the remote publishes a search index try retrieving ".index/nexus-maven-repository-index.properties" from it.
If Maven cont' download artifacts from the repository see here for information on how to diagnose the issue:
https://support.sonatype.com/hc/en-us/articles/213464518-Troubleshooting-Artifact-Download-Failures
Again, artifact download failures have nothing to do with search indexes.
Question:
When importing maven artifact repositories (either from other instances of Artifactory, or nexus, for example), many artifacts (and most parent) poms contain url tags which reference the old repository. These url tags are within the distributionManagement and repositories tags.
Do we need to go through a time consuming process of updating these URLs for every single artifact (and parent pom, where applicable)?
Further Information:
We are in the process of migrating some artifact repositories to a whole new environment. We have an old Artifactory instance and a Nexus instance from a separate project that we need to migrate into a single Artifactory instance in a new environment. We currently don't have access to run maven builds from the Nexus repo - we have only been given access to their filesystem to pull artifacts across.
The new Artifactory version is newer than the old one, so we used the following process:
1. system export excluding binaries
2. copy filestore directory across to new Artifactory server
3. imported the system export
For Nexus, we are rsyncing the filesystem for each repository across to the new Artifactory server, and using the 'Import Repository from Path' feature.
These imports have all finished successfully, and we can see all of the required artifacts in the new Artifactory instance.
We have successfully executed a maven build that pulled down dependencies imported from the old Artifactory instance, and this same build successfully published it's artifacts back to the new Artifactory instance as well.
Given our successful tests so far, we're not sure if we really need to update them, or if they will become a problem later for some reason (such as when we decommission the old Artifactory instance)
You're lucky to use Artifactory in your new environment :)
Artifactory will automatically remove any <repositories> references from your pom files, leaving the resolution rules to your settings.xml. All you need to do is generate a new settings.xml file from your new Artifactory and all the resolution will occur from it.
In order for it to work, please declare the old Artifactory and Nexus as remote repositories for the new Artifactory instance (don't use export/import). Once new Artifactory fetches artifact from old Artifactory or Nexus it removes the repositories declaration and stores the new, clean pom in the cache.
After awhile when you sure everything is cached, you can decommission the old servers and declare those repositories as offline (optionally moving the artifacts to local repository).
Neither the repositories nor the distribitionManagement have an impact on your usage of the components and as such nothing needs to be done on the import.
The distributionManagement details where components are released to. Since the component are already released and in your repo server the content does not matter.
Having repositories as an element in your pom files is a very bad practice and should be avoided. However if you are using a repo manager and the appropriate settings using the mirrorOf setup in settings.xml none of the repositories will be taken into account, but instead your repo manager will be contacted as defined in your settings.xml.
As you can see you can just migrate the components and leave them alone. Modifying the poms of already released components is probably a bad practice, since it means that some clients will have one pom, while others will have a different one for the SAME artifact. This violates the idea of a non-changing release artifact and can cause problems.
And in terms of migration you can easily just migrate the repositories in Nexus and turn off the old servers (at least you could migrating to Nexus). That way you don't have to run a number of them in parallel and can quickly decommission, while at the same time being sure you have all your components in your new repo manager.
My intent is to proxy Roo Maven repository with my local Nexus installation, so that it will contain Roo 1.2.0.RELEASE packages.
On http://static.springsource.org/spring-roo/reference/html/resources.html it is written that Roo builds are published on http://spring-roo-repository.springsource.org/release.
Unfortunately that link returns error NoSuchKey.
Is there some other Maven repository to get Roo packages from ?
Based on this Nexus ticket I solved my problem by:
create Proxy on Nexus for http://spring-roo-repository.springsource.org/release
add this repository into default "Public Repositories" group
Nexus will proxy requested artifacts and it will crate index of this artifacts, but it is not able to index the whole http://spring-roo-repository.springsource.org/release repository, because its index is not published. The reason of this problem is that it is hosted on Amazon S3 storage.
Create (in Nexus) a proxy repository with the remote storage location = http://spring-roo-repository.springsource.org/release
Then, add it to the public repositories group.