porównywanie sbt i Gradle [zamknięte]

Zanurzam się w Scala i zauważyłem kogoś. Byłem całkiem zadowolony z Gradle w projektach java / groovy i wiem, że istnieje wtyczka scala dla Gradle.

Jakie mogą być dobre powody, by faworyzować sbt nad Gradle w projekcie Scala?

Zauważ, że jedną kluczową różnicą między SBT i Gradle jest zarządzanie zależnościami :

• SBT : Ivy , z wersją, która może być podana jako stała (na przykład 1.5.2) lub jako najnowsza (lub dynamiczna).
  Zobacz „ Zależność bluszczu ”
  Oznacza to, że obsługa mechanizmu „-SNAPSHOT” może być problematyczna, mimo że szczegóły Marka Harraha w tym wątku :

To prawda, że ​​pamięć podręczna może się pogubić, ale nie jest prawdą, że Ivy nie rozumie rozwiązywania migawek. Eugene wyjaśnił ten punkt w innym wątku, być może na liście administratorów. Występuje problem z automatyczną aktualizacją SBT, który został rozwiązany w wersji 0.12.

To, czego Ivy nie obsługuje, o ile wiem, to publikowanie migawek w sposób, w jaki robi to Maven. Wydaje mi się, że powiedziałem to gdzie indziej, ale jeśli ktoś chce poprawić sytuację, moim zdaniem najlepiej jest poświęcić wysiłek pracy z zespołem Gradle, aby ponownie wykorzystać ich kod zarządzania zależnościami.

• Gradle : Ten wątek wspomina ( Peter Niederwieser ):

Chciałem tylko poinformować, że problemy z zależnościami migawek Ivy i Mavena były jednym z powodów, dla których Gradle ostatecznie zastąpił Ivy własnym kodem zarządzania zależnościami. To było duże zadanie, ale przyniosło nam wiele dobroci.

Ten tweet wspomina, że ​​cała sytuacja może ewoluować w przyszłości:

Mark powiedział w przeszłości, że był zainteresowany wykorzystaniem Gradle zamiast Ivy do SBT.

(oba narzędzia mogą się od siebie uczyć )

Dla mnie kluczowe cechy SBT to:

• Szybka kompilacja (szybciej niż fsc).
• Ciągła kompilacja / testowanie: polecenie ~testdokona ponownej kompilacji i przetestuje projekt za każdym razem, gdy zapiszesz modyfikację.
• Cross-kompilacja i cross-publishing w kilku wersjach scala.
• Automatyczne pobieranie zależności z poprawną zgodnością wersji Scala.

Wady to:

• Hieroglificzna składnia, która zniechęca nowych użytkowników (zwłaszcza jeśli pochodzą z Javy)
• Nie ma łatwego sposobu na zdefiniowanie „zadania”: jeśli potrzebujesz specjalnej procedury budowania, będziesz musiał albo znaleźć wtyczkę, albo napisać ją samodzielnie.

sbt to Scala DSL i Scala jest obywatelem pierwszej klasy, więc w zasadzie wydaje się, że pasuje.

Jednak sbt cierpi z powodu poważnych niekompatybilnych zmian między wersjami, co utrudnia znalezienie odpowiedniej działającej wtyczki dla zadania i uruchomienie jej.

Osobiście zrezygnowałem z czegoś, ponieważ sprawiało to więcej problemów niż rozwiązało. Właściwie przeszedłem na gradle.

Domyśl.

Jestem dość nowy w gradle i bardzo nowy w sbt - to, co do tej pory naprawdę podoba mi się w sbt, to konsola interaktywna. Pozwala mi na użycie poleceń takich jak „inspekcja”, aby uzyskać lepszy obraz tego, co się dzieje. AFAIK gradle nie zapewnia czegoś takiego jak ten atm.

Sbt i gradle, oba są oparte na statycznie typowanych językach ... ale sbt ma kilka zalet:

• lepsza obsługa wtyczek, szczególnie autopluginy
• tworzenie zadań i zarządzanie zależnościami między zadaniami
• sbt szczególnie pasuje do projektów scala w tym sensie, że obsługuje kompilacje przyrostowe, a większość samego sbt jest napisana w scali, a definicje kompilacji sbt jest napisana w scali
• sbt posiada interakcyjną obsługę powłoki z wieloma użytecznymi wbudowanymi zadaniami
• Domyślny cykl życia sbt jest całkiem przydatny i może rozpocząć nowicjusz przy znacznie mniejszym wysiłku