comparando sbt e Gradle [fechado]

110

Estou mergulhando em Scala e notei sbt. Tenho ficado muito feliz com o Gradle em projetos java / groovy e sei que existe um plugin scala para Gradle.

Quais poderiam ser boas razões para favorecer o sbt em vez do Gradle em um projeto Scala?

scala sbt gradle

— Hans Westerbeek
fonte

O SBT, em certo sentido, é como um Vim: se você grocá-lo, ficará satisfeito. E por falar nisso, também há maven e lein (foi criado para clojure, mas funciona com scala também).

— om-nom-nom

18

Não se sinta pressionado a mudar para o SBT. Alguns membros bem conhecidos da comunidade Scala usam o Gradle. Em vez disso, use o SBT como um experimento, sabendo que você pode apenas usar o Gradle.

— Daniel C. Sobral

6

Obrigado a todos ... Depois de ler seus insights, vou ficar com o Gradle. Parece-me que é aí que a maioria dos esforços de ferramentas de construção para o espaço da JVM estarão, conforme deixarmos o Maven para trás.

— Hans Westerbeek

10

É irritante que esta questão esteja sendo marcada como 'baseada em opinião' aqui, provavelmente por pessoas que não trabalham no espaço da JVM o tempo todo (e, portanto, não têm supervisão). As respostas abaixo são factuais e desprovidas de guerras sagradas.

— Hans Westerbeek

4

Não, essas respostas são principalmente declarações de fatos testáveis, não opiniões. Embora essa pergunta possa atrair respostas inúteis, na verdade não o fez. Deve permanecer aberto como uma descrição útil das diferenças reais entre as ferramentas.

— Erickson

61

Observe que uma diferença importante entre o SBT e o Gradle é o gerenciamento de dependências :

SBT : Ivy , com uma revisão que pode ser dada como fixa (1.5.2, por exemplo) ou como última (ou dinâmica).
Consulte " Dependência de Ivy ".
Isso significa que o suporte do mecanismo "-SNAPSHOT" pode ser problemático, embora os detalhes de Mark Harrah neste tópico :

É verdade que o cache pode ficar confuso, mas não é verdade que Ivy não entende a resolução de instantâneos. Eugene explicou esse ponto em outro tópico, talvez na lista de administradores. Há um problema com a atualização automática do sbt que foi corrigido no 0.12.

O que Ivy não suporta, até onde eu sei, é a publicação de instantâneos da maneira que o Maven faz. Acredito ter declarado isso em outro lugar, mas se alguém quiser melhorar a situação, minha opinião é que o melhor esforço é trabalhar com a equipe do Gradle para reutilizar seu código de gerenciamento de dependência.

Gradle : Este tópico menciona ( Peter Niederwieser ):

Para que você saiba, os problemas com as dependências de instantâneos do Ivy e Maven foram um dos motivos pelos quais o Gradle acabou substituindo o Ivy por seu próprio código de gerenciamento de dependências. Foi uma tarefa grande, mas nos trouxe muitas coisas boas.

Este tweet menciona que todas as situações podem evoluir no futuro:

Mark disse no passado que estava interessado em usar Gradle em vez de Ivy para o SBT.

(ambas as ferramentas podem aprender uma com a outra )

— VonC
fonte

1

O maior inconveniente que já conheci é sbt é que você não pode especificar a regra para não recompilar cada vez que é mencionada. As regras integradas para java e scala têm essa funcionalidade, mas não é exposta para escrever regras personalizadas. Portanto, toda vez que você gerar um arquivo de programa ou documentação e até mesmo se gerar um arquivo jar, sua tarefa será executada em cada chamada, independentemente de quaisquer alterações nas fontes terem sido realmente feitas. Mesmo o make é inteligente o suficiente, mas não sbt

— ayvango

1

@ayvango Não é o caso do sbt atualmente. Existem muitos plug-ins que utilizam essa funcionalidade, como android-sdk-plugin

— dant3

Você sabe qual API é usada para essa funcionalidade?

— ayvango

então isso é algo que falta à ivy quando comparado ao maven e ao gradle? Isso é estranho

— tribbloid

53

Para mim, as principais características do SBT são:

Compilação rápida (mais rápida do que fsc).
Compilação / teste contínuo: o comando ~testrecompilará e testará seu projeto sempre que salvar uma modificação.
Compilação e publicação cruzada em várias versões do scala.
Recuperando dependências automaticamente com a compatibilidade de versão correta do scala.

