2015-04-17 5 views
0

Я использую sbt 0.13.7.Как использовать источники из другого подпроекта в пользовательской задаче?

Я думаю, мой вопрос немного похож на this one. Однако у меня есть многопроектная сборка.

Скажем, моя структура проекта выглядит следующим образом:

- A 
    - build.sbt 
- B 
    - build.sbt 
build.sbt 

и B.dependsOn(A).

Есть ли способ написать пользовательскую задачу в build.sbt в B, которая использует источники от A?

+0

Вы должны 'B.aggregate (A)'? http://www.scala-sbt.org/0.12.2/docs/Getting-Started/Multi-Project.html#aggregation – ipoteka

+0

'aggregate' - позволить командам/задачам выполняться в проектах, указанных как агрегированные. Он не устанавливает зависимость класса. См. [Агрегация] (http://www.scala-sbt.org/0.13/tutorial/Multi-Project.html#Aggregation) в официальных документах. –

ответ

3

Предполагая, что A и B полностью отделенны строит (это не только multi-project build, как у вас есть несколько .sbt файлов), это возможно, только если A сборка физически находятся внутри B.


1) Если вам нужен A-источники будут доступны для B-источников:

- B 
    - build.sbt 
    - A 
    - build.sbt 
build.sbt 

, то вы можете описать A 's источники в некоторой регулярной B' проекта s, как:

Б/build.sbt

lazy val a = project in "./A" // or deeply if your sources not in A's root 

lazy val b = project in "." dependsOn a 

B/A/build.sbt (если вам действительно нужно отдельное строение здесь)

lazy val a = project in "." 

Вы можете захотеть поделиться плагин с исходным путем-независимым определением проекта между A и B затем, как:

def a(base: String) = Project(base = base, settings = someAsettings) 

Вы можете организовать такую ​​структуру с линком (Linux/Mac):

ln -s ../B A 

Othe rwise вам нужно вручную опубликовать A (publishLocal) в локальный репозиторий плюща и использовать его как внешнюю зависимость.

Если вы используете ссылки Git - symlinks, должны be fine, если участники используют ту же ОС. Другим решением является git submodules или subtree.


2) Если вам нужен код из-источников должны быть доступны внутри B-сборки (не B-источников), то вам нужна структура вроде этого:

- B 
    - build.sbt 
    - project 
    - project 
     - A 
    build.sbt 

проект внутри проекта на самом деле становится sbt-плагином, поэтому его код доступен для B.

Если вы не хотите менять структуру, то A должен стать sbt-plugin, и вам необходимо опубликовать его в локальном репозитории.

+0

Я понимаю. Мне нравится альтернатива. Лучше, но все равно немного неловко вложить ее в это, вероятно, вместо этого вместо пули будет использоваться внешняя зависимость. Этого я пытался избежать, потому что тогда мне нужно выпустить проект 'A' каждый раз, прежде чем изменения будут отражены в' B'. – reikje

0

Как насчет следующего в build.sbt в корневом проекте верхнего уровня?

lazy val a = project 
lazy val b = project 

lazy val printSources = taskKey[Unit]("Prints the sources of A") 
printSources := { 
    println("== sources of A ==") 
    (sources in (a, Compile)).value.foreach(println) 
} 

Выполнить задачу printSources и вы должны увидеть следующее:

[multi-sbt-project]> printSources 
== sources of A == 
/Users/jacek/dev/sandbox/multi-sbt-project/a/hello.scala 
[success] Total time: 0 s, completed Apr 18, 2015 11:26:54 AM 
+0

это копировать источники 'A' в' B'? – reikje

Смежные вопросы