1

We have Artifactory setup and we use Maven central repo for downloading artifacts, which are then automatically cached in Artifactory. We also upload/deploy our own artifacts in Artifactory.

I now want to replace Maven central repo with jcenter and would like to continue using our Artifactory for uploading/deploying our own artifacts and for also caching the jcenter (and any third-party) artifacts. I can ask all developers to modify their settings.xml file as it will be a one-time activity so that's not a problem.

I saw this link by @helmedeiros which describes making changes in <repositories> and <pluginRepositories> section of settings.xml file. However, those are the sections where i specify URL for our Artifactory server. If i replace my Artifactory URL, then it would mean that i will be able to both fetch and upload artifacts from jcenter which is not what i want.

How can i ensure that all developers are only able to pull (NOT deploy/upload) from jcenter and deploy/upload ONLY to Artifactory?

Here's what we have right now in settings.xml:

<?xml version="1.0" encoding="UTF-8"?>
<settings xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.1.0 http://maven.apache.org/xsd/settings-1.1.0.xsd" xmlns="http://maven.apache.org/SETTINGS/1.1.0"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <servers>
    <server>
      <username>${security.getCurrentUsername()}</username>
      <password>${security.getEscapedEncryptedPassword()!"*** Insert encrypted password here ***"}</password>
      <id>central</id>
    </server>
    <server>
      <username>${security.getCurrentUsername()}</username>
      <password>${security.getEscapedEncryptedPassword()!"*** Insert encrypted password here ***"}</password>
      <id>snapshots</id>
    </server>
  </servers>
  <profiles>
    <profile>
      <repositories>
        <repository>
          <snapshots>
            <enabled>false</enabled>
          </snapshots>
          <id>central</id>
          <name>libs-release</name>
          <url>https://inhouse-artifactory/artifactory/libs-release</url>
        </repository>
        <repository>
          <snapshots />
          <id>snapshots</id>
          <name>libs-snapshot</name>
          <url>https://inhouse-artifactory/artifactory/libs-snapshot</url>
        </repository>
      </repositories>
      <pluginRepositories>
        <pluginRepository>
          <snapshots>
            <enabled>false</enabled>
          </snapshots>
          <id>central</id>
          <name>plugins-release</name>
          <url>https://inhouse-artifactory/artifactory/plugins-release</url>
        </pluginRepository>
        <pluginRepository>
          <snapshots />
          <id>snapshots</id>
          <name>plugins-snapshot</name>
          <url>https://inhouse-artifactory/artifactory/plugins-snapshot</url>
        </pluginRepository>
      </pluginRepositories>
      <id>artifactory</id>
    </profile>
  </profiles>
  <activeProfiles>
    <activeProfile>artifactory</activeProfile>
  </activeProfiles>
</settings>

I will really appreciate any help in this regard.

Community
  • 1
  • 1
Technext
  • 7,887
  • 9
  • 48
  • 76

1 Answers1

0

I have exactly the same question :)

My solution is to create an Artifactory virtual repository (forgerock-third-party-virtual) to cache most of the public artifacts.

This virtual repository includes a remote repository based on jcenter:

enter image description here

On the virtual repository, there is no default deployment repository:

enter image description here

So with this setting, I hope the developers won't be able to push in this virtual repository.

According to the JFrog documentation, you have select one repository in this drop-down to be able to push into a virtual repository.

Regarding the deployment settings, we also have a parent pom where we specified our own repositories in the <distributionManagement> section.

On my build machines, I've added this profile (in .m2/settings.xml) to cache the artifacts:

 <profile>
  <id>force-third-party-repo</id>
  <activation>
    <activeByDefault>true</activeByDefault>
  </activation>
  <repositories>
    <repository>
      <id>forgerock-third-party</id>
      <name>ForgeRock Third Party Repository</name>
      <url>http://maven.forgerock.org/repo/forgerock-third-party-virtual</url>
      <snapshots>
        <enabled>true</enabled>
      </snapshots>
      <releases>
        <enabled>true</enabled>
      </releases>
    </repository>
  </repositories>
   <pluginRepositories>
    <pluginRepository>
      <id>forgerock-third-party</id>
      <name>ForgeRock Third Party Repository</name>
      <url>http://maven.forgerock.org/repo/forgerock-third-party-virtual</url>
      <snapshots>
        <enabled>true</enabled>
      </snapshots>
      <releases>
        <enabled>true</enabled>
      </releases>
    </pluginRepository>
  </pluginRepositories>
</profile>

I have other settings in this file to declare our own Artifactory repositories (for pushing/pulling our own artifacts) + some Maven credentials.

I did some tests with one of our Maven projects and it was working fine.

Once the new .m2/settings.xml will be ready, I'll push a template in an internal Artifactory repository, so the developers will be able to get this template with a curl command.

FYI, this is a POC for the moment. We want to move in production with these settings in a few days.

Bruno Lavit
  • 10,184
  • 2
  • 32
  • 38
  • I didn't really get your motive behind setting up a new virtual repository. As far as fetching is concerned, i observed that if you drag the jcenter to top (don't remember whether it was at top by default) in `Virtual > remote-repos`, section, then it caches into jcenter-cache automatically. This solves my concern of fetching from _jcenter_ instead of Maven central. For preventing deployment to _jcenter_, i think keeping the 'Default Deployment Repository' as blank might only partially address the issue. What if someone specifies _jcenter_ as default deployment path in their settings.xml file? – Technext Jun 06 '16 at 18:09
  • My virtual repo is an aggregation of several remote + one local repo. By using a single entry point (the virtual repo), I'm able to set only one time the relevant credentials in my settings.xml. About your deploy problem, can you solve it using the Artifactory permissions mechanism? You can set only a read access for your users. It should do the job to protect your repo against deployment. – Bruno Lavit Jun 07 '16 at 11:02
  • I was going through [this](https://www.jfrog.com/blog/push-the-limits-of-virtual-repositories-2/) article which is what i guess you're saying. Please correct me if i'm wrong. If i'm right, then i'm wondering how come a _single_ URL serve the purpose of deploying to both local snapshot and local release repositories? How will one be able to differentiate as to where the artifact will be deployed? In `` section, we specify the Artifactory URL and append either `libs-snapshot-local` or `libs-release-local` but in this case, i'm not sure. – Technext Jun 08 '16 at 17:49
  • If you have to deploy both release and snapshot artifacts (like most of the companies), I think the single URL is not the solution :( I think if the `` section is defined in your parent pom, it will deploy the artifacts in the relevant repos (snapshot or release). For my company, the plan is to use a single URL to resolve and to have the distribution repos set in the parent pom. This is the test I'm doing right now. – Bruno Lavit Jun 10 '16 at 14:50
  • Ok. So do you guys not differentiate between a snapshot and a release artifacts when it comes to deploying to Artifactory? – Technext Jun 11 '16 at 14:02
  • Yep we differentiate, we have 2 repositories configure in the `` section (one for snapshot and one for release). This is in our parent pom. In the project pom, I'll use only the virtual repo to resolve everything (3rd party, internal, ...) – Bruno Lavit Jun 12 '16 at 17:16
  • My mind is completely confused. I'll have to think about it afresh. – Technext Jun 14 '16 at 11:32