As desvantagens são:

Uma sintaxe hieroglífica que tende a desencorajar novos usuários (especialmente se eles vierem de Java)
Não é uma maneira fácil de definir uma "tarefa": se você precisar de um procedimento de construção especial, precisará encontrar um plugin ou escrever um plugin.

— paradigmático
fonte

Estou certo de que há / havia necessidade do recurso de compilação cruzada / publicação devido aos problemas que o Scala teve com incompatibilidade binária retroativa?

— Hans Westerbeek

1

Sim. E esses problemas podem acontecer novamente ao mudar para Scala 2.10.

— paradigmático

1

Há mais duas diferenças que eu adicionaria: * No SBT, é mais fácil autogerenciar dependências, IMO. * O executor de teste SBT parece mais rápido; Suspeito que haja alguma concorrência astuta envolvida aqui, mas estou supondo. O SBT parece ser um produto mais capaz, mas menos maduro.

— Rick-777

25

1 para a desvantagem da 'sintaxe hieroglífica'. Essa é a minha maior reclamação com o SBT. A sobrecarga do operador sempre leva ao abuso: - /

— Ron Dahlgren

7

A enigmática sintaxe do SBT traz à tona o que há de pior em escala. Gradle é baseado em um modelo de domínio bem pensado e sintaxe direta.

— nemoo

40

sbt é um Scala DSL e, para ele, Scala é um cidadão de primeira classe, portanto, em princípio, parece ser uma boa opção.

Mas o sbt sofre de grandes mudanças incompatíveis entre as versões, o que torna difícil encontrar o plugin de trabalho correto para uma tarefa e fazê-lo funcionar.

Eu pessoalmente desisti do sbt, pois estava causando mais problemas do que resolvendo. Na verdade, mudei para o gradle.

Vai saber.

— Jens Schauder
fonte

2

Pelo que eu sei, houve apenas uma mudança muito importante: quando o sbt mudou de 0.7.x para 0.1.x

— om-nom-nom

1

Se você usar um plugin para o sbt 0.11.2 e depois ir para o sbt 0.12, você precisa esperar que o autor do plugin compile uma nova versão ou faça você mesmo. a ideia-sbt é um exemplo.

— fmpwizard de

4

@fmpwizard A linha sbt 0.12 ainda não foi lançada ... Pare de espalhar FUD.

— paradigmático de

3

Não é o sbt impossível de usar, nossa equipe usa. Mas meu comentário foi para apoiar esta resposta, que dizia "... Mas sbt sofre de grandes mudanças incompatíveis entre as versões, o que torna difícil encontrar o plugin de trabalho correto para uma tarefa e fazê-lo funcionar ..." Como você notou , Não posso simplesmente usar o plugin scct, tive que modificá-lo (sim, pequena mudança, mas depois tive que publicá-lo em algum lugar para que toda a minha equipe pudesse acessá-lo) Uma dor sem um bom motivo.

— fmpwizard

3

Você é capaz de fazer compilação cruzada para diferentes versões do Scala usando o Gradle?

— Machisuji

4

Sou bastante novo no gradle e muito novo no sbt - o que realmente gosto no sbt até agora é o console interativo. Ele me permite usar comandos como 'inspecionar' para ter uma ideia melhor do que está acontecendo. AFAIK gradle não fornece algo assim.

— eugenevd
fonte

-11

Sbt e gradle, ambos são baseados em linguagens tipadas estaticamente .... mas sbt tem poucas vantagens:

melhor suporte a plugins, especialmente autoplugins
criação de tarefas e gerenciamento de dependências entre tarefas
sbt se adapta especialmente a projetos scala no sentido de que suporta builds incrementais e a maior parte do sbt em si é escrito em scala e as definições de build sbt são escritas em scala
sbt tem suporte de shell interativo com muitas tarefas úteis integradas
o ciclo de vida padrão do sbt é muito útil e pode ser um iniciante com muito menos esforço

— Saby
fonte

1

O Gradle é baseado no groovy, que não é uma linguagem de tipo estático.

— Vistritium

O Gradle faz gerenciamento de dependências entre tarefas, é o mais fácil possível criar uma tarefa, não tenho ideia de como pode ser mais fácil escrever um plugin do que para o gradle, que pode ter plugins groovy, Java, gradle e possivelmente mais.

— Johnride