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.
Related
In order to include a specific maven dependency, I included its repository in my pom. Because of this, maven will check every repository for every artifact. This repository is rather slow so I would rather have maven only reach out to it when checking for the dependencies that it provides.
Is there a way to limit maven to check a repository for certain artifacts? Perhaps certain group IDs?
I doubt that you can impose such filters, but Maven asks the repositories in a certain order until it finds the artifact. As we handle this problem through Nexus, I am not experienced in this, but the question How to set order of repositories in Maven settings.xml gives (maybe outdated) information about this.
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.
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.
I see several options:
directly in pom.xml
in company super-pom
in settings.xml (global or user)
in a profile or directly (in settings.xml or pom.xml)
We want our Jenkins to push artifacts to internal repository, and developers to pull missing artifacts from there.
If I put the repository URL in pom.xml, and later the internal repository is moved to a different address, the released versions will all have a broken link.
Super-pom saves some repetition, but in a clean setup you need to somehow know where the repository is to find the parent POM — to tell you where the repository is.
Having the URL in settings allows one to change it without modifying the artifacts, but there are two problems:
build will fail due to unresolved dependencies, if maven settings have no reference to the internal repo
developers have to update their settings.xml files manually
I'm also unsure about the merits of putting repository configuration in profiles. I know it let's you easily switch the repositories on and off, but shouldn't the -o option and snapshot resolution settings be enough for most uses?
What about using a different repository (e.g. with instrumented classes) for integration tests?
Configure a single repository in the users ${HOME}/.m2/settings.xml and configure other needed repositories in your appropriate repository manager either Nexus, Artifactory or Archiva. In Jenkins there is the Config File Provider plugin which exactly handles such situations in a very convinient way.
If you want to have repeatable builds and good control over your organization internally, use a repository manager and use a mirrorOf entry in everyone’s settings.xml to point at that url.
If you are exposing your source and want to make it easy for others to
build, then consider adding a repository entry to your POM, but don’t
pick a URL lightly, think long-term, and use a URL that will always be
under your control.
http://blog.sonatype.com/2009/02/why-putting-repositories-in-your-poms-is-a-bad-idea/
We are using nexus as a repository management system. However we are encountering a problem in regards to managing our groups.
Basically we have an snapshot versioned artifact that lives in two repositories. We add both these repositories to the same group in the order that we would like nexus to search them. This is in accordance with the documentation: http://www.sonatype.com/books/nexus-book/reference/config-sect-managing-groups.html
group
...
--> repo1
...
--> com.test.example-1.0.0-SNAPSHOT
...
--> repo2
...
--> com.test.example-1.0.0-SNAPSHOT
...
...
So by ordering repo1 above repo2 we always want to download the example artifact from repo1. What we find in reality however is that despite the ordering, we always download the latest snapshot version from either repo. So if repo2 has a more recent snapshot version we are pulling it down.
Has anyone else seen this behaviour? Does nexus not take ordering into account with snapshot repositories?
This is actually not Nexus but Maven that does it, what happens:
Maven requests "maven-metatadata.xml" from Nexus
Nexus cycles over member repositories in given order (repo1, repo2...) and merges that XML files.
From merged XML, Maven "gets the knowledge" of the latest snapshot, and explicitly asks for it.
Nexus can't do anything, I bet your snapshots has different names (artifactId-1.0-yyyy.mm.dd.hh.mm.jar, but those two has probably different yyymmdd etc), and serves up what Maven asks
What you can do here to make Nexus "hide" stuff from Maven is Routing rules. Add a rule that for given groupId, or artifactId or whatever (it's actually a regexp) serve only from repo1.