Este SDK utiliza Java 1.8. Para compilar se debe tener el JDK 1.8 y Apache Maven 3.X
Para compilar basta con el target package:
mvn package
Esto generará un jar bajo el directorio target con el código de la librería.
Para ejecutar localmente el proyecto y probarlo junto al repositorio de ejemplo debe ejecutar las siguientes líneas.
Remplace <DIR> por el directorio donde clono el repositorio y <VERSION> por el que corresponda a la versión clonada según sea el caso, donde <VERSION> dependerá de lo especificado en la etiqueta version del archivo pom.xml, busque la línea con el código similar a <version>X.X.X-SNAPSHOT</version>.
mvn compile && mvn package && mvn install:install-file \
-Dfile=/<DIR>/transbank-pos-sdk-java/target/transbank-sdk-pos-java-<VERSION>.jar \
-DgroupId=com.github.transbankdevelopers \
-DartifactId=transbank-sdk-pos-java \
-Dversion=<VERSION> \
-Dpackaging=jar \
-DgeneratePom=true
Puedes encontrar toda la documentación de cómo usar este SDK en el sitio https://www.transbankdevelopers.cl.
La documentación relevante para usar este SDK es:
- Documentación general sobre los productos y sus diferencias: POSIntegrado
- Primeros pasos con POSIntegrado.
- Primeros pasos con POSAutoservicio.
- Referencia detallada sobre POSIntegrado.
- Para los commits respetamos las siguientes normas: https://chris.beams.io/posts/git-commit/
- Usamos ingles, para los mensajes de commit.
- Se pueden usar tokens como WIP, en el subject de un commit, separando el token con
:
, por ejemplo:WIP: This is a useful commit message
- Para los nombres de ramas también usamos ingles.
- Se asume, que una rama de feature no mezclada, es un feature no terminado.
- El nombre de las ramas va en minúsculas.
- Las palabras se separan con
-
. - Las ramas comienzan con alguno de los short lead tokens definidos, por ejemplo:
feat/tokens-configuration
- WIP = Trabajo en progreso.
- feat = Nuevos features
- chore = Tareas, que no son visibles al usuario.
- bug = Resolución de bugs.
Para generar una nueva versión, se debe crear un PR (con un título "Prepare release X.Y.Z" con los valores que correspondan para X
, Y
y Z
). Se debe seguir el estándar semver para determinar si se incrementa el valor de X
(si hay cambios no retrocompatibles), Y
(para mejoras retrocompatibles) o Z
(si sólo hubo correcciones a bugs).
En ese PR deben incluirse los siguientes cambios:
- Modificar el archivo
CHANGELOG.md
para incluir una nueva entrada (al comienzo) paraX.Y.Z
que explique en español los cambios de cara al usuario del SDK. - Modificar
pom.xml
para que <Version
> seaX.Y.{Z+1}
(de manera que los pre-releases que se generen después del release sean de la siguiente versión).
Luego de obtener aprobación del pull request, debe mezclarse a master e inmediatamente generar un release en GitHub con el tag vX.Y.Z
. En la descripción del release debes poner lo mismo que agregaste al changelog.