We use Artifactory for our company's Maven repository. Is there a way to set it up (or set Maven up) so that an artifact can't be deployed to the repository if there is a pre-existing artifact with the same version number?
The reasoning for this is to make sure that valid releases don't accidentally get overwritten. If an artifact really does need to be re-deployed, one of our developers can use the Artifactory web interface to delete it. Then they can deploy the new copy.
Thanks!
This is easily achieved by revoking the "Delete" permission from the deploying users\groups on the target repository; the delete permission is required for both artifact removal and artifact re-deployment.
All user\group permissions are editable within the UI at Admin->Security->Permissions.
Also see Managing Permissions
Related
We are looking into setting up a local maven repository server at our institute. We have several teams that are completely independent and therefore should not have write access to each others artifacts.
Ideally we would like a similar permission concept as e.g. Gitlab, where every user can create a project (or in this case repository) and give permissions to it, but not have write access to any other repositories.
I tried out Artifactory and Nexus, but as far as I could tell, giving permissions to a group for a specific project includes manual work for a user with full admin rights, namely creating that repository.
Is there a freely available maven repository server, that allows creation and administration of repositories by users without giving them access to other repositories? If not, is there one, that can restrict write access for an artifact to the person who first deployed it?
Even better if Artifactory or Nexus can in fact do something like that and I just missed it.
You can create an arbitrary number of repositories in one Nexus 2.x (professional) server. Then you can set up different user accounts with different writing rights, e.g. you can create a projectA repository and define a projectAuser which has writing rights only for this particular repository.
I guess this is possible in Artifactory and Nexus 3 as well, but I do not have experience.
In Artifactory you have many options, I recommend you:
Create a virtual maven repository with permissions for a group of users.
Configure the settings.xml of this group of users with this virtual repository.
Create remote repositories to access to Github or any other websites.
Add these remote repositories to the virtual repository.
Create local repositories if you need and add to the virtual repository.
Do this with every group of users that you want and you will have independent artifacts and repositories.
I had jcenter repository in my artifactory under remote repositories. Since some of the artifacts were missing such as qpid, I decided to delete jcenter and add it back. When I deleted the jcenter repository and added it back it didn't download any artifacts.
The repository tree structure looks like this
Before removing the jcenter repository it was like this.
Why it is not able to import any artifact? I can see the URL which is associated with it(http://jcenter.bintray.com/) has so many artifacts.
A remote repository in Artifactory serves as a caching proxy. This means that it downloads artifacts from the remote URL and cache them in Artifactory,
When you deleted the JCenter repository from Artifactory you deleted all cached artifacts.
After recreating the repository, your cache is empty. This is why, when browsing jcenter-cache, you see no artifacts. You can use the remote browsing capability in order to see which artifacts are available in the remote URL, but not currently caches
To re-populate the cache, you will need to download artifacts from the remote repository. Usually the best way to do it, is running your builds which are using this repository.
If the problem is that artifacts are not resolved at all from the remote repository, try the following:
Make sure the repository is configured correctly in Artifactory. Use the "Test" button to make sure that the URL is correct and you can reach the remote URL.
Check that your build tool is properly configured to use the repository you configured. One way of checking this, is by monitoring the Artifactory request log looking for requests from your build tool.
Deleting a repository is not a good practice when you are missing some dependencies. A better approach would be checking if they are available in the remote URL and downloading them into the cache. Artifactory has the option to perform a remote search in Bintray which can help you when looking for artifacts in JCenter.
We're deploying our open source libraries to the OSS instance of Sonatype Nexus (https://oss.sonatype.org/) using the nexus-staging-plugin. This works all fine and well. However, since we're using a build server I want to block an accidential re-deployment of an existing artifact id - as this is normally not suppoted by maven. However, the OSSRH happily accepts and updates an existing release. Is there any way to block this and make the build fail?
I know that Nexus can be configured to do that - it is just, that I don't have any permissions to reconfigure the OSSRH instance..
Is there any maven plugin which could check the repo first and fail in first place in case nexus/sonatype does not support this? I looked into the enforcer plugin but there isn't a rule available.
It is true that there is a staging rule in Nexus which prevents duplicate GAV's being staged, but it is not enabled on https://oss.sonatype.org. The reason for this is that some users stage artifacts repeatedly (creating multiple staging repositories) and then choose one of them for release based on testing results.
But the server at https://oss.sonatype.org is configured so that you cannot release the same artifacts twice. So if you have two staging repositories that contain the same artifacts you will only be able to release one of them.
The requirements are as follows. We need copies from binaries we need in our projects on our repository server. We can't just proxy the public repository because we had several cases in the past where the binaries on the public repository were changed without changing the release number and we want to avoid problems imposed by that, thus we want to manually specify when to download it from the public repository and when to update. No changes are ever to be made to the binary stored on our repository server without manual interaction.
Is there a way achieve this? I.e. to say "I want artefacts X, Y, Z" copied to my repository server(preferably including their dependencies). Is this possible with either Nexus or Artifactory?
Yes. In Nexus define your own local repository, manually download the versions you want and add them to your repository. You may have to set up "manual routing" for dependency resolution to ensure that Nexus consults the repos in the correct order.
Then make sure your pom files refer to the specific versions you have downloaded.
One thing that will make this a little easier is that you can place the downloaded artifacts directly into the local storage directory of a Nexus repository (you don't need to upload them into Nexus).
See here for details: https://support.sonatype.com/entries/38605563
I have problems with configurations using Maven + Artifactory.
I try to download a new external file using a user created in Artifactory and my Artifactory doesn´t make download, claiming "Access denied" but if I put the same credentials as defined in remote settings, my application can download every external jars.
If I use the same permission setting of my remote configuration settings.xml where the Artifactory was installed (user admin) I can make downloads quickly.
There´s some way to configure to create a user in my Artifactory and configure the permission to make downloads of new artefacts? Because I didn´t find in anywhere.
I think that is more secure for my company if I have the possibility to create a new user in my Artifactory and just give the permissions: read and to download new artefacts but this option doesn´t exist in Artifactory.
How could I do this?
Because you've created a user entity within Artifactory, make sure it's got at least read permissions on all the repositories you'd like to resolve from.
For easier Maven configuration, you can also use Artifactory to generate proper Maven settings for yourself; this helps to reduce typos and reference mistakes (make sure you're logged in as the user entity you've created whilst generating the settings). After applying the settings file you can also run the mvn help:effective-settings goal on your project to make sure everything was applied correctly.
Finally, if you're required to authenticate with the remote repository you're proxying, you'll need to he specify the credentials in the configuration of that remote repository.
Make sure the user you are using to connect to Artifactory has Deploy permissions in Artifactory. The Deploy permission allows the user to download artifacts from repositories (in other words, populate cache with remote artifacts).
https://www.jfrog.com/confluence/display/RTF/Managing+Permissions
Deploy Allows deploying artifacts and deploying to caches (i.e.
populating caches with remote artifacts)
More information from the JFrog forum:
http://forums.jfrog.org/Maven-using-anonymous-user-even-though-artifactory-server-setup-in-the-settings-xml-td4634521.html