2016-05-20 11 views
1

Wir haben Artifactory Setup und wir verwenden Maven Central Repo zum Herunterladen von Artefakten, die dann automatisch in Artifactory zwischengespeichert werden. Wir laden auch unsere eigenen Artefakte in Artifactory hoch.Konfigurieren von jcenter für das Herunterladen von Artefakten und Artefakten für die Bereitstellung von Artefakten

Ich will jetzt Maven zentrale Repo mit jcenter ersetzen und möchten mit unserem Artifactory für das Hochladen fortzusetzen/unsere eigenen Artefakte bereitstellen und auch für die jcenter das Caching (und von Drittanbietern) Artefakte. Ich kann alle Entwickler bitten, ihre settings.xml Datei zu ändern, da es eine einmalige Aktivität sein wird, also ist das kein Problem.

Ich sah this Link von @ Helmedeiros, die Änderungen in <repositories> und <pluginRepositories> Abschnitt der Datei settings.xml macht. In diesen Abschnitten gebe ich jedoch die URL für unseren Artifactory-Server an. Wenn ich meine Artifactory-URL ersetze, würde das bedeuten, dass ich Artefakte von jcenter holen und hochladen kann, was ich nicht will.

Wie kann ich sicherstellen, dass alle Entwickler sind nur in der Lage zu ziehen (NICHT deploy/upload) von jcenter und deploy/upload NUR zu Artifactory?

Hier ist, was wir jetzt in settings.xml haben:

<?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> 

Ich werde wirklich jede Hilfe in dieser Hinsicht zu schätzen wissen.

+0

@JBaruch: Können Sie mir bitte zu diesem Thema helfen? – Technext

Antwort

0

Ich habe genau die gleiche Frage :)

Meine Lösung ist ein Artifactory virtuelles Repository (Forgerock-Dritt virtuell) erstellen die meisten öffentlichen Artefakte cachen.

Dieses virtuelle Repository ein Remote-Repository basierend auf jcenter umfasst:

enter image description here

Auf dem virtuellen Repository gibt kein Endlager Standard Einsatz ist:

enter image description here

Also mit dieser Einstellung Ich hoffe, dass die Entwickler dieses virtuelle Repository nicht einschieben können.

Gemäß JFrog documentation haben Sie in diesem Dropdown-Menü ein Repository ausgewählt, um in ein virtuelles Repository zu pushen.

In Bezug auf die Deployment-Einstellungen haben wir auch ein Eltern-Pom, wo wir unsere eigenen Repositories in der <distributionManagement> Sektion angegeben haben.

Auf meinen Build-Maschinen habe ich dieses Profil hinzugefügt (in .m2/settings.xml), um die Artefakte cachen:

<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> 

Ich habe andere Einstellungen in dieser Datei eigene Artifactory Repositories zu erklären (zum Schieben/Ziehen unserer eigenen Artefakte) + einige Maven Credentials.

Ich habe einige Tests mit einem unserer Maven-Projekte gemacht und es hat gut funktioniert.

Einmal die neuen .m2/Einstellungen.Xml wird bereit sein, ich werde eine Vorlage in einem internen Artifactory-Repository schieben, so dass die Entwickler diese Vorlage mit einem Curl-Befehl erhalten können.

FYI, das ist ein POC für den Moment. Wir wollen mit diesen Einstellungen in wenigen Tagen in die Produktion gehen.

+0

Ich habe Ihr Motiv nicht wirklich verstanden, ein neues virtuelles Repository einzurichten. Was das Holen betrifft, beobachtete ich, dass wenn man den jcenter nach oben zieht (ich erinnere mich nicht, ob er oben war) im Abschnitt "Virtual> remote-repos", dann wird er automatisch in jcenter-cache gespeichert. Dies löst meine Sorge, von _jcenter_ anstatt von Maven central zu holen. Um die Bereitstellung auf _jcenter_ zu verhindern, kann das Problem behoben sein, wenn das Standardbereitstellungsrepository leer gehalten wird. Was ist, wenn jemand _jcenter_ als Standardbereitstellungspfad in der Datei settings.xml angibt? – Technext

+0

Mein virtueller Repo ist eine Ansammlung von mehreren Remote + einem lokalen Repo. Mit einem einzigen Einstiegspunkt (dem virtuellen Repo) kann ich nur einmal die relevanten Zugangsdaten in meiner settings.xml festlegen. Können Sie das Problem bei der Bereitstellung mithilfe des Artifactory-Berechtigungsmechanismus lösen? Sie können nur einen Lesezugriff für Ihre Benutzer festlegen. Es sollte die Aufgabe erfüllen, Ihr Repo gegen die Bereitstellung zu schützen. –

+0

Ich ging durch [diesen] (https://www.jfrog.com/blog/push-the-limits-of-virtual-repositories-2/) Artikel, was ich denke, dass du sagst. Bitte korrigieren Sie mich, falls ich falsch liege. Wenn ich recht habe, frage ich mich, wie eine _single_ URL dazu dient, sowohl lokale Snapshots als auch lokale Release-Repositories bereitzustellen. Wie kann man unterscheiden, wo das Artefakt eingesetzt wird? Im '' Abschnitt geben wir die Artifactory URL an und hängen entweder 'libs-snapshot-local' oder' libs-release-local' an, aber in diesem Fall bin ich mir nicht sicher. – Technext

Verwandte Themen