i am new to maven though worked on ant a lot.After going thru http://maven.apache.org/guides/mini/guide-mirror-settings.html, i am bit confused.
i have two basic questions:-
1)whats the difference between mirror url and pluginRepository url. As my understanding both url defines the url from where repository
needs to be downloaded
2)whats the diefference b/w repository and pluginRepository?
3)what actually profile is? as per my understanding its a goal which we want to execute. For example:- when we do mvn install, install is already
defined profile by maven. Is n't it?
Let me start with a basic difference in Maven.
In general repositories are containers which can store two major types of artifacts.
The first are artifacts that are used as dependencies of other artifacts.
The other type of artifact is plugins. Maven plugins are themselves a special type of artifact. Because of this, plugin repositories may be separated from other repositories
Usually there will not made a difference between pluginRepositories and usual repositories, but technically it's possible.
Now to your first question:
It is possible to declare a repository inside the project which means to put the repository definition into the pom file which is bad practice.
The mirror setting is usually used to mirror all request from the defined repositories into a defined URL (see mirror settings). In practice delegate all request to a particular URL which is usually a URL of a repository manager.
Now we came to your third question.
A profile has nothing to do with a goal and nothing with mvn install. The call mvn install calls the maven build life cyclce which will run all life cycle phase after another. A profile can be best translated with a if-statement. You can activate a profile on command line like this:
mvn -Pdev install
mvn -Prun-its verify
which is a kind of condition in you pom.
Related
Is there a way in Gradle to explicitly define where certain artifacts should be coming from?
We have a legacy project which is being on-boarded to use a proper artifact repository manager, instead of a network share. However, we have multiple repositories from which artifacts are being downloaded. We'd like to be able to fine-grain where certain artifacts should be coming from, until we can fully on-board to the artifact repository manager in question.
Is something like this possible?
Yes that is possible as of Gradle 5.1
https://docs.gradle.org/5.1/release-notes.html#repository-to-dependency-matching
Repository to dependency matching
It is now possible to match repositories to dependencies, so that Gradle doesn't search for a dependency in a repository if it's never going to be found there.
See the docs for more details: https://docs.gradle.org/5.6.2/userguide/declaring_repositories.html#sec::matching_repositories_to_dependencies
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.
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/
How do i set Maven to retrieve external dependencies first from my own remote repository (using Archiva), and if its not found, Archiva will download from external sources, and at the same time saves the downloaded dependency?
You essentially have to set up your .m2/settings.xml file, nothing fancy.
Here is a pretty comprehensive guide. While based on Artifactory, the aspects of POM configuring are obviously general. That should give you all the information you need.
According to the Maven documentation:
You can force Maven to use a single repository by having it mirror all repository requests. The repository must contain all of the desired artifacts, or be able to proxy the requests to other repositories. This setting is most useful when using an internal company repository with the Maven Repository Manager to proxy external requests.
To achieve this, set mirrorOf to *.
This StackOverflow question also suggests that setting mirrorOf is sufficient to block an external repository, so why does the Sonatype documentation suggest overloading central with an unreachable URL?
The bogus URL is really irrelevant - you can set it to the original one if you need to, or the URL of your repository manager - as long as the mirrorOf is applicable, it won't be used.
The reason these examples redefine central is to set policies on artifact requests to the default repositories. By default, Maven does not enable snapshot requests to central, and uses default update and checksum policies. Redeclaring central allows these to be overridden - in this case, to enable snapshot artifacts and plugins, and the mirror then redirects all of these to the repository manager. This avoids the need to declare the repositories in your POM (as long as all users have their settings correct).
I wrote that so I can tell you what I was thinking ;-)
The central repository definition needs to be updated to enable snapshot retrieval for at least one repo, otherwise Maven won't even ask the repository manager (pointed to by the mirrorOf) for any snapshots.
While not required, I like to change the definition of the url to be an invalid one also so if there is a misconfiguration somewhere else in the system, it becomes immediately obvious what is happening. Otherwise Maven may still reach out to Central and mask the problems. It's essentially a fail-fast setup.
There's more information on this topic in an old blog I wrote
maven needs project dependencies to be available locally for it to run. It does not care about how it is made available - whether manually installed (using mvn install:install-file), through a mirror or by from central repository. It will fail to run if it is unable to find dependencies.
The sonatype documentation that you are referring to is on using nexus to mirror/proxy repositories. The url specified should be a valid nexus url and cannot be unreachable.
The same is suggested in the SO question as well.