scala - logmanager - maven repository org apache logging log4j

comparando sbt y Gradle (5)

Estoy buceando en Scala y noté sbt. He estado bastante contento con Gradle en proyectos de Java / Groovy, y sé que hay un complemento scala para Gradle.

¿Cuáles podrían ser buenas razones para favorecer a sbt sobre Gradle en un proyecto de Scala?

Para mí, las características clave de SBT son:

Compilación rápida (más rápido que fsc ).
Compilación / pruebas continuas: la ~test comando recompilará y probará su proyecto cada vez que guarde una modificación.
Compilación cruzada y publicación cruzada, en varias versiones de scala.
Recuperación automática de dependencias con la compatibilidad correcta de la versión scala.

Las desventajas son:

Una sintaxis jeroglífica que tiende a desalentar a los nuevos usuarios (especialmente si provienen de Java)
No es una forma fácil de definir una "tarea": si necesita un procedimiento de compilación especial, necesitará encontrar un complemento o escribir un complemento usted mismo.

Sbt y gradle, ambos se basan en lenguajes tipados estáticos ... pero sbt tiene pocas ventajas:

mejor soporte de complementos, especialmente autoplugins
creación de tareas y gestión de dependencias entre tareas
sbt se adapta especialmente a los proyectos de scala en el sentido de que admite compilaciones incrementales y la mayor parte del mismo sbt está escrito en scala y sbt. las definiciones de compilación están escritas en scala.
sbt tiene soporte de shell interactivo con muchas tareas útiles incorporadas
El ciclo de vida predeterminado de sbt es bastante útil y puede hacer que el principiante comience con bastante menos esfuerzo

Soy bastante nuevo en gradle, y muy nuevo en sbt, lo que realmente me gusta de sbt hasta ahora es la consola interactiva. Me permite usar comandos como ''inspeccionar'' para tener una mejor idea de lo que está pasando. AFAIK gradle no proporciona algo como este atm.

Tenga en cuenta que una diferencia clave entre SBT y Gradle es su gestión de la dependencia :

SBT : Ivy , con una revisión que se puede dar como una fija (1.5.2, por ejemplo) o como la última (o dinámica).
Ver " Ivy Dependency "
Eso significa que el soporte del mecanismo "-SNAPSHOT" puede ser problemático, a pesar de que Mark Harrah detalla en este hilo :

Es cierto que la memoria caché puede confundirse, pero no es cierto que Ivy no comprenda la resolución de instantáneas. Eugene explicó este punto en otro hilo, quizás en la lista de administración. Hay un problema con la actualización automática de sbt que se trató en 0.12.
Lo que Ivy no admite, hasta donde yo sé, es publicar instantáneas de la manera en que lo hace Maven. Creo que lo he expresado en otro lugar, pero si alguien quiere mejorar la situación, mi opinión es que es mejor dedicar el esfuerzo al trabajo con el equipo de Gradle para reutilizar su código de administración de dependencias.

Gradle : Este hilo menciona ( Peter Niederwieser ):

Para hacerte saber, los problemas con las dependencias de instantáneas de Ivy y Maven fueron una de las razones por las que Gradle eventualmente reemplazó a Ivy con su propio código de administración de dependencias. Fue una gran tarea, pero nos trajo mucha bondad.

Este tweet menciona que toda la situación podría evolucionar en el futuro:

Mark dijo en el pasado que estaba interesado en usar Gradle en lugar de Ivy para SBT.

(ambas herramientas pueden aprender unas de otras )

sbt es un Scala DSL y para él Scala es un ciudadano de primera clase, por lo que en principio parece ser una buena opción.

Pero sbt sufre de grandes cambios incompatibles entre versiones, lo que hace difícil encontrar el plugin de trabajo correcto para una tarea y hacer que funcione.

Personalmente renuncié a sbt, ya que causaba más problemas de los que resolvía. De hecho, cambié a gradle.

Imagínate.