Why repository in pom.xml is a bad idea

About six months ago I published a tutorial on adding libraries to the project that are not in the maven repositories. It was about small projects, and I recommended putting the repository tag right in pom.xml so that you can build a project without having to edit settings.xml.

In the comments this approach was criticized by sshikov , igor_suhorukov , jbaruch and many others. In the same place, in the comments, I was given a link to an article by Brian Fox, which clearly and clearly states what the repository in pom.xml is fraught with. Article 2009, but not lost relevance so far. I did not find a translation in Habré - therefore I offer you my attention.

There is one question that I get asked very often, and I think it’s time to put my thoughts on this in writing so that I don’t have to repeat them again and again.

Here it is, this question: Where to put the paths to the repositories: in memorials or in settings.xml ?
The short answer is: settings.xml .
Long answer: According to circumstances .

Here we need to consider two scenarios: for an enterprise (software that is not accessible from the outside) and publicly available software.
We'll start with the enterprise.

Enterprise

In the case of an enterprise, the common practice is to install some kind of repository manager like Nexus. It works as a proxy for all external repositories, and also manages internal ones.

When maven searches for artifacts, he walks through the list of repositories defined in memos and in settings.xml until he finds what he is looking for. If you specify your repository manager as the repository in the pay server, maven will still roll back to the search in the Central repository when it does not find artifacts there.

One way to solve this problem is to redefine the id of the Central repository and enter the address of your repository manager there. Such a solution may be appropriate, but in order not to repeat the procedure for each project, it should be done in any one corporate pom file. After redefining Central, you end up in Trick-22 . In order to find a dumpster, in which the path to the repository is indicated, you need to know where the repository, in which this dumpster is located. All will end with the fact that in any case you have to add this repository in settings.xml just for something to work at all.

There are other problems with the simple redefinition of Central. Specifically, this method does not allow processing calls to other repositories that may be in the transitive dependencies of the project and redirect requests to them. This causes problems: first, the build slows down, since maven goes around all external repositories in search of an artifact ... Perhaps it will search for an artifact even in your internal repositories, in which this artifact is definitely not. Secondly, it means that something can gather from one developer and not gather from another. Thirdly, it turns out that as an organization you have no idea where your artifacts come from.

For you, as organizations, in most cases it is convenient when all developers use the same repositories for building and all requests go through one controlled mechanism. This is most easily achieved by using the mirrorOf * entry in settings.xml, which will redirect all requests to your repository manager. In the mirrorOf can not be determined. Examples of how a good setup looks like can be found in this section of the Nexus Book .

Given all these points, it is clear that the definition of repositories in pom.xml actually does not really help and basically only creates additional problems.
The above implies that your artifacts do not have an external consumer. If this is not the case, then besides the first category, you also fall into the second. (Categories do not exclude each other.)

Open source projects

If you publish your software in open access and it will be downloaded and collected by someone other than you, then you need to take into account other points. If all your dependencies are in the Central repository, then nothing else needs to be done. However, if your artifacts can only be put in your own repository ( we are talking about, for example, SNAPSHOT versions of your parent lovers ), or in a third-party repository, then developers will have problems assembling your code. In this and only in this case, it makes sense to add a repository to your skomics. But there are side effects that you need to know about.

• The records that you made will be eternally cast in the unmarked records. This means that if the URLs change afterwards, everyone who uses your old books will get broken links, and they will have to find the working links manually.
• Each of these records will fall into their assemblies, since maven will need to view them when searching for dependencies. At the moment, maven is not able to understand that the dependencies of your repository are in it (and if transitivity is taken into account, the situation looks even worse).

If the build result is a utility (like Nexus), rather than a component that will be used as a dependency, then adding a repository to a memory card is more or less safe. In this case, it is unlikely that someone else will depend on your artifact in their assembly directly, and the above concerns become baseless, since the new versions of the code are likely to get the right ways.

If you publish jarks that will be used in the assembly by someone else, then you need to think about posting them and their dependencies in the Central repository. Then they will always be available to all users, regardless of what happens to your repository or urls, and there is no risk of accidentally adding new repositories to the builds. For the same reason, Central will sooner or later stop taking memorials with repository.

Total

In the dry residue we have the following. If you need reproducible assemblies and good control over what is happening inside the organization, use the repository manager, and also set mirrorOf in settings.xml with all employees to specify the address of this manager.

If you give the source code out and want to be convenient to collect it, consider adding a repository to a commemoration, but do not approach the choice of url lightly, think strategically, and use an url that will always be under your control. If the URL has to be changed, make sure that you can always track 404 errors and write the appropriate mod_rewrite rules to make sure that future builds can find the appropriate artifacts.

PS

And finally a little bike from my own life. Once upon a time I participated in the creation of a concept proof of one interesting idea. Everything was done on java, and the code had to be deployed naturally in the customer’s environment, otherwise - what a proof it is :). The assembly was designed according to the recommendations of the best dog breeders, the repositories were connected in settings.xml, the artifacts lay in Nexus - just like in this article.

But during deployment , it suddenly became clear that the settings.xml, which is used during the build, will not give us even a look, let alone edit it. Enterprise, security, everything. And I had to put a repository in a skirt. The repositories for development and for CI were different, and in order to somehow handle this situation, we made 2 profiles: one - with repositories for CI, which was default, and the other - with repositories for development, which was marked as default in settings .xml on the developer's machine. Emotions, I remember, we then drank pretty. This is how it happens.

UPD.
Here came 2 useful tips from jbaruch , which well complement the article, add them here. He, of course, drowns behind the Artifactory, but it’s good advice, but for some reason Nexus’s lawyers didn’t run into Temko.

1. Use clearing repositories from pom.xml in Artifactory . If someone in the team is still too lazy to do the right thing, and then he says, the CI build will fall, since the repositories will be deleted from pom.xml .

   
   
2. At least on the CI server (and better everywhere) use Maven Wrapper . In the maven-wrapper.properties file , you can register the distributionUrl to an arbitrary Maven distribution, which gives you the opportunity to download a distributive from the Artifactory, which already has the correct settings.xml with the correct repositories and only uses it. Nobody will prohibit, again, the developers put Maven out of the box and nafigachit any repositories in settings.xml and pom.xml , but if your CI uses a wrapper that downloads the distribution with the correct repositories, your build will run correctly and fall, if something goes wrong.