I want to setup Artifactory for a large company and I have a question:
Should every application group have their own set of snapshot and release repos so module collisions don't occur?
The best practice for setting up maven repositories in large companies is to have a SNAPSHOT and a RELEASE maven repo for a functional domain, group of applications or similar.
Probably you need remote repos for external dependencies that are in Maven Central or in other external repositories, in this case, you need to create a remote repo to access these dependencies.
Also, you can have a virtual repo to group all of these local and remote repositories.
For, example:
You have a banking website for personals finances with these maven repos:
SNAPSHOT maven repo: personal-finance-local-SNAPSHOT
RELEASE maven repo: personal-finance-local-RELEASE
You have a banking website for enterprise finances with these maven repos:
SNAPSHOT maven repo: enterprise-finance-local-SNAPSHOT
RELEASE even repo: enterprise-finance-local-RELEASE
If you have external dependencies in Maven Central, you can create two remote maven repos: remote-SNAPSHOT and remote-RELEASE
Finally, create a virtual maven repo in Artifactory to group all maven repos that you want, for example, all of this example. You can have the repo virtual-maven-SNAPSHOT and the virtual-maven-RELEASE where you can have all the SNAPSHOTs or all the RELEASEs dependencies.
If you don't want to have a virtual repo for SNAPSHOTs and another for release versions you can have an unique virtual repo like: virtual-maven
If the company is really that big,(beside the thing you mentioned) it has probably internal release procedures. Like, to be able to release a product even internally some quality assurance protocols must be fullfiled.
In this case, different groups should not able to access other groups repositories without this qa protocols being fullied.
Private repositories for each software group is way to go in this case. And if a group's products can be used internally, It should have another repo for internal releases where others can access.
Related
We have Sonatype nexus repository where we publish artifacts. I want to mirror that repository in a different server located in a different office location. Is there a opensource tool to mirror an entire repository? Note: I am not talking about proxy repositories or caches. I want active mirroring with the two repositories more or less in sync.
You need to setup one as a main repository (basically the one you have) and then the second one in proxy configuration, see this detailed instruction:
https://help.sonatype.com/learning/repository-manager-3/first-time-installation-and-setup/lesson-2%3A-proxy-and-hosted-maven-repositories#app
I now have a PC working as a Sonatype Nexus server and a development environment. I know Nexus stores artifacts for proxy type repository in SonatypRoot\sonatype-work\nexus\storage, and Maven will use a local repository to store artifacts (default directory is C:\USERS\USER_NAME\.m2\repository).
So the question comes when I'm using Maven with Nexus running on the same machine, because i have two copies of every artifact which is big waste of storage.
In Nexus's configuration tab for proxy type repository, there is an option named Override Local Storage Location.
My question is can I set this to my Maven's local repository?
That's a bad idea. One common purpose of nexus to publish artifact internally within your organisation. Typically this is done using mvn deploy. On the other hand your maven local repository serves purpose as a cache to avoid downloading stuff that has been obtained before. If you mix them together you might be accidentally publishing artifacts to your organisation while you just want to test locally in your PC.
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.
We have recently decided to use Maven as build system. I'm responsible to migrate all the projects from Ant to Maven. We also decided to use Apache Archiva to configure an internal repository in the company.
I see that Archiva create two repositories by default (internal and snapshots). I also see that it configures the internal repository to proxy the central and java.net repositories.
Are there some best practices regarding Archiva configuration?
In the Archiva documentation, there is a possibility to configure Maven to use only the internal repository and then access the remote repository through the internal repository. What do you think about this option?
Thanks for your help
A Maven repository manager is essential to support Enterprise Maven development. The Maven installer is merely a bootstrap, running Maven for the first time downloads everything it needs from the Maven Central repository in order to compile your project.
The benefits of using a Maven repository aree documented elsewhere but I'll summarize:
Efficiency. Repository acts as a cache for Maven Central artifacts
Resilience. Repository protects against remote repository failures or lack of internet connection
Repeatability. Storing common artifacts centrally, avoids shared build failures caused by developers maintaining their own local repositories.
Audit. If all 3rd party libraries used by development come from a single entry point in the build process one can assess how often they're used (based on download log files) and what kinds of licensing conditions apply.
To that end I'd encourage you to use the following Archiva features:
Locking down to only use Archiva. Configure Maven clients download everything from Archiva.
Virtual repositories for each team. Configure all the remote repositories used by teams centrally in Archiva instead of leaving the details to the teams themselves.
PS
I use Nexus for my Maven repository management, but the same concepts apply.
I have a Maven project that was built a few years back, and now I need to make some updates. One of the dependencies to my project has a Maven repository listed in its POM that no longer exists. I get build failures now.
I would have thought the repository listings in my POM or Settings.xml would trump any repositories listed in a dependency's POM; or Maven would try my repositories after failing to connect to the extinct repository. Instead, it just bombs out with a build failure.
Additionally, I already have the required dependencies in my local repository. I would have additionally thought that Maven would just use that.
Is there a way to override the inherited repository listings, or tell Maven to carry-on in the case of a repo problem?
If the artifact that you depend on is a snapshot version then maven will check for a new snapshot every time you build, thats why it is a good practice to lock down your dependencies to a released version.
You can "override" the repository declarations by defining a <mirror> in the settings.xml.
See http://maven.apache.org/settings.html#Mirrors
I usually set up a locally hosted repository manager (preferably nexus) and then define mirrorOf(*) = local-repo-manager/url.
Nexus allows multiple repo's to be grouped with a predefined search order.
Nexus repo's can be locally hosted or caching/proxies to public repo's.
I usually have a locally hosted 3rd party repo at the front of the group, where I can store artifacts that are not published on public repo's.