[scala] moduły czy mini projekty?

Dalej męczę ten projekt do robienia rankingu języków programowania w oparciu ogłoszenia o prace. Obsługuję już 62 stronki.

Jakie są dobre praktyki dzielenia całego projektu na mniejsze części w scali? Lepiej robić moduły tak jak pokazane tutaj: https://github.com/pbassiner/sbt-multi-project-example
czy lepiej zrobić osobne projekty, które używają siebie nawzajem poprzez dependency?

mam tak o:

└───tech-ranking-root (io, domain, api) 
    ├───tech-ranking-countries (scrappers, extractors)
    ├───tech-ranking-hosts (scrappers, extractors)
    ├───tech-ranking-jobs (scrappers, extractors

tech-ranking-root miałoby klasy wspólne
tech-ranking-countries do scrapowania państw, ich kodów iso i języków urzędowych
tech-ranking-hosts do scrapowania hostów po których można śmigać
tech-ranking-jobs do scrapowania ogłoszeń

odpalanie:
na żądanie java --jar tech-ranking-countries[...].jar
usługa co miesiąc java --jar tech-ranking-hosts[...].jar
usługa co tydzień java --jar tech-ranking-jobs[...].jar

dlatego chcę mieć to osobno

Pytanie trochę bez sensu bo multiproject który podlinkowałeś to są właśnie osobne projekty wzajemnie się używające, tylko że mają wspólny plik sbt

to zrobiłem tak samo. Wygodny ten sbt, znacznie bardziej od mavena.

Dostaję taką strukturę:

└───tech-ranking 
    ├───project
        ├───target
    ├───target
        ├───target
        ├───tech-ranking-countries-target
        ├───tech-ranking-hosts-target
        ├───tech-ranking-jobs-target
    ├───tech-ranking-countries
        ├───src
    ├───tech-ranking-hosts
        ├───src
    ├───tech-ranking-jobs
        ├───src

za pomocą:

name := "tech-ranking"
version in ThisBuild := "0.0.0-SNAPSHOT"
organization in ThisBuild := "com.julian"
scalaVersion in ThisBuild := "2.12.3"
target := baseDirectory.value / "target" / "target"

// projects -------------------------------------------------------------------

lazy val global = project
  .in(file("."))
  .settings(settings)
  .aggregate(
    root,
    ads,
    countries,
    hosts
  )

lazy val root = (project in file("tech-ranking-root"))
  .settings(
    name := "tech-ranking-root",
    settings,
    libraryDependencies ++= commonDependencies,
	target := baseDirectory.value / ".." / "target" / "tech-ranking-root-target"
  )

lazy val ads = (project in file("tech-ranking-ads"))
  .settings(
    name := "tech-ranking-ads",
    settings,
    libraryDependencies ++= commonDependencies,
	target := baseDirectory.value / ".." / "target" / "tech-ranking-ads-target"
  )
  .dependsOn(
    root
  )
  
lazy val countries = (project in file("tech-ranking-countries"))
  .settings(
    name := "tech-ranking-countries",
    settings,
    libraryDependencies ++= commonDependencies,
	target := baseDirectory.value / ".." / "target" / "tech-ranking-countries-target"
  )
  .dependsOn(
    root
  )

lazy val hosts = (project in file("tech-ranking-hosts"))
  .settings(
    name := "tech-ranking-hosts",
    settings,
    libraryDependencies ++= commonDependencies,
	target := baseDirectory.value / ".." / "target" / "tech-ranking-hosts-target"
  )
  .dependsOn(
    root
  )

// ...

Zastanawiam się jak przerzucić project/target do target/project

Chcesz żeby koledzy rzucali w ciebie obelgami czy po prostu tymczasowo uczysz się SBTa i zaorasz niedługo ten projekt? https://en.wikipedia.org/wiki/Convention_over_configuration jest OK, po co to psuć?

Dla bardzo ciekawskich:

Zastanawiam się jak przerzucić project/target do target/project

Jeżeli to tylko w celach edukacyjnych to zgodnie z https://www.scala-sbt.org/1.x/docs/Organizing-Build.html ustawienia musisz wstawić do pliku project/cośtam.sbt, a nie do cośtam.sbt w katalogu głównym projektu (zamiast cośtam.sbt można wstawić np build.sbt - wszystkie pliki *.sbt w danym folderze są traktowane tak samo).