mirror of https://github.com/sbt/sbt.git
Merge pull request #1270 from oscarvarto/spanishTranslation
Initial Spanish translation of documentation
This commit is contained in:
eugene yokota
commit
2a0fef6700
|
|
@ -0,0 +1,279 @@
|
|||
=========================
|
||||
`.sbt` Build Definition
|
||||
=========================
|
||||
|
||||
Esta página describe las *build definitions*, incluyendo algo de "teoría" y
|
||||
la sintaxis de `build.sbt`. Se asume que usted sabe como :doc:`usar sbt <Running>` y que ha leído las páginas previas en la
|
||||
:doc:`Guía de inicio <index.html>`.
|
||||
|
||||
`.sbt` vs. `.scala` Build Definition
|
||||
----------------------------------
|
||||
|
||||
Una *build definition* para sbt puede contener archivos con terminación `.sbt`, localizados
|
||||
en el directorio base de un proyecto, y archivos con extensión `.scala`, localizados en el
|
||||
subdirectorio `project/` del directorio base.
|
||||
|
||||
Esta página trata sobre los archivos `.sbt`, que son apropiados para la mayoría de los casos.
|
||||
Los archivos `.scala` se usan típicamente para compartir código entre archivos `.sbt` y para
|
||||
*build definitions* más complicadas.
|
||||
|
||||
Vea :doc:`.scala build definition <Full-Def>` (más adelante en la *Guía de inicio*) para más
|
||||
información sobre los archivos `.scala`.
|
||||
|
||||
¿Qué es una *Build Definition*?
|
||||
-------------------------------
|
||||
|
||||
Después de examinar un proyecto y procesar los archivos para la definición de la construcción del proyecto,
|
||||
sbt termina con un mapa inmutable (un conjunto de pares llave-valor) describiendo la construcción.
|
||||
|
||||
Por ejemplo, una llave es :key:`name` y se mapea a un valor de tipo cadena (`String`), el nombre de su proyecto.
|
||||
|
||||
*Los archivos de definición de la construcción no afectan el mapa de sbt directamente.*
|
||||
|
||||
En lugar de esto, la definición de la construcción crea una lista enorme de objectos con el tipo
|
||||
`Setting[T]` donde `T` es el tipo del valor en el mapa. Un `Setting` describe una *transformación del mapa*,
|
||||
tal como añadir un nuevo valor llave-valor o agregar a un valor existente. (En el espíritu de la
|
||||
programación funcional con estructuras de datos y valores inmutables, una transformación regresa un
|
||||
nuevo mapa - no se actualiza el viejo mapa en sí mismo).
|
||||
|
||||
En `build.sbt`, usted puede crear un `Setting[String]` para el nombre de su proyecto como se indica a continuación:
|
||||
|
||||
::
|
||||
|
||||
name := "hello"
|
||||
|
||||
Este `Setting[String]` transforma el mapa al añadir (o reemplazar) la llave `name`, dándole el valor
|
||||
|
||||
`"hello"`. El mapa transformado se convierte en el nuevo mapa de sbt.
|
||||
|
||||
Para crear el mapa, sbt primero ordena la lista de *settings* (configuraciones) de modo que todos
|
||||
los cambios al mismo se realicen juntos, y los valores que dependen de otras llaves se procesan después
|
||||
de las llaves de las que dependen. Entonces sbt visita la lista ordenada de `Settings`\ s y aplica cada uno al mapa a la vez.
|
||||
|
||||
Resumen: Una definición de construcción define una lista de `Setting[T]`, donde un
|
||||
`Setting[T]` es una transformación que afecta el mapa de pares de llaves-valores de sbt
|
||||
y `T` es el tipo de cada valor.
|
||||
|
||||
De qué manera `build.sbt` define la configuración
|
||||
-------------------------------------------------
|
||||
|
||||
`build.sbt` define una `Seq[Setting[_]]`; se trata de una lista de expresiones
|
||||
de Scala, separada por líneas en blanco, donde cada una se convierte en un elemento
|
||||
de la secuencia. Si usted colocara `Seq(` antes del contenido de un archivo `.sbt`
|
||||
y `)` al final y reemplazara las líneas blancas con comas, entonces estaría observando
|
||||
el código `.scala` equivalente.
|
||||
|
||||
A continuación se muestra un ejemplo:
|
||||
|
||||
::
|
||||
|
||||
name := "hello"
|
||||
|
||||
version := "1.0"
|
||||
|
||||
scalaVersion := "2.10.4"
|
||||
|
||||
Cada `Setting` se define con una expresión de Scala.
|
||||
Las expresiones en `build.sbt` son independientes la una de la otra, y
|
||||
son expresiones, más bien que sentencias completas de Scala. Estas expresiones
|
||||
pueden estar entremezcladas con `val`\ s, `lazy val`\s, y `def`\ s.
|
||||
No se permiten `object`\ s ni `class`\ es en `build.sbt`.
|
||||
Estos deben ir en el directorio `project/` como archivos de código fuente completos.
|
||||
|
||||
Por la izquierda, :key:`name`, :key:`version`, y :key:`scalaVersion` son *keys* (llaves).
|
||||
Una *key* es una instancia de `SettingKey[T]`, `TaskKey[T]`, o `InputKey[T]` donde `T` es
|
||||
el valor esperado para el tipo. La clase de *keys* se explican abajo.
|
||||
|
||||
Las *keys* tienen un método llamado `:=`, que regresa un `Setting[T]`. Usted podría usar
|
||||
una sintáxis similar a la de Java para invocar al método:
|
||||
|
||||
::
|
||||
|
||||
name.:=("hello")
|
||||
|
||||
Pero Scala permite usar `name := "hello"` en lugar de lo anterior (en Scala, un método con un único
|
||||
parámetro puede utilizar cualquiera de las dos sintaxis).
|
||||
|
||||
El método `:=` en la *key* :key:`name` regresa un `Setting`, específicamente un
|
||||
`Setting[String]`. `String` también aparece en el tipo de :key:`name` en sí misma,
|
||||
el cuál es `SettingKey[String]`. En este caso, el valor `Setting[String]` regresado es una
|
||||
transformación para agregar o reemplazar la *key* :key:`name` en el mapa de sbt,
|
||||
dándole el valor `"hello"`.
|
||||
|
||||
Si usted usa el tipo de valor equivocado, la definición de la construcción no compilará:
|
||||
|
||||
::
|
||||
|
||||
name := 42 // no compila
|
||||
|
||||
Las *settings* (configuraciones) deben estar separadas por líneas en blanco
|
||||
---------------------------------------------------------------------------
|
||||
|
||||
No es posible escribir un `build.sbt` como el siguiente:
|
||||
|
||||
::
|
||||
|
||||
// NO compila, pues no hay líneas en blanco
|
||||
name := "hello"
|
||||
version := "1.0"
|
||||
scalaVersion := "2.10.3"
|
||||
|
||||
sbt necesita un tipo de delimitador para indicar donde termina una expresión y comienza
|
||||
la siguiente.
|
||||
|
||||
Los archivos `.sbt` contienen una lista de expresiones de Scala, no un único programa de Scala.
|
||||
Estas expresiones tienen que separarse y pasarse al compilador de manera individual.
|
||||
|
||||
Keys
|
||||
----
|
||||
|
||||
Tipos
|
||||
~~~~~
|
||||
|
||||
Existen tres tipos de llaves:
|
||||
|
||||
- `SettingKey[T]`: una *key* para un valor que se calcula una sola vez (el valor es
|
||||
calculado cuando se carga el proyecto, y se mantiene).
|
||||
- `TaskKey[T]`: una *key* para un valor, llamado una *task* (tarea),
|
||||
que tiene que ser recalculada cada vez, potencialmente con efectos laterales.
|
||||
- `InputKey[T]`: una *key* para una *task* que tiene argumentos para la línea de comandos como
|
||||
entrada. Vea :doc:`/Extending/Input-Tasks` para más detalles.
|
||||
|
||||
Built-in Keys (Llaves ya incluídas)
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Las llaves ya incluídas son simplemente campos de un objeto llamado
|
||||
`Keys <../../sxr/sbt/Keys.scala.html>`_. Un archivo
|
||||
`build.sbt` tiene implícitamente un `import sbt.Keys._`, de modo que
|
||||
`sbt.Keys.name` puede ser referido como :key:`name`.
|
||||
|
||||
Custom Keys (llaves personalizadas)
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Las llaves personalizadas pueden definirse con sus métodos de creación respectivos: `settingKey`, `taskKey`, e `inputKey`.
|
||||
Cada método espera el tipo del valor asociado con la llave así como una descripción.
|
||||
El nombre de la llave se toma del `val` al que se le asignó la llave.
|
||||
Por ejemplo, para definir una llave para una nueva tarea llamado `hello`, ::
|
||||
|
||||
lazy val hello = taskKey[Unit]("An example task")
|
||||
|
||||
Aquí se usó el hecho de que un archivo `.sbt` puede contener `val`\ s y `def`\ s además de *settings* (configuraciones).
|
||||
Todas estas definiciones son evaluadas antes que las configuraciones sin importar donde se definan en el archivo.
|
||||
`val`\ s y `def`\ s deben estar separadas de las *settings* mediante líneas blancas.
|
||||
|
||||
.. note::
|
||||
|
||||
Típicamente, se utilizan `lazy val`\ s en lugar de `val`\ s para evitar problemas de inicialización.
|
||||
|
||||
Task vs. Setting keys (Llaves para *Tasks* vs. Llaves para *Settings*)
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Se dice que una `TaskKey[T]` define una *task*. Las *tasks* son operaciones tales como
|
||||
:key:`compile` o :key:`package`. Pueden regresar `Unit` (`Unit` es el tipo de Scala análogo a `void`),
|
||||
o pueden regresar un valor relacionado con la tarea, por ejemplo, :key:`package` es una `TaskKey[File]` y
|
||||
su valor es el archivo jar que este crea.
|
||||
|
||||
Cada vez que inicia una tarea de ejecución, por ejemplo mediante teclear :key:`compile`
|
||||
en el prompt interactivo de sbt, sbt volverá a ejecutar cualquier *task* envuelta exactamente una vez.
|
||||
|
||||
El mapa de sbt que describe el proyecto puede mantener una cadena fija para un *setting* tal como
|
||||
:key:`name`, pero tiene que haber algo de código ejecutable para una tarea como :key:`compile` -- incluso si dicho
|
||||
código ejecutable eventualmente regresa una cadena, tiene que ejecutarse cada vez.
|
||||
|
||||
*Una key dada siempre se refiere ya sea a una task o a un setting*. Es decir, "taskiness" (si debe ejecutarse
|
||||
cada vez) es una propiedad de la *key*, no del valor.
|
||||
|
||||
Definiendo tasks y settings
|
||||
---------------------------
|
||||
|
||||
Usando `:=`, usted puede asignar un valor a un *setting* y un cómputo a una *task*.
|
||||
En el caso de un *setting*, el valor será calculado una sola vez al momento de cargar el proyecto.
|
||||
Para una tarea, el cómputo se realizará cada vez que se ejecute la tarea.
|
||||
|
||||
Por ejemplo, para implementar la tarea `hello` de la sección anterior, ::
|
||||
|
||||
hello := { println("Hello!") }
|
||||
|
||||
Ya vimos un ejemplo de definición de un *setting* para el nombre del proyecto, ::
|
||||
|
||||
name := "hello"
|
||||
|
||||
Tipos para las tareas y los settings
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Desde la perspectiva del sistema de tipos, el `Setting` creado a partir de una *task key* es
|
||||
ligeramente distinta de la creada a partir de una *setting key*.
|
||||
`taskKey := 42` resulta en una `Setting[Task[T]]` mientras que
|
||||
`settingKey := 42` resulta en una `Setting[T]`. Para la mayoría de los propósitos
|
||||
no hay diferencia, la *task key* todavía crea un valor de tipo `T`
|
||||
cuando la tarea se ejecuta.
|
||||
|
||||
La diferencia entre los tipos `T` y `Task[T]` tiene la siguiente implicación: un
|
||||
*setting* no puede depender de una *task*, poque un *setting* es evaluado únicamente una vez
|
||||
al momento de cargar el proyecto y no se vuelve a ejecutar.
|
||||
Se escribirá más sobre este asunto pronto en :doc:`more about settings <More-About-Settings>`.
|
||||
|
||||
Keys en modo sbt interactivo
|
||||
----------------------------
|
||||
|
||||
En el modo interactivo de sbt, usted puede teclear el nombre de cualquier tarea para ejecutar
|
||||
dicha tarea. Es por esto que al teclear :key:`compile` se ejecuta la *task* de compilación.
|
||||
La *key* :key:`compile` es una llave para una *task*.
|
||||
|
||||
Si usted teclea el nombre de una *key* para *setting* más bien que una para *task*, entonces
|
||||
el valor de la *key* para *setting* será mostrado. Al teclear el nombre de una *task* se ejecuta
|
||||
dicha *task*, pero no se despliega el valor resultante; para ver el resultado de la *task*, use
|
||||
`show <nombre de la tarea>` más bien que simplemente `<nombre de la tarea`.
|
||||
La convención para los nombres de las llaves es usar `estiloDeCamello` de modo que el nombre utilizado
|
||||
en la línea de comandos y el identificador de Scala sean idénticos.
|
||||
|
||||
Para aprender más sobre cualquier *key*, teclee `inspect <nombre de la key>` en el prompt
|
||||
interactivo de sbt.
|
||||
Algo de la información que `inspect` despliega no tendrá sentido todavía, pero en la parte superior
|
||||
le mostrará el tipo del valor para el *setting* y una breve descripción del tal.
|
||||
|
||||
Imports en `build.sbt`
|
||||
------------------------
|
||||
|
||||
Puede poner sentencias import en la parte superior de `build.sbt`; no necesitan estar
|
||||
separadas por líneas en blanco.
|
||||
|
||||
Hay algunos imports por default, como se indica a continuación:
|
||||
|
||||
::
|
||||
|
||||
import sbt._
|
||||
import Process._
|
||||
import Keys._
|
||||
|
||||
(Además, si usted tiene :doc:`archivos .scala <Full-Def>`,
|
||||
el contenido de cualquier objeto `Build` o `Plugin` en estos archivos será importado.
|
||||
Más sobre este asunto cuando se llegue a :doc:`definiciones de construccion .scala <Full-Def>`.)
|
||||
|
||||
Añadiendo dependencias (librerías)
|
||||
----------------------------------
|
||||
|
||||
Para agregar dependencias de librerías de terceros, hay dos opciones. La primera es
|
||||
añadir jars en el directorio `lib/` (para *unmanaged dependencies*) y la otra es agregar
|
||||
*managed dependencies*, que se verán como se muestra a continuación en `build.sbt`:
|
||||
|
||||
::
|
||||
|
||||
libraryDependencies += "org.apache.derby" % "derby" % "10.4.1.3"
|
||||
|
||||
Así es como se agrega una *managed dependency* sobre la librería Apache Derby, versión 10.4.1.3.
|
||||
|
||||
La key :key:`libraryDependencies` envuelve dos complejidades: `+=` más bien que
|
||||
`:=`, y el método `%`. `+=` agrega algo al valor anterior de la *key* más bien que reemplazarlo; esto
|
||||
se explica en :doc:`más sobre los settings </Getting-Started/More-About-Settings>`.
|
||||
El método `%` se usa para construir un ID para un módulo de Ivy a partir de cadenas, como se explica
|
||||
en :doc:`library dependencies </Getting-Started/Library-Dependencies>`.
|
||||
|
||||
Por lo pronto, omitiremos los detalles del manejo de las dependencias (librerías) hasta más tarde en
|
||||
la Guía de inicio. Hay una :doc:`página completa </Getting-Started/Library-Dependencies>` que cubre
|
||||
el tema más tarde.
|
||||
|
||||
A continuación
|
||||
--------------
|
||||
|
||||
Siga con :doc:`aprenda más sobre scopes </Getting-Started/Scopes>`.
|
||||
|
|
@ -0,0 +1,92 @@
|
|||
=========================
|
||||
Estructura de directorios
|
||||
=========================
|
||||
|
||||
Esta página asume que usted ha :doc:`instalado sbt <Setup>` y ha visto el
|
||||
ejemplo :doc:`Hello, World <Hello>`.
|
||||
|
||||
Directorio base
|
||||
---------------
|
||||
|
||||
En la terminología de sbt, el "directorio base" es el directorio que contiene al proyecto.
|
||||
De modo que si usted creó el proyecto `hello` que contiene `hello/build.sbt` y `hello/hw.scala`
|
||||
como se indicó en el ejemplo :doc:`Hello, World <Hello>`, `hello` es su directorio base.
|
||||
|
||||
Código fuente
|
||||
-------------
|
||||
|
||||
El código fu8ente puede ponerse en el directorio base del proyecto como en el caso de
|
||||
`hello/hw.scala`. Sin embargo, la mayoría de las personas no hacen esto para proyectos reales;
|
||||
se traduce en mucho desorden.
|
||||
|
||||
sbt utiliza la misma estructura de directorios que
|
||||
`Maven <http://maven.apache.org/>`_ para el código fuente por default (todos las rutas son relativas
|
||||
al directorio base):
|
||||
|
||||
.. code-block:: text
|
||||
|
||||
src/
|
||||
main/
|
||||
resources/
|
||||
<archivos que se incluyen en el jar principal van aquí>
|
||||
scala/
|
||||
<código fuente de Scala de main>
|
||||
java/
|
||||
<código fuente de Java de main>
|
||||
test/
|
||||
resources
|
||||
<archivos que se incluyen en el jar de test van aquí>
|
||||
scala/
|
||||
<código fuente de Scala para test>
|
||||
java/
|
||||
<código fuente de Java para test>
|
||||
|
||||
|
||||
Otros directorios en `src/` serán ignorados. Adicionalmente, todos los directorios ocultos serán
|
||||
ignorados.
|
||||
|
||||
Archivos de definición de la construcción de sbt (sbt build definition files)
|
||||
-----------------------------------------------------------------------------
|
||||
|
||||
Ya ha visto `build.sbt` en el directorio base del proyecto. Otros
|
||||
archivos sbt aparecen en el subdirectorio `project`.
|
||||
|
||||
El subdirectorio `project` puede contener archivos `.scala`, que se combinan
|
||||
con los archivos `.sbt` para formar la definición completa de la construcción.
|
||||
|
||||
Vea :doc:`.scala build definitions <Full-Def>` para más información.
|
||||
|
||||
.. code-block:: text
|
||||
|
||||
build.sbt
|
||||
project/
|
||||
Build.scala
|
||||
|
||||
Tal vez pueda ver archivos `.sbt` dentro de `project/` pero no son equivalentes
|
||||
a archivos `.sbt` en el directorio base del proyecto. La explicación de esto
|
||||
`viene después <Full-Def>`, dado que necesitará algo de antecedentes primero.
|
||||
|
||||
Productos de la construcción
|
||||
----------------------------
|
||||
|
||||
Los archivos generados (clases compiladas, paquetes en jars, archivos gestionados (*managed files*), caches,
|
||||
y documentación) será escrita al directorio `target` por default.
|
||||
|
||||
Configurando el sistema de control de versiones
|
||||
-----------------------------------------------
|
||||
|
||||
Su archivo `.gitignore` (o el equivalente para otro sistema de control de versiones)
|
||||
debe contener:
|
||||
|
||||
.. code-block:: text
|
||||
|
||||
target/
|
||||
|
||||
Note que el texto anterior tiene una `/` de forma deliberada (para que únicamente los directorios
|
||||
sean seleccionados) y de manera deliberada no tiene una `/` al inicio (para que el directorio
|
||||
`project/target/` también sea seleccionado, además de simplemente el directorio `target/`).
|
||||
|
||||
A continuación
|
||||
==============
|
||||
|
||||
Aprenda sobre :doc:`cómo ejecutar sbt <Running>`.
|
||||
|
|
@ -0,0 +1,92 @@
|
|||
============
|
||||
Hello, World
|
||||
============
|
||||
|
||||
Esta página asume que usted ha :doc:`instalado sbt <Setup>`.
|
||||
|
||||
Cree un directorio project con código fuente
|
||||
--------------------------------------------
|
||||
|
||||
Un proyecto válido de sbt puede ser un directorio que contenga un único archivo de código fuente.
|
||||
Intente crear un directorio `hello` con un archivo `hw.scala`, que contenga lo siguiente:
|
||||
|
||||
::
|
||||
|
||||
object Hola {
|
||||
def main(args: Array[String]) = println("¡Hola!")
|
||||
}
|
||||
|
||||
Después, desde el directorio `hello`, inicie sbt y teclee `run` en la consola interactiva
|
||||
de sbt. En Linux u OS X los comandos tal vez se vean de la siguiente manera:
|
||||
|
||||
.. code-block:: text
|
||||
|
||||
$ mkdir hello
|
||||
$ cd hello
|
||||
$ echo 'object Hola { def main(args: Array[String]) = println("¡Hola!") }' > hw.scala
|
||||
$ sbt
|
||||
...
|
||||
> run
|
||||
...
|
||||
Hola!
|
||||
|
||||
En este caso, sbt funciona simplemente por convención. sbt encontrará lo siguiente de manera
|
||||
automática:
|
||||
|
||||
- Código fuente en el directorio base.
|
||||
- Código fuente en `src/main/scala` o `src/main/java`.
|
||||
- Pruebas en `src/test/scala` o `src/test/java`
|
||||
- Archivos de datos en `src/main/resources` o `src/test/resources`
|
||||
- jars en `lib`
|
||||
|
||||
Por default, sbt construirá proyectos con la misma versión de Scala utilizada para ejecutar
|
||||
sbt en sí mismo.
|
||||
|
||||
Usted puede ejecutar el proyecto con `sbt run`o ingresar a la `REPL de Scala <http://www.scala-lang.org/node/2097>`_ con `sbt console`.
|
||||
`sbt console` configura el classpath de su proyecto para que pueda probar ejemplos de Scala
|
||||
basados en el código de su proyecto.
|
||||
|
||||
Build definition (Definición de la construcción)
|
||||
------------------------------------------------
|
||||
|
||||
La mayoría de los proyectos necesitarán algo de configuración manual. La configuración básica de la construcción
|
||||
va en un archivo llamado `build.sbt`, localizado en el directorio base del proyecto.
|
||||
|
||||
Por ejemplo, si su proyecto está en el directorio `hello`, en
|
||||
`hello/build.sbt` usted puede escribir:
|
||||
|
||||
.. parsed-literal::
|
||||
|
||||
name := "hello"
|
||||
|
||||
version := "1.0"
|
||||
|
||||
scalaVersion := "|scalaRelease|"
|
||||
|
||||
Note la línea en blanco entre cada ítem. Esto no es simplemente porque sí;
|
||||
se requieren las líneas en blanco para separar cada ítem. En :doc:`.sbt build definition <Basic-Def>` usted
|
||||
aprenderá más sobre cómo escribir un archivo `build.sbt`.
|
||||
|
||||
Si usted planea empaquetar su proyecto en un jar, tal vez desee configurar al menos el nombre y la versión
|
||||
en un archivo `build.sbt`.
|
||||
|
||||
Configurando la versión de sbt
|
||||
------------------------------
|
||||
|
||||
Usted puede forzar una versión partivular de sbt al crear un archivo
|
||||
`hello/project/build.properties`. En este archivo, escriba:
|
||||
|
||||
.. parsed-literal::
|
||||
|
||||
sbt.version=\ |release|
|
||||
|
||||
para forzar el uso de sbt |release|. sbt es 99% compatible (con respecto al código fuente) de
|
||||
una *release* a otra.
|
||||
|
||||
Sin embargo, configurar la versión de sbt en `project/build.properties` evita
|
||||
cualquier confusión potencial.
|
||||
|
||||
A continuación
|
||||
==============
|
||||
|
||||
Aprenda sobre el :doc:`layout de archivos y directorios <Directories>` de un proyecto de sbt.
|
||||
|
|
@ -0,0 +1,116 @@
|
|||
=========
|
||||
Ejecución
|
||||
=========
|
||||
|
||||
Esta página describe cómo utilizar `sbt` una vez que usted a configurado su proyecto.
|
||||
Se asume que usted ha :doc:`instalado sbt <Setup>` y que ha creado un proyecto
|
||||
`Hello, World <Hello>` u otro proyecto.
|
||||
|
||||
Modo interactivo
|
||||
----------------
|
||||
|
||||
Ejecute sbt en el directorio de su proyecto sin argumentos:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ sbt
|
||||
|
||||
Ejecutar sbt sin ningún argumento en la línea de comandos, inicia sbt en modo interactivo.
|
||||
El modo interactivo tiene una línea de comandos (¡con *tab completion* e historia!).
|
||||
|
||||
Por ejemplo, usted puede teclear :key:`compile` en el prompt de sbt:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
> compile
|
||||
|
||||
Para key:`compile` de nuevo, presione la tecla "arriba" y entonces enter.
|
||||
|
||||
Para ejecutar su programa nuevamente, teclee :key:`run`.
|
||||
|
||||
Para dejar el modo interactivo, teclee `exit` o utilice Ctrl+D (Unix) o Ctrl+Z
|
||||
(Windows).
|
||||
|
||||
Modo Batch (por lotes)
|
||||
----------------------
|
||||
|
||||
También puede ejecutar sbt en modo batch, especificando una lista separada por espacios
|
||||
de comandos de sbt como argumentos. Para comandos de sbt que toman argumentos, pase el
|
||||
comando y los argumentos como uno solo a `sbt` mediante encerrarlos entre comillas. Por
|
||||
ejemplo:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ sbt clean compile "testOnly TestA TestB"
|
||||
|
||||
En este ejemplo, la *key* :key:`testOnly` tiene argumentos, `TestA` y `TestB`.
|
||||
Los comandos se ejecutarán en sequencia (:key:`clean`, :key:`compile`, y entonces
|
||||
:key:`testOnly`).
|
||||
|
||||
Construcción y test continuos
|
||||
-----------------------------
|
||||
|
||||
Para acelerar el ciclo de edición-compilación-prueba, puede pedir a sbt que
|
||||
recompile automáticamente o que ejecute los tests siempre que se guarde un archivo de código fuente.
|
||||
|
||||
Puede conseguir que un comando se ejecute siempre que uno o más archivos de código fuente cambien
|
||||
al agregar como prefijo `~`. Por ejemplo, en modo interactivo, intente:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
> ~ compile
|
||||
|
||||
Presione enter para dejar de observar sus cambios.
|
||||
|
||||
Usted puede usar el prefijo `~` ya sea en modo interactivo o en modo *batch*.
|
||||
|
||||
Vea :doc:`/Detailed-Topics/Triggered-Execution` para más detalles.
|
||||
|
||||
Comandos comunes
|
||||
----------------
|
||||
|
||||
Aquí encontrará algunos de los comandos de sbt más comunes. Para una lista más completa,
|
||||
vea :doc:`/Detailed-Topics/Command-Line-Reference`.
|
||||
|
||||
- :key:`clean` Borra todos los archivos generados (en el directorio :key:`target`).
|
||||
- :key:`compile` Compila los archivos de código fuente de main (en los directorios
|
||||
`src/main/scala` y `src/main/java`).
|
||||
- :key:`test` Compila y ejecuta todos los tests.
|
||||
- :key:`console` Inicia el interprete de Scala con un classpath que incluye el código
|
||||
fuente compilado y todas las dependencias. Para regresar a sbt, teclee
|
||||
`:quit`, Ctrl+D (Unix), o Ctrl+Z (Windows).
|
||||
- `run <argument>*` Ejecuta la clase principal para el proyecto en la misma máquina virtual que `sbt`.
|
||||
- :key:`package` crea un archivo jar que contiene los archivos en `src/main/resources` y las clases compiladas
|
||||
de `src/main/scala` y `src/main/java`.
|
||||
- `help <command>` Despliega ayuda detallada para el comando especificado.
|
||||
Si no se proporciona ningún comando, despliega una breve descripción de todos los comandos.
|
||||
- `reload` Recarga la definición de la construcción (los archivos `build.sbt`,
|
||||
`project/*.scala`, `project/*.sbt`). Este comando es necario si cambia la definición de la construcción.
|
||||
|
||||
Tab completion
|
||||
--------------
|
||||
|
||||
El modo interactivo tiene *tab completion*, incluyendo el caso cuando se tiene un prompt vacio. Una convención
|
||||
especial de sbt es que presionar tab una vez puede mostrar únicamente un subconjunto de *completions* más probables,
|
||||
mientras que presionarlo más veces muestra opciones más verbosas.
|
||||
|
||||
Comandos de historia
|
||||
--------------------
|
||||
|
||||
El modo interactivo recuerda la historia, incluso si usted sale de sbt y lo reinicia.
|
||||
La manera más simple de acceder a la historia es con la tecla "arriba". También se soportan
|
||||
los siguientes comandos:
|
||||
|
||||
- `!` Muestra la ayuda para los comandos de historia.
|
||||
- `!!` Ejecuta el comando previo de nuevo.
|
||||
- `!:` Muestra todos los comandos previos.
|
||||
- `!:n` Muestra los n comandos previos.
|
||||
- `!n` Ejecuta el comando con índice `n`, como se indica con el comando `!:`
|
||||
- `!-n` Ejecuta el comando n-th previo a este.
|
||||
- `!cadena` Ejecuta el comando más reciente que comienza con 'cadena'
|
||||
- `!?cadena` Ejecuta el comando más reciente que contenga 'cadena'
|
||||
|
||||
En seguida
|
||||
----------
|
||||
|
||||
Continúe :doc:`entendiendo build.sbt <Basic-Def>`.
|
||||
|
|
@ -0,0 +1,375 @@
|
|||
======
|
||||
Scopes
|
||||
======
|
||||
|
||||
Esta página describe los *scopes*. Se asume que usted ha leído y comprendido la página previa,
|
||||
:doc:`.sbt build definition <Basic-Def>`.
|
||||
|
||||
La historia completa sobre las *keys*
|
||||
-------------------------------------
|
||||
|
||||
:doc:`Previamente <Basic-Def>` supusimos que una *key* como
|
||||
:key:`name` correspondía a una entrada en el mapa de sbt de pares llave-valor (key-value). Esto
|
||||
fue una simplificación.
|
||||
|
||||
En verdad, cada llave puede tener un valor asociado en más de un contexto,
|
||||
llamado un "scope".
|
||||
|
||||
Algunos ejemplos concretos:
|
||||
|
||||
- Si usted tiene múltiples proyectos en la definición de la construcción, una *key* puede
|
||||
tener un valor diferente en cada proyecto.
|
||||
- La *key* :key:`compile` puede tener un valor diferente para sus archivos de código fuente
|
||||
de main comparado con el correspondiente valor para el código fuente de test, si usted
|
||||
desea que se compilen de manera distinta.
|
||||
- La *key* :key:`packageOpitons` (que contiene opciones para crear paquetes jar)
|
||||
puede tener diferentes valores para el empaquetado de archivos class (:key:`packageBin`) o para
|
||||
el empaquetado de código fuente (:key:`packageSrc`).
|
||||
|
||||
*No hay un único valor para una key dada*, porque el valor puede variar de acuerdo con el *scope*.
|
||||
|
||||
Sin embargo, existe un único valor para una *scoped key* (llaves con un contexto).
|
||||
|
||||
Si usted se imagina que sbt está procesando una lista de *settings* para generar
|
||||
un mapa de llave-valor (*key-value*) que describe al proyecto, como :doc:`se discutió anteriormente <Basic-Def>`,
|
||||
las *keys* en dicho mapa son *scoped keys*.
|
||||
Cada *setting* definido en la definición de la construcción del proyecto (por ejemplo en
|
||||
`build.sbt`) aplica a una *scoped key* también.
|
||||
|
||||
Con frecuencia el *scope* es implícito o tiene un valor por default, pero si dichos valores
|
||||
son incorrectos, entonces tendrá que indicar el *scope* deseado en `build.sbt`.
|
||||
|
||||
Ejes del Scope
|
||||
--------------
|
||||
|
||||
Un *eje del scope* es un tipo, donde cada instancia del tipo puede definir su propio *scope* (esto es,
|
||||
cada instancia puede tener sus propios valores únicos para las *keys*).
|
||||
|
||||
Hay tres ejes del scope:
|
||||
|
||||
- Projects
|
||||
- Configurations
|
||||
- Tasks
|
||||
|
||||
Scoping mediante del eje del proyecto
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Si usted :doc:`coloca múltiples proyectos en una construcción única <Multi-Project>`, cada proyecto necesita sus propios *settings*.
|
||||
Es decir, las *keys* pueden estar en *scope* de acuerdo al proyecto.
|
||||
|
||||
Los ejes del proyecto también pueden configurarse para la "entera construcción", de modo que un *setting* aplique
|
||||
a la construcción completa más bien que a un solo proyecto. Los *settings* de *nivel de construcción*
|
||||
con frecuencia se usan como un plan de reserva cuando un proyecto no define un *setting* específico para un proyecto.
|
||||
|
||||
Scoping mendiante el eje de configuración
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Una configuración define el tipo de construcción, potencialmente con su propio
|
||||
classpath, código fuente, paquetes generados, etc. El concepto de configuración
|
||||
viene de Iviy, que sbt usa para :doc:`managed dependencies <Library-Dependencies>`, y para
|
||||
`MavenScopes <http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Scope>`_.
|
||||
|
||||
Algunas configuraciones que verá en sbt:
|
||||
|
||||
- `Compile` que define la construcción principal (*main*) (`src/main/scala`).
|
||||
- `Test` que define cómo construir tests (`src/test/scala`).
|
||||
- `Runtime` que define el classpath para la *task* `run`.
|
||||
|
||||
Por default, todas las llaves asociadas con la compilación, empaquetamiento y la ejecución
|
||||
tienen un scope de configuración y por lo tanto pueden funcionar de manera diferente en cada
|
||||
configuración. Los ejemplos más obvios son las *keys* para *tasks*
|
||||
:key:`compile`, :key:`package`, y :key:`run`; pero todas las llaves que *afectan* dichas *keys*
|
||||
(tales como :key:`sourceDirectories` o :key:`scalacOptions` o
|
||||
:key:`fullClasspath`) también tienen scope de configuración.
|
||||
|
||||
Scoping mediante el eje task
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Los *settings* pueden afectar cómo funcionan las *tasks*. Por ejemplo, la *key* de *setting* :key:`packageOptions` afecta
|
||||
a la *key* :key:`packageSrc` de *task*.
|
||||
|
||||
Para soportar esto, una *key de task* (tal como :key:`packageSrc`) puede ser el scopde para otra *key* (tal como :key:`packageOptions`).
|
||||
|
||||
Las diferentes *tasks* que construyen un paquete (:key:`packageSrc`,
|
||||
:key:`packageBin`, :key:`packageDoc`) pueden compartir *keys* relacionadas al empaquetamiento,
|
||||
tales como :key:`artifactName` y :key:`packageOptions`. Dichas *keys* pueden tener distintos valores para cada
|
||||
*task* de empaquetamiento.
|
||||
|
||||
Scope global
|
||||
------------
|
||||
|
||||
Cada eje de scope puede llenarse con una instancia del tipo de eje (por ejemplo
|
||||
el eje de *task* puede llevarse con una *task*), o el eje puede llenarse con el
|
||||
valor especial `Global`.
|
||||
|
||||
`Global` significa lo que usted espera: el valor del *setting* aplica a todas
|
||||
las instancias de ese eje. Por ejemplo, si el eje de la *task* es `Global`,
|
||||
entonces dicho *setting* aplicaría a todas las *tasks*.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Delegation
|
||||
----------
|
||||
|
||||
A scoped key may be undefined, if it has no value associated with it in
|
||||
its scope.
|
||||
|
||||
For each scope, sbt has a fallback search path made up of other scopes.
|
||||
Typically, if a key has no associated value in a more-specific scope,
|
||||
sbt will try to get a value from a more general scope, such as the
|
||||
`Global` scope or the entire-build scope.
|
||||
|
||||
This feature allows you to set a value once in a more general scope,
|
||||
allowing multiple more-specific scopes to inherit the value.
|
||||
|
||||
You can see the fallback search path or "delegates" for a key using the
|
||||
`inspect` command, as described below. Read on.
|
||||
|
||||
Referring to scoped keys when running sbt
|
||||
-----------------------------------------
|
||||
|
||||
On the command line and in interactive mode, sbt displays (and parses)
|
||||
scoped keys like this:
|
||||
|
||||
.. code-block:: text
|
||||
|
||||
{<build-uri>}<project-id>/config:intask::key
|
||||
|
||||
- `{<build-uri>}<project-id>` identifies the project axis. The
|
||||
`<project-id>` part will be missing if the project axis has "entire
|
||||
build" scope.
|
||||
- `config` identifies the configuration axis.
|
||||
- `intask` identifies the task axis.
|
||||
- `key` identifies the key being scoped.
|
||||
|
||||
`*` can appear for each axis, referring to the `Global` scope.
|
||||
|
||||
If you omit part of the scoped key, it will be inferred as follows:
|
||||
|
||||
- the current project will be used if you omit the project.
|
||||
- a key-dependent configuration will be auto-detected if you omit the
|
||||
configuration or task.
|
||||
|
||||
For more details, see :doc:`/Detailed-Topics/Inspecting-Settings`.
|
||||
|
||||
Examples of scoped key notation
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
- :key:`fullClasspath` specifies just a key, so the default scopes are used:
|
||||
current project, a key-dependent configuration, and global task
|
||||
scope.
|
||||
- `test:fullClasspath` specifies the configuration, so this is
|
||||
:key:`fullClasspath` in the `test` configuration, with defaults for
|
||||
the other two scope axes.
|
||||
- `*:fullClasspath` specifies `Global` for the configuration,
|
||||
rather than the default configuration.
|
||||
- `doc::fullClasspath` specifies the :key:`fullClasspath` key scoped
|
||||
to the `doc` task, with the defaults for the project and
|
||||
configuration axes.
|
||||
- `{file:/home/hp/checkout/hello/}default-aea33a/test:fullClasspath`
|
||||
specifies a project,
|
||||
`{file:/home/hp/checkout/hello/}default-aea33a`, where the project
|
||||
is identified with the build `{file:/home/hp/checkout/hello/}` and
|
||||
then a project id inside that build `default-aea33a`. Also
|
||||
specifies configuration `test`, but leaves the default task axis.
|
||||
- `{file:/home/hp/checkout/hello/}/test:fullClasspath` sets the
|
||||
project axis to "entire build" where the build is
|
||||
`{file:/home/hp/checkout/hello/}`
|
||||
- `{.}/test:fullClasspath` sets the project axis to "entire build"
|
||||
where the build is `{.}`. `{.}` can be written `ThisBuild` in
|
||||
Scala code.
|
||||
- `{file:/home/hp/checkout/hello/}/compile:doc::fullClasspath` sets
|
||||
all three scope axes.
|
||||
|
||||
Inspecting scopes
|
||||
-----------------
|
||||
|
||||
In sbt's interactive mode, you can use the `inspect` command to
|
||||
understand keys and their scopes. Try `inspect test:fullClasspath`:
|
||||
|
||||
.. code-block:: text
|
||||
|
||||
$ sbt
|
||||
> inspect test:fullClasspath
|
||||
[info] Task: scala.collection.Seq[sbt.Attributed[java.io.File]]
|
||||
[info] Description:
|
||||
[info] The exported classpath, consisting of build products and unmanaged and managed, internal and external dependencies.
|
||||
[info] Provided by:
|
||||
[info] {file:/home/hp/checkout/hello/}default-aea33a/test:fullClasspath
|
||||
[info] Dependencies:
|
||||
[info] test:exportedProducts
|
||||
[info] test:dependencyClasspath
|
||||
[info] Reverse dependencies:
|
||||
[info] test:runMain
|
||||
[info] test:run
|
||||
[info] test:testLoader
|
||||
[info] test:console
|
||||
[info] Delegates:
|
||||
[info] test:fullClasspath
|
||||
[info] runtime:fullClasspath
|
||||
[info] compile:fullClasspath
|
||||
[info] *:fullClasspath
|
||||
[info] {.}/test:fullClasspath
|
||||
[info] {.}/runtime:fullClasspath
|
||||
[info] {.}/compile:fullClasspath
|
||||
[info] {.}/*:fullClasspath
|
||||
[info] */test:fullClasspath
|
||||
[info] */runtime:fullClasspath
|
||||
[info] */compile:fullClasspath
|
||||
[info] */*:fullClasspath
|
||||
[info] Related:
|
||||
[info] compile:fullClasspath
|
||||
[info] compile:fullClasspath(for doc)
|
||||
[info] test:fullClasspath(for doc)
|
||||
[info] runtime:fullClasspath
|
||||
|
||||
On the first line, you can see this is a task (as opposed to a setting,
|
||||
as explained in :doc:`.sbt build definition <Basic-Def>`).
|
||||
The value resulting from the task will have type
|
||||
`scala.collection.Seq[sbt.Attributed[java.io.File]]`.
|
||||
|
||||
"Provided by" points you to the scoped key that defines the value, in
|
||||
this case
|
||||
`{file:/home/hp/checkout/hello/}default-aea33a/test:fullClasspath`
|
||||
(which is the :key:`fullClasspath` key scoped to the `test`
|
||||
configuration and the `{file:/home/hp/checkout/hello/}default-aea33a`
|
||||
project).
|
||||
|
||||
"Dependencies" may not make sense yet; stay tuned for the :doc:`next page <More-About-Settings>`.
|
||||
|
||||
You can also see the delegates; if the value were not defined, sbt would
|
||||
search through:
|
||||
|
||||
- two other configurations (`runtime:fullClasspath`,
|
||||
`compile:fullClasspath`). In these scoped keys, the project is
|
||||
unspecified meaning "current project" and the task is unspecified
|
||||
meaning `Global`
|
||||
- configuration set to `Global` (`*:fullClasspath`), since project
|
||||
is still unspecified it's "current project" and task is still
|
||||
unspecified so `Global`
|
||||
- project set to `{.}` or `ThisBuild` (meaning the entire build, no
|
||||
specific project)
|
||||
- project axis set to `Global` (`*/test:fullClasspath`) (remember,
|
||||
an unspecified project means current, so searching `Global` here is
|
||||
new; i.e. `*` and "no project shown" are different for the project
|
||||
axis; i.e. `*/test:fullClasspath` is not the same as
|
||||
`test:fullClasspath`)
|
||||
- both project and configuration set to `Global`
|
||||
(`*/*:fullClasspath`) (remember that unspecified task means
|
||||
`Global` already, so `*/*:fullClasspath` uses `Global` for all
|
||||
three axes)
|
||||
|
||||
Try `inspect fullClasspath` (as opposed to the above example,
|
||||
`inspect test:fullClasspath`) to get a sense of the difference.
|
||||
Because the configuration is omitted, it is autodetected as `compile`.
|
||||
`inspect compile:fullClasspath` should therefore look the same as
|
||||
`inspect fullClasspath`.
|
||||
|
||||
Try `inspect *:fullClasspath` for another contrast.
|
||||
:key:`fullClasspath` is not defined in the `Global` configuration by
|
||||
default.
|
||||
|
||||
Again, for more details, see :doc:`/Detailed-Topics/Inspecting-Settings`.
|
||||
|
||||
Referring to scopes in a build definition
|
||||
-----------------------------------------
|
||||
|
||||
If you create a setting in `build.sbt` with a bare key, it will be
|
||||
scoped to the current project, configuration `Global` and task
|
||||
`Global`:
|
||||
|
||||
::
|
||||
|
||||
name := "hello"
|
||||
|
||||
Run sbt and `inspect name` to see that it's provided by
|
||||
`{file:/home/hp/checkout/hello/}default-aea33a/*:name`, that is, the
|
||||
project is `{file:/home/hp/checkout/hello/}default-aea33a`, the
|
||||
configuration is `*` (meaning global), and the task is not shown
|
||||
(which also means global).
|
||||
|
||||
`build.sbt` always defines settings for a single project, so the
|
||||
"current project" is the project you're defining in that particular
|
||||
`build.sbt`. (For :doc:`multi-project builds <Multi-Project>`, each project has its own `build.sbt`.)
|
||||
|
||||
Keys have an overloaded method called `in` used to set the scope. The
|
||||
argument to `in` can be an instance of any of the scope axes. So for
|
||||
example, though there's no real reason to do this, you could set the
|
||||
name scoped to the `Compile` configuration:
|
||||
|
||||
::
|
||||
|
||||
name in Compile := "hello"
|
||||
|
||||
or you could set the name scoped to the :key:`packageBin` task (pointless!
|
||||
just an example):
|
||||
|
||||
::
|
||||
|
||||
name in packageBin := "hello"
|
||||
|
||||
or you could set the name with multiple scope axes, for example in the
|
||||
:key:`packageBin` task in the `Compile` configuration:
|
||||
|
||||
::
|
||||
|
||||
name in (Compile, packageBin) := "hello"
|
||||
|
||||
or you could use `Global` for all axes:
|
||||
|
||||
::
|
||||
|
||||
name in Global := "hello"
|
||||
|
||||
(`name in Global` implicitly converts the scope axis `Global` to a
|
||||
scope with all axes set to `Global`; the task and configuration are
|
||||
already `Global` by default, so here the effect is to make the project
|
||||
`Global`, that is, define `*/*:name` rather than
|
||||
`{file:/home/hp/checkout/hello/}default-aea33a/*:name`)
|
||||
|
||||
If you aren't used to Scala, a reminder: it's important to understand
|
||||
that `in` and `:=` are just methods, not magic. Scala lets you write
|
||||
them in a nicer way, but you could also use the Java style:
|
||||
|
||||
::
|
||||
|
||||
name.in(Compile).:=("hello")
|
||||
|
||||
There's no reason to use this ugly syntax, but it illustrates that these
|
||||
are in fact methods.
|
||||
|
||||
When to specify a scope
|
||||
-----------------------
|
||||
|
||||
You need to specify the scope if the key in question is normally scoped.
|
||||
For example, the :key:`compile` task, by default, is scoped to `Compile`
|
||||
and `Test` configurations, and does not exist outside of those scopes.
|
||||
|
||||
To change the value associated with the :key:`compile` key, you need to
|
||||
write `compile in Compile` or `compile in Test`. Using plain
|
||||
:key:`compile` would define a new compile task scoped to the current
|
||||
project, rather than overriding the standard compile tasks which are
|
||||
scoped to a configuration.
|
||||
|
||||
If you get an error like *"Reference to undefined setting"*, often
|
||||
you've failed to specify a scope, or you've specified the wrong scope.
|
||||
The key you're using may be defined in some other scope. sbt will try to
|
||||
suggest what you meant as part of the error message; look for "Did you
|
||||
mean compile:compile?"
|
||||
|
||||
One way to think of it is that a name is only *part* of a key. In
|
||||
reality, all keys consist of both a name, and a scope (where the scope
|
||||
has three axes). The entire expression
|
||||
`packageOptions in (Compile, packageBin)` is a key name, in other
|
||||
words. Simply :key:`packageOptions` is also a key name, but a different one
|
||||
(for keys with no `in`, a scope is implicitly assumed: current
|
||||
project, global config, global task).
|
||||
|
||||
Next
|
||||
----
|
||||
|
||||
Now that you understand scopes, you can :doc:`learn more about settings <More-About-Settings>`.
|
||||
|
|
@ -0,0 +1,174 @@
|
|||
=============
|
||||
Configuración
|
||||
=============
|
||||
|
||||
Panorama general
|
||||
================
|
||||
|
||||
Para crear un proyecto de sbt, necesitará dar los siguientes pasos:
|
||||
- Instalar sbt y crear un script para iniciarlo.
|
||||
- Configurar un proyecto simple :doc:`hola mundo <Hello>`.
|
||||
|
||||
- Crear un directorio llamado project con archivos de código fuente en él.
|
||||
- Crear su *build definition* (definición de construcción del proyecto).
|
||||
|
||||
- Continuar con :doc:`ejecución <Running>` para aprender a ejecutar sbt.
|
||||
- Enseguida continuar con :doc:`.sbt build definition <Basic-Def>`
|
||||
para aprender más sobre las *build definitions*.
|
||||
|
||||
Instalando sbt
|
||||
==============
|
||||
|
||||
sbt proporciiona varios paquetes para diferentes sistemas operativos, pero también puede hacer una `Instalación manual`_, `Manual Installation`_.
|
||||
|
||||
Paquetes oficialmente soportados:
|
||||
- MSI_ para Windows
|
||||
- Paquetes ZIP_ o TGZ_
|
||||
- Paquete RPM_
|
||||
- Paquete DEB_
|
||||
|
||||
.. note::
|
||||
|
||||
Por favor reporte cualquier problema que se tenga con los paquetes arriba mencionados al projecto `sbt-launcher-package`_.
|
||||
|
||||
**Paquetes de terceros**:
|
||||
- :ref:`Homebrew <homebrew_setup>` o :ref:`Macports <macports_setup>` para `Mac`_
|
||||
- `Gentoo`_ emerge overlays
|
||||
|
||||
.. note::
|
||||
|
||||
Los paquetes de terceros pueden no proporcionar la última versión disponible.
|
||||
Por favor asegúrese de reportar cualquier problema con estos paquetes a los mantenedores respectivos.
|
||||
|
||||
Mac
|
||||
---
|
||||
|
||||
.. _macports_setup:
|
||||
|
||||
`Macports <http://macports.org/>`_
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ port install sbt
|
||||
|
||||
.. _homebrew_setup:
|
||||
|
||||
`Homebrew <http://mxcl.github.com/homebrew/>`_
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ brew install sbt
|
||||
|
||||
Gentoo
|
||||
------
|
||||
|
||||
En el árbol oficial no hay ebuild para sbt. Pero existen ebuilds para
|
||||
hacer un *merge* de sbt a partir de los binarios:
|
||||
https://github.com/whiter4bbit/overlays/tree/master/dev-java/sbt-bin. Para
|
||||
hacer un merge de sbt a partir de estos ebuilds, puede hacer lo siguiente:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ mkdir -p /usr/local/portage && cd /usr/local/portage
|
||||
$ git clone git://github.com/whiter4bbit/overlays.git
|
||||
$ echo "PORTDIR_OVERLAY=$PORTDIR_OVERLAY /usr/local/portage/overlays" >> /etc/make.conf
|
||||
$ emerge sbt-bin
|
||||
|
||||
.. note::
|
||||
|
||||
Por favor reporte cualquier problema con el ebuild `aquí <https://github.com/whiter4bbit/overlays/issues>`_.
|
||||
|
||||
.. _manual installation:
|
||||
|
||||
Instalación manual
|
||||
------------------
|
||||
|
||||
La instalación manual requiere la descarga de `sbt-launch.jar`_ y la creación de un script para ejecutarlo.
|
||||
|
||||
|
||||
Unix
|
||||
~~~~
|
||||
|
||||
Ponga `sbt-launch.jar`_ en `~/bin`.
|
||||
|
||||
Cree un script para ejecutar el jar, mediante la creación de `~/bin/sbt` con el siguiente contenido:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
SBT_OPTS="-Xms512M -Xmx1536M -Xss1M -XX:+CMSClassUnloadingEnabled -XX:MaxPermSize=256M"
|
||||
java $SBT_OPTS -jar `dirname $0`/sbt-launch.jar "$@"
|
||||
|
||||
Haga el script ejecutable con:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ chmod u+x ~/bin/sbt
|
||||
|
||||
Windows
|
||||
~~~~~~~
|
||||
|
||||
La instalación manual para Windows varía según el tipo de terminal y dependiendo de si Cygwin es usado o no.
|
||||
En todos los casos, ponga el archivo batch o el script en el *path* de modo que pueda iniciar `sbt`
|
||||
en cualquier directorio mediante teclear `sbt` en la línea de comandos. También, ajuste los settings de la
|
||||
JVM de acuerdo con su máquina si es necesario.
|
||||
|
||||
Para **usuarios que no utilizan Cygwin, pero que usan la terminal standard de Windows**, cree un archivo batch `sbt.bat`:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
set SCRIPT_DIR=%~dp0
|
||||
java -Xms512M -Xmx1536M -Xss1M -XX:+CMSClassUnloadingEnabled -XX:MaxPermSize=256M -jar "%SCRIPT_DIR%sbt-launch.jar" %*
|
||||
|
||||
y ponga el `sbt-launch.jar`_ que descargó en el mismo directorio que archivo batch.
|
||||
|
||||
Si utiliza **Cygwin con la terminal standard de Windows**, cree un script de bash `~/bin/sbt`:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
SBT_OPTS="-Xms512M -Xmx1536M -Xss1M -XX:+CMSClassUnloadingEnabled -XX:MaxPermSize=256M"
|
||||
java $SBT_OPTS -jar sbt-launch.jar "$@"
|
||||
|
||||
Reemplace `sbt-launch.jar` con la ruta hasta el `sbt-launch.jar`_ que descargó y recuerde utilizar `cygpath` si es necesario.
|
||||
Haga el scrip ejecutable con:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ chmod u+x ~/bin/sbt
|
||||
|
||||
Si utiliza **Cygwin con una terminal Ansi** (que soporte secuentas de escape Ansi y que sea configurable mediante `stty`), cree un script `~/bin/sbt`:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
SBT_OPTS="-Xms512M -Xmx1536M -Xss1M -XX:+CMSClassUnloadingEnabled -XX:MaxPermSize=256M"
|
||||
stty -icanon min 1 -echo > /dev/null 2>&1
|
||||
java -Djline.terminal=jline.UnixTerminal -Dsbt.cygwin=true $SBT_OPTS -jar sbt-launch.jar "$@"
|
||||
stty icanon echo > /dev/null 2>&1
|
||||
|
||||
Reemplace `sbt-launch.jar` con la ruta hasta el `sbt-launch.jar`_ que descargó y recuerde utilizar `cygpath` si es necesario.
|
||||
Entonces, haga que el script sea ejecutable con:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ chmod u+x ~/bin/sbt
|
||||
|
||||
Para que la tecla *backspace* funcione correctamente en la consola de scala, necesita asegurarse de que dicha tecla esté enviando el caracter de borrado, de acuerdo a la configuración de stty.
|
||||
Para la terminal por default de cygwin (mintty) puede encontrar una configuración en Options -> Keys "Backspace sends ^H" que necesitará estar palomeada si su tecla de borrado envía el caracter por default de cygwin ^H.
|
||||
|
||||
.. note::
|
||||
|
||||
Otras configuraciones no están actualmente soportadas.
|
||||
Por favor envíe `pull requests <https://github.com/sbt/sbt/blob/0.13/CONTRIBUTING.md>`_ implementando o describiendo dicho soporte.
|
||||
|
||||
Tips y notas
|
||||
==============
|
||||
|
||||
Si tiene algún problema ejecutando sbt, vea :doc:`/Detailed-Topics/Setup-Notes` en las codificaciones de la
|
||||
terminal, HTTP proxies, y opciones de la JVM.
|
||||
|
||||
Siguiente
|
||||
=========
|
||||
|
||||
Continúe :doc:`creando un projecto simple <Hello>`.
|
||||
|
||||
|
|
@ -0,0 +1,32 @@
|
|||
==============
|
||||
Bienvenido(a)!
|
||||
==============
|
||||
|
||||
Esta Guía de inicio le ayudará a empezar con sbt.
|
||||
|
||||
sbt usa un número pequeño de conceptos para soportar *build definitions* (definiciones de construcción de software)
|
||||
flexibles y poderosas. No hay tantos conceptos, pero sbt no es exactamente como cualquier otro sistema de
|
||||
construcción de sofware y hay detalles con los que *usted tropezará* si no ha leído la documentación.
|
||||
|
||||
La Guía de inicio cubre los conceptos que usted necesita para crear
|
||||
y mantnere una *build definition*.
|
||||
|
||||
¡Es *altamente recomendable* leer la Guía de inicio!
|
||||
|
||||
Si usted tiene mucha prisa, los conceptos más importantes pueden encontrarse en
|
||||
:doc:`sbt build definition <Basic-Def>`,
|
||||
:doc:`scopes <Scopes>`, y :doc:`más sobre settings <More-About-Settings>`.
|
||||
Pero no prometemos que sea una buena idea dejar de leer las otras páginas de la guía.
|
||||
|
||||
Es mejor leer en orden, ya que las páginas posteriores de la Guía de inicio
|
||||
utilizan conceptos introducidos con anterioridad.
|
||||
|
||||
La Guía inicia con :doc:`Configuración <Setup>`.
|
||||
|
||||
Gracias por utilizar sbt *¡Diviértase!*
|
||||
|
||||
Traducciones a otros lenguajes
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
- `Japonés <http://scalajp.github.com/sbt-getting-started-guide-ja/>`_
|
||||
- Inglés
|
||||
|
|
@ -0,0 +1,52 @@
|
|||
===
|
||||
sbt
|
||||
===
|
||||
|
||||
.. toctree::
|
||||
:hidden:
|
||||
|
||||
index
|
||||
|
||||
sbt es una herramienta de construcción para Scala, Java, y `más <https://github.com/d40cht/sbt-cpp>`_.
|
||||
Requiere Java 1.6 o posterior.
|
||||
|
||||
Instalación
|
||||
-----------
|
||||
|
||||
Vea las :doc:`instrucciones de instalación </Getting-Started/Setup>`.
|
||||
|
||||
Características
|
||||
---------------
|
||||
|
||||
- Poca o ninguna configuración requerida para proyectos simples.
|
||||
- doc:`build definition </Getting-Started/Basic-Def>` basada en Scala que puede utilizar la flexibilidad completa del código de Scala.
|
||||
- Recompilación incremental precisa usando la información extraída del compilador.
|
||||
- Compilación y *testing* continuos con :doc:`triggered execution </Detailed-Topics/Triggered-Execution>`
|
||||
- Empaqueta y publica jars.
|
||||
- Genera documentación con scaladoc.
|
||||
- Soporta proyectos mixtos de Scala/:doc:`Java </Detailed-Topics/Java-Sources>`.
|
||||
- Soporta :doc:`testing </Detailed-Topics/Testing>` con ScalaCheck, specs, y ScalaTest. JUnit es soportado con un plugin.
|
||||
- Inicia una sesión de Scala REPL (*Read-Eval-Print-Loop*) con las clases del proyecto y dependencias en el classpath.
|
||||
- Modularización soportada con :doc:`sub-proyectos </Getting-Started/Multi-Project>`.
|
||||
- Soporte para proyectos externos (¡enliste un repositorio de git como una dependencia!).
|
||||
- :doc:`Parallel task execution </Detailed-Topics/Parallel-Execution>` (ejecución de tareas en paralelo), incluyendo ejecución de *tests* (pruebas) en paralelo.
|
||||
- :doc:`Soporte para manejo de dependencias (librerías) </Getting-Started/Library-Dependencies>`:
|
||||
declaraciones *inline*, archivos de configuración externos de Ivy o Maven, o manejo manual de dependencias.
|
||||
|
||||
Iniciando
|
||||
---------
|
||||
|
||||
Para iniciar, *por favor lea* la :doc:`Guía para empezar </Getting-Started/Welcome>`.
|
||||
Se ahorrará *mucho* tiempo si tiene una compresión correcta del panorama general de antemano.
|
||||
Toda la documentación puede encontrarse vía la :doc:`tabla de contenidos <index>`.
|
||||
|
||||
Utilice `Stack Overflow <http://stackoverflow.com/tags/sbt>`_ para preguntar.
|
||||
Use la `sbt-dev mailing list`_ para discutir el desarrollo de sbt.
|
||||
Utilice el canal #sbt de irc para preguntas y discusiones.
|
||||
|
||||
Puede hacer un *fork* de esta documentación en `GitHub <https://github.com/sbt/sbt/>`_.
|
||||
Siéntase libre de hacer correcciones y añadiduras a la documentación. El código fuente de esta documentación está localizado en
|
||||
el subdirectorio `src/sphinx` del proyecto de Github.
|
||||
|
||||
La documentación para la versión 0.7.x ha sido `archivada aquí <http://www.scala-sbt.org/0.7.7/docs/home.html>`_.
|
||||
Esta documentación sirve para la versión |version| de sbt.
|
||||
Loading…
Reference in New Issue