Comment puis-je obtenir le sbt pour utiliser un référentiel de proxy maven local (Nexus)?

J’ai un projet sbt (Scala) qui extrait actuellement des artefacts du Web. Nous souhaiterions évoluer vers un référentiel Nexus standardisé en entreprise qui mettrait en cache les artefacts. À partir de la documentation de Nexus, je comprends comment faire pour les projets Maven. Mais la sbt utilise évidemment une approche différente. (Je comprends que Ivy est impliquée d’une manière ou d’une autre, mais je ne l’ai jamais utilisée et je ne comprends pas comment cela fonctionne.)

Comment puis-je dire à sbt et / ou à Ivy sous-jacente d’utiliser le système de référentiel d’entreprise Nexus pour toutes les dépendances? J’aimerais que la réponse utilise une sorte de fichier de configuration au niveau du projet, afin que les nouveaux clones de notre référentiel source utilisent automatiquement le proxy. (C’est-à-dire qu’il n’est pas possible de traiter des fichiers de configuration par utilisateur dans un répertoire de points).

Merci!

Étape 1: Suivez les instructions des rubriques détaillées: Référentiels de proxy , que j’ai résumés et ajoutés ci-dessous:

  1. (Si vous utilisez Artifactory, vous pouvez ignorer cette étape.) Créez un référentiel (ou groupe) de proxy Maven entièrement distinct sur votre référentiel Maven d’entreprise, afin de protéger les référentiels de type ivy tels que ces deux éléments importants:

    Cela est nécessaire car certains gestionnaires de référentiels ne peuvent pas gérer des référentiels de style Ivy et de style Maven mélangés.

  2. Créez un repositories fichiers, en répertoriant à la fois votre référentiel d’entreprise principal et tous les référentiels que vous avez créés à l’étape 1, au format indiqué ci-dessous:

     [repositories] my-maven-proxy-releases: http://repo.example.com/maven-releases/ my-ivy-proxy-releases: http://repo.example.com/ivy-releases/, [organization]/[module]/(scala_[scalaVersion]/)(sbt_[sbtVersion]/)[revision]/[type]s/[artifact](-[classifier]).[ext] 
  3. Enregistrez le fichier dans le répertoire .sbt votre répertoire personnel ou spécifiez-le sur la ligne de commande sbt:

     sbt -Dsbt.repository.config= 

Bonne nouvelle pour ceux qui utilisent d’anciennes versions de sbt : Même si, au moins dans le lanceur sbt 0.12.0, les fichiers de propriétés de démarrage des anciennes versions de sbt ne contiennent pas la ligne requirejse (celle qui mentionne repository.config ), elle travaillera toujours pour ces versions de sbt si vous éditez ces fichiers pour append la ligne requirejse, et les reconditionner dans le jar de lanceur de sbt 0.12.0! C’est parce que la fonctionnalité est implémentée dans le lanceur, pas dans sbt lui-même. Et le lanceur sbt 0.12.0 est censé être capable de lancer toutes les versions de sbt, de retour à 0.7!

Étape 2: Pour vous assurer que les référentiels externes ne sont pas utilisés, supprimez les référentiels par défaut de vos résolveurs. Cela peut être fait de deux manières:

  1. Ajoutez l’option de ligne de commande -Dsbt.override.build.repos=true mentionnée sur la page des rubriques détaillées ci-dessus. Cela entraînera les référentiels que vous avez spécifiés dans le fichier pour remplacer tous les référentiels spécifiés dans l’un de vos fichiers sbt. Cela ne fonctionnera peut-être que dans sbt 0.12 et plus – je ne l’ai pas encore essayé.
  2. Utilisez fullResolvers := Seq( résolveur (s) pour vos référentiels Maven d’entreprise ) dans vos fichiers de génération, au lieu de resolvers ++= ou des resolvers := ou tout ce que vous utilisiez auparavant.

OK, avec l’aide de Mark Harrah sur la liste de diffusion sbt, j’ai une réponse qui fonctionne.

Ma classe de construction ressemble maintenant à la suivante (plus quelques autres repos):

 import sbt._ //By extending DefaultWebProject, we get Jetty support class OurApplication(info: ProjectInfo) extends DefaultWebProject(info) { // This skips adding the default repositories and only uses the ones you added // explicitly. --Mark Harrah override def repositories = Set("OurNexus" at "http://our.nexus.server:9001/nexus/content/groups/public/") override def ivyRepositories = Seq(Resolver.defaultLocal(None)) ++ repositories /* Squeryl */ val squeryl = "org.squeryl" % "squeryl_2.8.0.RC3" % "0.9.4beta5" /* DATE4J */ val date4j = "hirondelle.date4j" % "date4j" % "1.0" from "http://www.date4j.net/date4j.jar" // etc } 

Maintenant, si je supprime l’arborescence Squeryl du .ivy2/cache de ma machine, sbt essaie de le récupérer dans l’arborescence Nexus avec l’URL appropriée. Problème résolu!

