sbt uberjar

Crear jar independiente usando SBT



uberjar (5)

''sbt package'' producirá un archivo jar.

Si desea que sea ejecutable, debe agregar lo siguiente a su configuración .sbt:

mainClass in Compile := Some("your.main.Class")

Era un usuario pesado de Maven y ahora estoy usando gradualmente SBT para algunos de mis proyectos.

Me gustaría saber cómo podría usar SBT para crear un proyecto Java independiente. Este proyecto debe empaquetarse como un archivo JAR y este archivo JAR se usará como una dependencia en otro proyecto SBT.

En Maven, podría decir en mi pom.xml qué tipo de artefacto debería producir cuando lo construyo. ¿Hay algo similar que pueda hacer en SBT?


Claro, puede usar el comando ''sbt package'', crea un archivo jar pero este jar no tendrá dependencias. Para ejecutarlo es necesario especificar ''classpath'' arg en las bibliotecas.

En tu caso, deseas un archivo ejecutable independiente. Y necesita agregar las dependencias. Para hacer esto, puede usar el complemento ''ensamblar'' para SBT, consulte https://github.com/sbt/sbt-assembly/

Después, puede ejecutar el comando ''sbt assembly'', que proporciona un archivo jar con todas las dependencias que puede implementar y ejecutar en cualquier lugar y en cualquier momento.

Para más detalles, mira este article


Creo que la forma más fácil de producir un contenedor independiente con su proyecto en él, lamentablemente no es mentir dentro de sbt.

Yo personalmente uso mi IDE: Intellij para hacer el jar (a través de la función ''construir artefacto'').

Gracias a Intellij puedo elegir fácilmente qué biblioteca quiero incluir en el contenedor o no, (por ejemplo, el scala stl).

En mi humilde opinión, este es, de lejos, el método más simple para obtener un jar ejecutable para su proyecto.

Si coloca scala stl, puede ejecutar su jar con el comando "java -jar", si no tiene que ejecutarlo en alguna parte con la versión correcta de scala instalada con "scala".


Existe una diferencia entre el uso independiente y hacer que un proyecto sea utilizable como dependencia u otro proyecto. En el primer caso, usaría un complemento como github.com/sbt/sbt-assembly . Lo que hará es crear un archivo jar que contenga los archivos de clase de proyecto junto con todas sus dependencias. Si escribe una aplicación, lo que obtiene es un tarro con doble clic que puede ejecutar desde cualquier lugar.

Si desea utilizar su proyecto A como dependencia para otro proyecto B, tiene diferentes opciones. Simplemente podría empaquetar los archivos de clase de A, utilizando el sbt package (respuesta de @Channing Walton). Luego podría soltar el archivo .jar resultante en el directorio lib del proyecto B. Sin embargo, si A también requiere bibliotecas, debe asegurarse de que también terminen en las bibliotecas del proyecto B.

Un mejor enfoque es publicar su proyecto. Puede hacerlo solo en su máquina local, utilizando sbt publish-local . Eso almacenará el contenedor como producido por el package en un directorio local especial al que se puede acceder desde sbt en otro proyecto, junto con un archivo POM que contiene las dependencias de A. Utilizará un ID de grupo (organización) y una ID de artefacto (nombre) y una versión de su proyecto A. Por ejemplo, en build.sbt :

name := "projecta" version := "0.1.0-SNAPSHOT" organization := "com.github.myname" scalaVersion := "2.10.3" publishMavenStyle := true

Después de publicar con sbt publish-local , puede agregar la siguiente dependencia a su proyecto B:

libraryDependencies += "com.github.myname" %% "projecta" % "0.1.0-SNAPSHOT"

Si tiene un proyecto Java puro, puede omitir el sufijo de la versión de Scala, es decir, en el Proyecto A:

crossPaths := false autoScalaLibrary := false

Y luego en el Proyecto B:

libraryDependencies += "com.github.myname" % "projecta" % "0.1.0-SNAPSHOT"

(utilizando solo un % caracteres entre el grupo y la ID del artefacto).

Más sobre publicación en la documentación de sbt .


publishLocal

construye el artefacto y lo publica en el repositorio Ivy local, lo que lo hace disponible para las dependencias de proyectos locales.

publishM2

Igual que arriba, pero el artefacto se publica en el repositorio local de Maven en lugar de en el repo de Ivy.