web-dev-qa-db-fra.com

comment obtenir sbt d'utiliser un référentiel de proxy maven local (Nexus)?

J'ai un projet sbt (Scala) qui extrait actuellement des artefacts du Web. Nous aimerions évoluer vers un référentiel Nexus normalisé par l’entreprise qui mettrait en cache les artefacts. D'après la documentation de Nexus, je comprends comment procéder pour les projets Maven. Mais 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-jacent 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 que fouiller avec des fichiers de configuration par utilisateur dans un répertoire de points n'est pas viable.) 

Merci!

scalamavenivynexussbt
69
Harlan

Étape 1: Suivez les instructions de la section Rubriques détaillées: Référentiels de proxy , que j'ai résumées et ajoutées ci-dessous:

  1. (Si vous utilisez Artifactory, vous pouvez ignorer cette étape.) Créez un référentiel (ou groupe) de proxy entièrement séparé sur votre référentiel d'entreprise Maven, pour créer un proxy style de lierre des référentiels tels que ces deux importants:

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

  2. Créez un fichier repositories, répertoriant à la fois votre référentiel d'entreprise principal et tout dossier supplémentaire créé à l'étape 1, dans le 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 ce fichier dans le répertoire .sbt situé dans votre répertoire personnel ou indiquez-le sur la ligne de commande sbt:

    sbt -Dsbt.repository.config=<path-to-your-repo-file>

Bonne nouvelle pour ceux qui utilisent des versions plus anciennes de sbt : Même si, dans le fichier de lancement de sbt 0.12.0 au moins, les fichiers de propriétés de démarrage des versions plus anciennes de sbt ne contient pas la ligne requise (celle qui mentionne repository.config), cela fonctionnera toujours pour ces versions de sbt si vous éditez ces fichiers pour ajouter la ligne requise et les reconditionnez dans le fichier jar de lancement de sbt 0.12.0 ! En effet, la fonctionnalité est implémentée dans le lanceur, pas dans sbt elle-même. Et le lanceur sbt 0.12.0 est censé pouvoir lancer toutes les versions de sbt, de nouveau à 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 dans la page Rubriques détaillées ci-dessus. Les référentiels que vous avez spécifiés dans le fichier se substitueront à ceux spécifiés dans l'un de vos fichiers sbt. Cela pourrait ne fonctionner que dans les versions 0,12 et plus, mais je ne l’ai pas encore essayé.
  2. Utilisez fullResolvers := Seq(résolveur (s) pour les référentiels maven de votre entreprise) dans vos fichiers de construction, au lieu de resolvers ++= ou resolvers := ou de ce que vous utilisiez auparavant. utilisation.
32
Robin Green

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 pensions):

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’arbre Squeryl du répertoire .ivy2/cache de ma machine, sbt tente de le récupérer à partir de l’arbre Nexus avec l’URL appropriée. Problème résolu!

12
Harlan

Tout ce dont vous avez besoin est de définir un fichier de propriétés sbt.boot.properties qui vous permettra de:

  • redéfinissez l'emplacement de la cache ivy (j'ai besoin de cela car il ferait sinon partie de notre profil Windows itinérant , qui est très limité en espace disque dans notre boutique. Voir numéro 74 )
  • définir n'importe quel 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 

 [référentiels] 
 local
 mes-liens: 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: projet/build.properties 
 Invite-créer: le projet n'existe pas, créer un nouveau projet? 
 Remplissage rapide: vrai 
 option rapide: vrai 

 [bûche]
 niveau: debug 

 [app-properties] 
 project.name: quick = set (test), new = Invite (Nom) [p], remplissage = Invite (Nom) 
 project.organization: new = Invite (Organisation) [org.vonc] 
 project.version: quick = set (1.0), new = Invite (Version) [1.0], fill = Invite (Version) [1.0] 
 build.scala.versions: quick = set (2.8.0.RC2), new = Invite (version Scala) [2.8.0.RC2], fill = Invite (version Scala) [2.8.0.RC2] 
 sbt.version: quick = set (0.7.4), new = Invite (version sbt) [0.7.4], fill = Invite (version sbt) [0.7.4] 
 project.scratch: quick = set (true) 
 project.initialize: quick = set (true), new = set (true) 

 [lierre]
 répertoire de cache: C:\HOMEWARE\projects\.ivy2\cache

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

J'ai commenté toute 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 par ordre croissant de priorité:

  • Remplacez le fichier /sbt/sbt.boot.properties dans la jar.
  • Placez un fichier de configuration nommé sbt.boot.properties sur le chemin de classe. 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:

  • première tentative sur le répertoire de travail en cours, 
  • puis contre le répertoire personnel de l'utilisateur, 
  • puis contre le répertoire contenant le pot de lancement. 

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 votresbt.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 /C C:\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 les artefacts uniquement à partir de:

  • votre Nexus
  • votre dépôt Maven local.

Vient de tester à la maison avec un ancien Nexus opensource 1.6 que 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-compiler/2.8.0/scala-compiler-2.
8.0.jar ...
        [SUCCESSFUL ] org.scala-lang#scala-compiler;2.8.0!scala-compiler.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)
:: retrieving :: org.scala-tools.sbt#boot-scala
        confs: [default]
        2 artifacts copied, 0 already retrieved (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-compiler;2.9.7
        ==== nexus: tried
          http://localhost:8081/nexus/content/repositories/scala/org/scala-lang/scala-compiler/2.9.7/scala-compiler-2.9.7.pom
          -- artifact org.scala-lang#scala-compiler;2.9.7!scala-compiler.jar:
          http://localhost:8081/nexus/content/repositories/scala/org/scala-lang/scala-compiler/2.9.7/scala-compiler-2.9.7.jar

Donc, il se limite aux deux repo que j'ai définis:

[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 commenté tout le reste: local, maven-local, ...)

Si je commente tous référentiels et que je mets une valeur amusante (2.7.9) pour la version scala dans le sbt.boot.properties, je reçois (comme l'OP l'a fait)

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

Si je mets 2.7.7 (tout en ayant toujours tout repo commenté), 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 ce n'est que parce qu'il avait déjà téléchargé scala2.8.0 lors de mes tentatives précédentes.
Si je supprime cette bibliothèque de mon répertoire project/boot, alors une exception se produira:

[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.
9
VonC

éditez le fichier de configuration dans sbt_home/conf "sbtconfig.txt"

ajouter 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
6
foxundermon

Cela m’a énervé pendant un moment et j’ai trouvé un gars qui a écrit un plugin SBT pour maven sur github appelé maven-sbt il ne vous reste plus qu’à l’inclure dans votre projet de plugins et à le mélanger. avec maven.MavenDependencies et toutes vos opérations comme la mise à jour et la publication en local avec votre maven local. La bonne chose à ce sujet est que si vous êtes comme moi, votre organisation est toute maven. Ainsi, toutes vos bibliothèques sont dans votre dépôt principal local mais si, pour une raison quelconque, vous construisez d'abord avec sbt, vous commencez également à recevoir un paquet ou des bocaux en lierre. Quel gaspillage d’espace et de temps puisque vous aurez toujours besoin de les obtenir pour vos constructions maven.

Cela dit, je souhaite que cela soit intégré à sbt afin de ne pas avoir à l’ajouter à chaque projet. Peut-être en tant que processeur au moins. Il a mentionné dans une chose que j'ai lue qu'il aimerait l'ajouter à 0.9 mais que je n'ai pas pu le trouver.

5
ozone

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

0
mehtunguh