Il vous suffit de définir un fichier de propriétés sbt.boot.properties qui vous permettra de:

  • redéfinir l’emplacement du cache de lierre (j’en ai besoin car cela ferait partie de notre profil Windows en itinérance , qui est très limité en termes d’espace disque dans notre boutique. Voir le numéro 74 )
  • définir tout autre repo Maven que vous voulez
     C: \ HOMEWARE \ apps \ sbt-0.74 \ sbt.boot.properties

     [scala]
       version: 2.7.7
     # classificateurs: sources, javadoc

     [app]
       org: org.scala-tools.sbt
       nom: sbt
       version: read (sbt.version)
       classe: sbt.xMain
       composants: xsbti
       version croisée: true
       classificateurs: sources, javadoc

     [repositorys]
       local
       mon-lien: http://my.nexus/nexus/content/repositories/scala-tools/, [organisation] / [module] / [révision] / [type] s / [artefact] (- [classificateur]). [ext]
       maven-local
     # sbt-db: http://databinder.net/repo/, [organisation] / [module] / [révision] / [type] s / [artefact] (- [classificateur]). [ext]
     # maven-central
     # scala-tools-releases
     # scala-tools-snapshots

     [démarrage]
      répertoire: projet / boot
      Propriétés: project / build.properties
      prompt-create: le projet n'existe pas, créer un nouveau projet?
      prompt-fill: true
      option rapide: vrai

     [bûche]
      niveau: debug

     [app-propriétés]
      project.name: quick = set (test), new = prompt (Nom) [p], fill = prompt (Nom)
      project.organization: new = prompt (Organization) [org.vonc]
      project.version: quick = set (1.0), new = prompt (Version) [1.0], fill = prompt (Version) [1.0]
      build.scala.versions: quick = set (2.8.0.RC2), new = prompt (version Scala) [2.8.0.RC2], fill = prompt (version Scala) [2.8.0.RC2]
      sbt.version: quick = set (0.7.4), new = prompt (version sbt) [0.7.4], fill = prompt (version sbt) [0.7.4]
      project.scratch: quick = set (true)
      project.initialize: quick = set (true), new = set (true)

     [lierre]
      cache-directory: C: \ HOMEWARE \ projects \ .ivy2 \ cache

Remarque: ce fichier sbt.boot.properties est inspiré de:

  • celle mentionnée dans la page “Lanceur généralisé” du projet sbt .
  • celui trouvé dans sbt-0.74 lui sbt-0.74 même!

J’ai commenté une définition de référentiel Maven externe et ajouté une référence à mon propre référentiel Nexus Maven.

Le lanceur peut être configuré de l’une des manières suivantes en ordre croissant de priorité:

  • Remplacez le fichier /sbt/sbt.boot.properties dans le fichier jar .
  • Placez un fichier de configuration nommé sbt.boot.properties sur le sbt.boot.properties de sbt.boot.properties . Placez-le dans la racine du chemin de classe sans le préfixe /sbt .
  • Spécifiez l’emplacement d’une autre configuration sur la ligne de commande. Cela peut être fait par:
    • soit en spécifiant l’emplacement en tant que propriété système sbt.boot.properties
    • ou comme premier argument du lanceur préfixé par ‘ @ ‘.

La propriété système a une priorité inférieure.
La résolution d’un chemin relatif est:

  • d’abord tenté contre le répertoire de travail en cours,
  • puis contre le répertoire personnel de l’utilisateur,
  • puis contre le répertoire contenant le pot lanceur.

Une erreur est générée si aucune de ces tentatives n’aboutit.


Définissez un wrapper sbt.bat (pour être sûr de spécifier votre sbt.boot.properties ) comme:

 C:\HOMEWARE>more C:\HOMEWARE\bin\sbt.BAT @echo off set t=%~dp0 set adp0=%t:C:\="%" set SBT_DIR=%adp0%..\apps\sbt-0.74 dir C:\%SBT_DIR%\sbt-launch-0.7.4.jar # if needed, add your proxy settings set PROXY_OPTIONS=-Dhttp.proxyHost=my.proxy -Dhttp.proxyPort=80xx -Dhttp.proxyUser=auser -Dhttp.proxyPassword=yyyy set JAVA_OPTIONS=-XX:+CMSClassUnloadingEnabled -XX:MaxPermSize=256m -Xmx512M -cp C:\HOMEWARE\apps\sbt-0.74\sbt-launch-0.7.4 set SBT_BOOT_PROPERTIES=-Dsbt.boot.properties="sbt.boot.properties" cmd /CC:\HOMEWARE\apps\jdk4eclipse\bin\java.exe %PROXY_OPTIONS% %JAVA_OPTIONS% %SBT_BOOT_PROPERTIES% -jar C:\HOMEWARE\apps\sbt-0.74\sbt-launch-0.7.4.jar %* 

Et votre sbt téléchargera des artefacts uniquement à partir de:

  • votre Nexus
  • votre repo Maven local.

Juste testé à la maison avec un vieux Nexus opensource 1.6, j’avais en cours d’exécution, java 1.6, sbt07.4

 C:\Prog\Java\jdk1.6.0_18\jre\bin\java -Xmx512M -Dsbt.boot.properties=sbt.boot.properties - jar "c:\Prog\Scala\sbt\sbt-launch-0.7.4.jar" 

