2014-08-31 14 views
8

Ho incontrato un paio di casi correlati con SBT che mi hanno bloccato. C'è un modo per dire a SBT di saltare un sottoprogetto interamente per certe versioni di scala quando si esegue una compilazione incrociata?Come fare a SBT per saltare la compilazione incrociata per un determinato sottoprogetto?

Ecco due esempi in cui sarebbe utile.

1) Una build con tre progetti A, B e C. Entrambi A e B sono progetti scala e hanno 'scalaVersions ++ = Seq ("2.11.2", "2.10.4") nelle relative impostazioni . Project C è un artefatto puramente Java, e quindi ho escluso le librerie Scala dalle sue dipendenze. Mi piacerebbe che A e B dipendessero da C, ma idealmente mi piacerebbe solo costruire C una sola volta. Se utilizzo il comportamento predefinito e faccio "+ publish" dal progetto di aggregatore radice, ottengo due copie di C-1.0.0.jar prodotte, e SBT tenta di pubblicarlo due volte, che è ovviamente un no-no per un repository maven.

2) Una build con più progetti scala, ma dove un progetto dovrebbe essere costruito solo su una singola versione di Scala. Ho provato a definire 'scalaVersions' nelle impostazioni per questo progetto per contenere solo una versione in cui gli altri progetti ne hanno due, ma ancora una volta "+ publish" da un aggregatore radice sembra ignorarlo e compila ancora due volte, con la seconda volta in mancanza perché le dipendenze non sono disponibili per quella versione di Scala. Questo progetto è un nodo foglia nel grafico delle dipendenze, quindi è una cosa perfetta da voler fare logicamente.

Per il caso n. 2, ho pensato di impostare le dirs di origine per la versione "cattiva" scala su/dev/null o qualcosa di simile, ma che comunque esegue effettivamente la build e produce un artefatto vuoto. So che probabilmente potrei andare e trovare tutte le chiavi rilevanti e fare qualcosa di simile

publishArtifact := if(scalaBinaryVersion.value == "2.10") false else publishArtifact.value 

e poi dare la caccia a tutte le altre impostazioni relative/compiti (compilare, compilare in prova, prova nella prova, packageBin, ecc.) ma sembra piuttosto un hack-ish. C'è un "salto" ambientato da qualche parte?

risposta

4

Ho scritto sbt-doge per indirizzare l'aggregazione delle attività tra i sottoprogetti rispettando le loro crossScalaVersions. Per i progetti Java potrebbe essere necessaria una voce fittizia crossScalaVersion.

+0

Questo sembra estremamente utile, ma sono francamente dispiaciuto di aggiungere "così tanto test" e così alla mia build: -/ –

+0

E ho perso totalmente l'alternativa "sensata" in 0.1.4. Le mie scuse, signore! Funziona come un fascino! –

+0

@Tomer a quali test e "alternative sensibili" ti riferisci? – matanster

1

Il plug-in sbt-doge può essere utilizzato per specificare un'impostazione crossScalaVersion in ciascun sottoprogetto.

Innanzitutto, aggiungere la riga addSbtPlugin("com.eed3si9n" % "sbt-doge" % "0.1.5") al numero projects/plugins.sbt.

Per evitare la riduttiva sintassi del doge ("tale compilazione", davvero?) È necessario enablePlugins(CrossPerProjectPlugin) nel progetto root. Con questo, è possibile aggiungere un segno più prima dei comandi sbt e onoreranno le impostazioni di cross-build. Proprio così: + compile.

Problemi correlati