I have a nexus repo on my network. In settings.xml on the build server we have
<mirror>
<id>company.com</id>
<name>nexus</name>
<url>http://build.company.com/nexus/content/groups/public/</url>
<mirrorOf>*</mirrorOf>
</mirror>
On this build server we have a number of proxy repositories defined for public repos, and I have some commercially licensed artifacts in a hosted repo.
And a profile - Maven cannot resolve my parent pom (artifact in nexus) without this:
<profiles>
<profile>
<id>repos</id>
<repositories>
<repository>
<id>my-local-repo</id>
<name>bootstrapthingy</name>
<url>http://build.company.com/nexus/content/groups/public/</url>
<releases>
<enabled>true</enabled>
</releases>
<snapshots>
<enabled>true</enabled>
<checksumPolicy>fail</checksumPolicy>
<updatePolicy>always</updatePolicy>
</snapshots>
</repository>
</repositories>
</profile>
</profiles>
<activeProfiles>
<activeProfile>repos</activeProfile>
</activeProfiles>
My question today:
I also have removed all my
<repositories>
tags from the parent pom that all projects (should eventually!) inherit, and everything seems to work.
Is this well and good? I seem to end up a lot thinking about best practice when I work with maven - lately, around where should information be kept?
As my repositories are now defined at Nexus level, there is an element of my build that is no longer source code controlled, and this bothers me.
Yes I would argue you're on the right track!
Maven recommends to think about your infrastructure and plan it! By that it splits project concerns from infrastructure aspects. Project specific configuration goes into the pom.xml while I would vote to put infrastructure configuration into settings.xml
So the company mirror / proxy goes into settings.xml (as infrastructure may change) along with its authentication and environment settings (that are project independant!)
Usually projects do not rely on a per-project repository. If they do they could in almost any case use the nexus server for that (lets say explicit SNAPSHOT dependencies). So the practice to not have repositories in a pom.xml is ok. URL's change and builds should not request artifacts at different locations. It endangers your build reproduce-ability (as does adding all kinds of unstable remote repos into nexus).
I think within a company you need to consider (or simply acknowledge) that builds in projects are not self-maintained. Most open-source projects are since they do not have a common shared infrastructure they may benefit from (or suffer under?). You need to do the best of it but having infrastructure issues solved in settings.xml also means that the project does not need to do that anymore. Has pro's and con's - no doubt about that :)
Related
I've discovered today, while investigating a bug regarding my project being no more deployable, that maven tries to load dependencies from all available repositories.
I don't find it wise, specifically regarding our internal artifacts, that are searched on amven central, Sonatype FlexMojos, and other external release repositories (specificall when the last one provides a custom 404 page that maven wrongly interprets as valid content, replacing my valid artifact with an invalid one).
So, is is possible to tell maven which repositories to lookup for SNAPSHOTs artifacts, and which to lookup for RELEASE ones ?
Would it help if you made it explicit to not look for snapshots in your repo?
<repositories>
<repository>
<id>central</id>
<name>Maven Repository Switchboard</name>
<layout>default</layout>
<url>http://repo1.maven.org/maven2</url>
<snapshots>
<enabled>false</enabled>
</snapshots>
</repository>
</repositories>
My solution is to set up a repository mirror in the intranet. That way, Maven needs to know a single URL to download everything.
I then use the internal mirror to bundle repositories (local and remote ones). If snapshot repos are first in the search path, the mirror server will almost never publish the names of my internal artifacts (only when I forgot to deploy them).
On top of that, it will reduce the download times for the rest of the team plus it will make sure that everyone can still work even when there are network problems outside of your control.
I have a collection of related projects that inherit from a common maven project.
Since they are still in alpha release, they all (including the parent) are deployed in the Sonatype snapshots repository, instead of Maven central.
The configuration for accessing the maven central is in the parent project of my application.
So its POM specifies as its parent:
...
<parent>
<groupId>org.sonatype.oss</groupId>
<artifactId>oss-parent</artifactId>
<version>7</version>
</parent>
...
And set the corresponding repository at Sonatype:
...
<repositories>
<repository>
<id>snapshots-repo</id>
<url>https://oss.sonatype.org/content/repositories/snapshots</url>
<releases>
<enabled>false</enabled>
</releases>
<snapshots>
<enabled>true</enabled>
</snapshots>
</repository>
</repositories>
...
So the children projects do not have to repeat this configuration.
The parent also provides many other things that are common to all my projects.
Currently I keep all these projects in unrelated directories.
Now, if a user of my application checkout one of my projects and attempt to install it with mvn install, he will receive the error: Non-resolvable parent POM: Could not find artifact ...
This makes sense to me, since the project cannot access the Sonatype repository (e.g., for downloading the parent) since it is precisely the parent the one that contains how to connect to such repository.
I do not want to request the user to install first the parent project, since he should be able to install what he needs in just one single step.
Then what is the recommended way to distribute my libraries so the user can install any of them with one single command ?
It occurs to me that I could include the parent POM in each of the projects (for example, using git submodules) so the parent can be resolved locally. But I am wondering if this is the best way to organize this (?). Any better alternative is appreciated.
UPDATE
I added this to my ~/.m2/settings.xml so the parent POM could be resolved in the Sonatype snapshots repository. Apparently it is working fine and the parent POM is resolved as any other dependency.
<profiles>
<profile>
<id>allow-snapshots</id>
<activation><activeByDefault>true</activeByDefault></activation>
<repositories>
<repository>
<id>snapshots-repo</id>
<url>https://oss.sonatype.org/content/repositories/snapshots</url>
<releases><enabled>false</enabled></releases>
<snapshots><enabled>true</enabled></snapshots>
</repository>
</repositories>
</profile>
</profiles>
If you want to keep it to one step install than you have to list enough information in the project pom, i.e. either:
no parent pom, put all the information into each project pom
tell maven where to find your other projects. List the sonatype shnapshot repo in each project file.
A repository manager only helps those with access to it. That is ok if the users are in one organisation. Using the sonatype repository reaches a wider circle.
I want to include a parent in a project pom, containing distribution management and repositories. As one would expect.
When I mvn package the child, maven is unable to resolve the parent pom, unsurprisingly.
I can make it resolve the parent by adding my internal nexus repository to the child pom. But this sounds like eggs laying chickens - I'm telling the child something it should know from the parent. I would have to add this repo to every child pom that has a parent.
How can I avoid this?
As khmarbaise wrote, you need to define your repositories in a profile in your settings.xml (this seems somewhat weird, but is actually the only feasible way):
<profiles>
<profile>
<id>repos</id>
<repositories>
<repository>
<id>my-local-repo</id>
<name>Projektserver Snapshots</name>
<url>http://my-server/nexus/content/groups/public</url>
<releases>
<enabled>true</enabled>
</releases>
<snapshots>
<enabled>true</enabled>
<checksumPolicy>fail</checksumPolicy>
<updatePolicy>daily</updatePolicy>
</snapshots>
</repository>
</repositories>
</profile>
</profiles>
<activeProfiles>
<activeProfile>repos</activeProfile>
</activeProfiles>
Depending on your actual config, you would also include mirror setting and might call your local nexus central.
Sounds like the parent has been deployed to your internal nexus repository so it picks it up from there once you add in the distribution management and repository details.
To make it pick it up from your local copy. First ensure the versions match. Then navigate to the parent and run mvn clean install. This will push the parent pom to your local maven repo.
You may also get round this by ensuring you have added the releativePath element to the parent details in the child pom, you may not need to manually build the parent then but im not 100% sure and havent tested that.
The only things which should defined in your pom is distributionManagement the repositories should be defined in settings.xml instead.
I am using my own version of the Nexus web app repository installed on my local machine. I have Nexus configured with only one repository, the one where I store my snapshots:
http://localhost:8081/nexus/content/repositories/MySnapshots/
Note that after the Nexus installation I removed all the default repositories and added just my own. (Perhaps this was a bad idea?)
When I do a mvn clean install I noticed that some of the 3rd party artifacts are downloading straight from the remote repository. For example, here is one of the output lines from the build:
Downloading: http://repo.maven.apache.org/maven2/com/sun/org/apache/xml/internal/resolver/...
The strange thing is that I see other artifacts are going through my local Nexus to ultimately get to the artifact:
Downloading: http://localhost:8081/nexus/content/repositories/MySnapshots/org/apache/maven/wagon/wagon-provider-api...
Notice how the first part of the download url is my local repository but everything after MySnapshots is from apache.org.
It's almost like my Nexus repository is acting like a proxy to maven.apache.org for some artifact downloads but for others it goes straight to the source.
Can anyone tell me why this is happening?
I would't be bothered so much by this if all my builds succeeded all the time but sometimes, when I am compile large projects, I get build failures due to not being able to find an artifact.
For example, when I try to build another project that depends on eclipse jdt stuff I get the following error:
Downloading: http://localhost:8081/nexus/content/repositories/MySnapshots/eclipse/jdt/core/eclipse.jdt.core
Could not find artifact eclipse.jdt.core:eclipse.jdt.core
I am not sure if this means that my Nexus is not configured properly or if there really is no artifact eclipse.jdt.com. If the downloads were not going through my local Nexus repository I would then investigate the pom/settings.xml files. Instead this makes me wonder if it's due to my Nexus configuration.
If you would like to see my settings.xml for Maven and my pom file for the project I am building when I see this you can view them here:
settings.xml: http://pastebin.com/NvLr5bEA
pom.xml: http://pastebin.com/PJ0P3RaK
If you like to use the local nexus as a proxy as usual than you have to configure the settings.xml like this:
<mirrors>
<mirror>
<!--This sends everything else to /public -->
<id>nexus</id>
<mirrorOf>*</mirrorOf>
<url>http://localhost:8081/nexus/content/groups/public</url>
</mirror>
</mirrors>
<profiles>
<profile>
<id>nexus</id>
<!--Enable snapshots for the built in central repo to direct -->
<!--all requests to nexus via the mirror -->
<repositories>
<repository>
<id>central</id>
<url>http://central</url>
<releases><enabled>true</enabled></releases>
<snapshots><enabled>true</enabled></snapshots>
</repository>
</repositories>
<pluginRepositories>
<pluginRepository>
<id>central</id>
<url>http://central</url>
<releases><enabled>true</enabled></releases>
<snapshots><enabled>true</enabled></snapshots>
</pluginRepository>
</pluginRepositories>
</profile>
</profiles>
<activeProfiles>
<!--make the profile active all the time -->
<activeProfile>nexus</activeProfile>
</activeProfiles>
The tricky thing is the mirror thing which reroutes every call to the configured nexus instance.
Things you mentioned like eclipse parts can be problematic, cause only a few artifacts are available via maven central. Furthermore you should leave the defaults like maven central, release repository and the snapshots repository unchanged, cause these are the repository you need.
I don't think its a proxy issue , upto my understanding for the first case when it is downloading from Maven Central Repo , it might be possible that same artifact is not available in your nexus repository , that's why it is going to Maven Central Repo.
In the second case it is available in your nexus so reactor didn't try to download it from Maven Central Repo.
I was curious about how to set up development vs production maven profiles. Should I only put the snapshots repo in the dev profile, and the other artifacts (local repo, for releases etc), in the production profile?
What are the major things which different profiles of these types?
The major difference is, obviously, settings among Prod, Test, and Dev profiles. Things like
Database connectivity
Properties like resource settings, thread-pool configuration, log file location and it's size
Storage settings like for local you might have a /mnt/media but for Prod, you may want S3
varies in these profiles.
Now come to release, usually Test profile/s has SNAPSHOT releases (like nightly builds) that is configured to go to SNAPSHOT repository of yours. And a Prod profile is released, usually, using Maven Release Plugin, that automatically knocks the SNAPSHOT off your release version/artifacts. And is configured to store the artifact in RELEASES repo. The configuration for these repos goes like
<profile>
<id>test</id>
<distributionManagement>
<snapshotRepository>
<id>snapshotrepo</id>
<name>Repository for snapshots only</name>
<layout>default</layout>
<uniqueVersion>false</uniqueVersion>
<url>http://repo.company.com/snapshots</url>
</snapshotRepository>
</distributionManagement>
.....
.....
.....
<profile>
<id>prod</id>
</distributionManagement>
<repository>
<id>releaserepo</id>
<name>Final release artifacts</name>
<layout>default</layout>
<uniqueVersion>false</uniqueVersion>
<url>http://repo.company.com/releases</url>
</repository>
</distributionManagement>
....
....
The credential to these repos goes into settings.xml.
Dev profile is usually not configured to release to company repo (as it will be too cluttered of useless artifacts), it just gets installed in your local repo, as SNAPSHOT and overwritten on each build.
Usually (in my experience) the different repos are configured in settings.xml, and not in separate profiles (except maybe in profiles enabled by default).
Example of a default profile:
<profile>
<id>default</id>
<activation>
<activeByDefault>true</activeByDefault>
</activation>
<repositories>
<repository>
<id>central</id>
<url>http://some_url/content/groups/public</url>
<snapshots>
<enabled>false</enabled>
</snapshots>
</repository>
<repository>
<id>snapshots</id>
<url>http://some_url/content/groups/public-snapshots</url>
<releases>
<enabled>false</enabled>
</releases>
</repository>
</repositories>
If you are concerned about having SNAPSHOT dependencies in your releases, you can use tools like maven-release-plugin to verify that there are no SNAPSHOT dependencies in your project.
What are the major things which different profiles of these types?
You often use profiles to separate between different build environments. For instance, using a CI you often put plugins for static code analysis, reporting, test coverage etc. in a profile that is only activated when building on the CI server (since it takes more time to run it with these tools enabled).
Another use is to separate out specific part of the application, for instance you don't want the acceptance-test submodule to run on every mvn test, but only sometimes when you enable the mvn test -p acceptanceTests profile
The problem with environment specific builds
Now, profiles are sometimes used to separate configurations like connections strings, enpoints etc. In my view that is not ideal, since you end up with environment specific builds. Sometimes that is hard to avoid, but most of the time this can be solved by externalizing configuration (make sure to have proper configuration management), and use the same binary artifact in dev/test/prod. That way you are sure that the build that passed system test is the same as that in prod etc.