Ça donne:

 [success] Build completed successfully. C:\Prog\Scala\tests\pp>sbt Getting Scala 2.8.0 ... downloading http://localhost:8081/nexus/content/repositories/scala/org/scala-lang/scala-comstackr/2.8.0/scala-comstackr-2. 8.0.jar ... [SUCCESSFUL ] org.scala-lang#scala-comstackr;2.8.0!scala-comstackr.jar (311ms) downloading http://localhost:8081/nexus/content/repositories/scala/org/scala-lang/scala-library/2.8.0/scala-library-2.8. 0.jar ... [SUCCESSFUL ] org.scala-lang#scala-library;2.8.0!scala-library.jar (185ms) :: resortingeving :: org.scala-tools.sbt#boot-scala confs: [default] 2 artifacts copied, 0 already resortingeved (14484kB/167ms) [info] Building project test 0.1 against Scala 2.8.0 [info] using sbt.DefaultProject with sbt 0.7.4 and Scala 2.7.7 

Si j’essaie une valeur amusante dans le fichier sbt.boot.properties:

 C:\Prog\Scala\tests\pp>sbt Getting Scala 2.9.7 ... :: problems summary :: :::: WARNINGS module not found: org.scala-lang#scala-comstackr;2.9.7 ==== nexus: sortinged http://localhost:8081/nexus/content/repositories/scala/org/scala-lang/scala-comstackr/2.9.7/scala-comstackr-2.9.7.pom -- artifact org.scala-lang#scala-comstackr;2.9.7!scala-comstackr.jar: http://localhost:8081/nexus/content/repositories/scala/org/scala-lang/scala-comstackr/2.9.7/scala-comstackr-2.9.7.jar 

Donc, il se limite aux deux repo que j’ai définies:

 [repositories] nexus: http://localhost:8081/nexus/content/repositories/scala nexus2: http://localhost:8081/nexus/content/repositories/scala, [organization]/[module]/[revision]/[type]s/[artifact](-[classifier]).[ext] 

(J’ai tout commenté: local , maven-local , …)

Si je commente tous les référentiels et mets une valeur amusante (2.7.9) pour la version scala dans sbt.boot.properties , j’obtiens (comme le fait l’OP)

 C:\Prog\Scala\tests\pp>sbt Error during sbt execution: No repositories defined. 

Si je mets 2.7.7 (tout en ayant toujours des repo commentés), oui, cela ne génèrera pas d’erreur:

 C:\Prog\Scala\tests\pp>sbt [info] Building project test 0.1 against Scala 2.8.0 [info] using sbt.DefaultProject with sbt 0.7.4 and Scala 2.7.7 

Mais c’est seulement parce qu’il avait déjà téléchargé scala2.8.0 lors de mes essais précédents.
Si je supprime cette bibliothèque de mon répertoire project/boot , elle lancera une exception:

 [info] using sbt.DefaultProject with sbt 0.7.4 and Scala 2.7.7 > C:\Prog\Scala\tests\pp>sbt Error during sbt execution: No repositories defined. at xsbt.boot.Pre$.error(Pre.scala:18) at xsbt.boot.Update.addResolvers(Update.scala:197) ... at xsbt.boot.Boot$.main(Boot.scala:15) at xsbt.boot.Boot.main(Boot.scala) Error loading project: Error during sbt execution: No repositories defined. 

Eh bien, cela m’a fait boguer pendant un certain temps alors j’ai trouvé un mec qui a écrit un plugin SBT pour maven sur github appelé maven-sbt donc tout ce que vous avez à faire est de l’inclure dans votre projet plugin et toutes vos opérations comme la mise à jour et la publication locale fonctionnent avec votre maven local. La bonne chose à ce sujet est que si vous êtes comme moi, votre org est tout. Donc, toutes les librairies sont dans votre repo local, mais si pour une raison quelconque vous construisez d’abord avec sbt, alors vous commencez à avoir un tas de bocaux en lierre. Quelle perte d’espace et de temps puisque vous aurez encore besoin de les récupérer pour vos constructions de maven.

Cela dit, je souhaite que cela soit intégré à Sbt, donc je n’aurais pas besoin de l’append à chaque projet. Peut-être en tant que processeur au moins. Il a mentionné dans une chose que je lisais qu’il aimerait l’append à 0,9 mais je n’ai pas pu le trouver.

éditer le fichier de configuration dans sbt_home / conf “sbtconfig.txt”

append deux lignes

 -Dsbt.override.build.repos=true -Dsbt.repository.config="C:/Program Files (x86)/sbt/conf/repo.properties" 

le contenu repo.properties est

 [repositories] local public: http://222.vvfox.com/public <-fix this ,write your local nexus group url 

J’ai eu cette erreur parce que j’avais un fichier vide dans ~/.sbt/repositories . L’ajout de référentiels au fichier et la suppression du fichier ont résolu le problème.