porównywanie sbt i Gradle [zamknięte]


110

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?


SBT w pewnym sensie jest jak Vim: jeśli go oszukasz, będziesz zadowolony. A tak przy okazji, jest też maven i lein (został stworzony do ubrań, ale działa też z łuską).
om-nom-nom

18
Nie czuj presji, aby przejść na SBT. Niektórzy znani członkowie społeczności Scala używają Gradle. Zamiast tego użyj SBT jako eksperymentu, wiedząc, że zamiast tego możesz po prostu użyć Gradle.
Daniel C. Sobral

6
dzięki wszystkim ... Przeczytawszy twoje spostrzeżenia, zostanę przy Gradle. Wydaje mi się, że właśnie tam będzie znajdować się większość działań związanych z narzędziami do budowania przestrzeni JVM, gdy zostawimy Mavena w tyle.
Hans Westerbeek

10
Irytujące jest to, że to pytanie jest tutaj oznaczane jako „oparte na opiniach”, prawdopodobnie przez ludzi, którzy nie pracują w przestrzeni JVM przez cały czas (i przez to nie mają nadzoru). Poniższe odpowiedzi są oparte na faktach i pozbawione świętej wojny.
Hans Westerbeek,

4
Nie, te odpowiedzi to przede wszystkim stwierdzenia weryfikowalnych faktów, a nie opinie. Chociaż na to pytanie można uzyskać nieprzydatne odpowiedzi, w rzeczywistości tak się nie stało. Powinien pozostać otwarty jako użyteczny opis rzeczywistych różnic między narzędziami.
erickson

Odpowiedzi:


61

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.

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ć )


1
Największą niedogodnością, jaką kiedykolwiek spotkałem, jest to, że nie można określić reguły, aby nie rekompilować ponownie za każdym razem, gdy jest wspomniana. Wbudowane reguły dla java i scala mają tę funkcjonalność, ale nie są ujawniane do pisania reguł niestandardowych. Tak więc za każdym razem, gdy generujesz plik programu lub dokumentację, a nawet jeśli generujesz plik jar, zadanie będzie wykonywane przy każdym wywołaniu, niezależnie od jakichkolwiek zmian w źródłach. Nawet marka jest wystarczająco sprytna, ale nie sbt
ayvango

1
@ayvango Obecnie sbt tak nie jest. Istnieje wiele wtyczek, które wykorzystują tę funkcjonalność, np. Android-sdk-plugin
dant3

Czy wiesz, jakie API jest używane do tej funkcji?
ayvango

więc jest to coś, czego brakuje bluszczowi w porównaniu z maven i gradle? To dziwne
tribbloid

53

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.

Czy mam rację, że istnieje / była potrzeba funkcji cross-kompilacji / publikowania z powodu problemów, jakie Scala miał z niekompatybilnością wsteczną plików binarnych?
Hans Westerbeek

1
Tak. I te problemy mogą się powtórzyć po przejściu do Scali 2.10.
paradygmatyczny

1
Są jeszcze dwie różnice, które dodam: * W SBT łatwiej jest samodzielnie zarządzać zależnościami, IMO. * Biegacz testowy SBT wydaje się szybszy; Podejrzewam, że w grę wchodzi sprytna współbieżność, ale zgaduję. SBT wydaje się bardziej zdolnym, ale raczej mniej dojrzałym produktem.
Rick-777

25
+1 za wadę „składni hieroglificznej”. To mój największy problem z SBT. Przeciążenie operatora zawsze prowadzi do nadużyć: - /
Ron Dahlgren

7
Tajemnicza składnia SBT wydobywa to, co najgorsze w scali. Gradle jest oparty na dobrze przemyślanym modelu domeny i prostej składni.
nemoo

40

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.


2
O ile wiem, była tylko jedna bardzo duża zmiana: kiedy sbt zmienił się z 0,7.x na 0,1.x
om-nom-nom

1
Jeśli używasz wtyczki dla sbt 0.11.2, a następnie przechodzisz do sbt 0.12, musisz poczekać, aż autor wtyczki skompiluje nową wersję lub zrobić to sam. idea-sbt jest jednym z przykładów.
fmpwizard

4
@fmpwizard Linia sbt 0.12 nie została jeszcze wydana ... Przestań rozpowszechniać FUD.
paradygmatyczny

3
To nie jest coś, czego nie można użyć, nasz zespół z niego korzysta. Ale mój komentarz miał na celu wsparcie tej odpowiedzi, która brzmiała: "... Ale coś cierpi z powodu poważnych niekompatybilnych zmian między wersjami, co utrudnia znalezienie odpowiedniej działającej wtyczki dla zadania i uruchomienie jej ..." Jak zauważyłeś , Nie mogę po prostu użyć wtyczki scct, musiałem ją zmodyfikować (tak mała zmiana, ale potem musiałem ją gdzieś opublikować, aby cały mój zespół miał do niej dostęp) Ból bez powodu.
fmpwizard

3
Czy jesteś w stanie wykonać kompilację krzyżową dla różnych wersji Scali za pomocą gradle?
Machisuji

4

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.


-11

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

1
Gradle jest oparty na groovy, który nie jest językiem typowanym statycznie.
Vistritium

Gradle zarządza zależnościami między zadaniami, tworzenie zadań jest tak proste, jak to tylko możliwe, nie mam pojęcia, jak łatwiej jest napisać wtyczkę niż dla gradle, który może mieć wtyczki groovy, Java, gradle i być może więcej.
Johnride,
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.