Solo para versiones superiores a la 7.0.0-zelda

Introducción

A partir de la versión 7.0.0-zelda de la Onesait Platform se ha realizado una refactorización del código:

Se ha separado todo el código referente a las APIs de gestión de los elementos de Plataforma a un nuevo módulo Management APIs.
Se ha creado una nueva librería Management Libs
Se ha limpiado el código del Control Panel

En este post puede encontrar una guía de buenas prácticas a la hora de desarrollar a partir de esta versión de Plataforma y cómo solucionar los conflictos que puedan surgir cuando estés trabajando en ramas anteriores y quieras llevarte los cambios a ramas superiores a la 7.0.0-zelda.

Antes de empezar

Cuando estés trabajando en una rama posterios a la 7.0.0-zelda es necesario borrar la tabla configuration y lanzar el configinit, o en su defecto modificar manualmente el EndpointModules.

Buenas prácticas

Para versiones superiores a la 7.0.0-zelda hay que tener las siguientes consideraciones a la hora de desarrollar:

Se han eliminado todas las APIs de gestión del Control Panel, por lo que ahora en el Control Panel sólo deberán ir:
1. Controladores web
2. Beans de configuración
3. HTMLs
4. Javascripts
5. CSS
6. Estáticos
Se ha creado un nuevo módulo Management APIs para las APIs de gestión que antes estaban en el Control Panel, por lo que ahora en este módulo deberán ir:
1. Controladores REST
2. Beans de Configuración
Se ha creado una nueva librería Management Libs que se inyecta tanto en el Control Panel como en el Management APIs. En esta librería se han metido todas las clases que son utilizadas en los dos módulos y que no puedan o no tenga sentido meter en las librerías ya existentes. Hay que tener en cuenta que lo ideal es intentar meter las clases comunes en librerías ya existentes como el Config Service.

Flowengine, Notebooks y Dataflow

Para el caso del Flowengine, Notebooks y Dataflow la refactorización ha sido más particular, ya que no se han podido llevar directamente las APIs de gestión de estos conceptos directamente al Management APIs por tener dependencia con clases comunes a los controladores del Control Panel.

En este caso lo que se ha hecho ha sido:

Crear dentro del módulo Management Libs los servicios con toda la lógica de negocio.
En los controladores del Control Panel y en las APIs de gestión del Management APIs se han inyectado estos beans y se utilizan los servicios para redirigir todas las llamadas a los servicios correspondientes.

Cómo levantar Keycloak en local

A partir de la versión 7.0.0-zelda para arrancar keycloak en local habrá que seguir esta guía: ¿Cómo levantar Keycloak como Identity Manager en Entorno local? como hasta ahora, el único cambio es que cuando llegue el momento de arrancar el Keycloak Manager, ahora hay que levantar primero el módulo Management APIs en vez del Control Panel.

Resolución de conflictos

Cuando estés resolviendo una issue en una rama anterior a la 7.0.0-zelda tendrás que seguir los siguientes pasos, por ejemplo si estás resolviendo una issue en la rama 6.2.1-xenon y te quieres llevar los cambios hasta la rama develop:

Crear rama desde la versión 6.2.1-xenon y resolver la issue en esa rama
Llevarte los cambios a las ramas 6.2.1-xenon, 6.3.0-yoshi, 6.3.1-yoshi, 7.0.0-zelda
El siguiente merge sería a develop (o a la siguiente rama correspondiente), lo mejor es que a partir de aquí hagas los merges desde línea de comandos para evitar problemas con los merges automáticos:

git checkout develop
git pull origin develop
git merge release/7.0.0-zelda

Con las líneas de comando anterior lo que estás haciendo es cambiarte a la rama develop y actualizarla y mergear el código de la rama release/7.0.0-zelda en tu rama local

Es importante que el merge lo hagas directamente sobre la rama develop, ya que si se hace una rama intermedia Git luego no identifica que se han resuelto los conflictos y te tocará volver a resolverlos una y otra vez

Ahora es bastante probable que te aparezcan conflictos, ya que hay clases que se han eliminado del Control Panel y se han distribuido en otros módulos, entre ellos el nuevo módulo de apis de gestión.

Uno de los conflictos que es posible que aparezca será de este estilo:

Donde se puede ver que ha habido un cambio en la clase CacheRestController.java. Esta clase en la rama 7.0.0-zelda estaba en el control-panel pero en la siguiente versión se ha borrado del control-panel y se ha añadido al módulo management-apis.

Cuando te encuentres este tipo de conflictos tendrás que:

Abrir en el eclipse el archivo en cuestión que se ha movido, en este caso el CacheRestController.java, te deberá aparecer marcada la clase que se ha eliminado del controlpanel y la clase que se ha movido al management-apis

Abrimos ambos archivos y tendremos que comparar los cambios y llevarnoslos de la clase del control-panel a la clase de management-apis. Teniendo especial cuidado, ya que los conflictos en la clase de management-apis no van a salir marcados, por lo que tendremos que llevarnoslos a mano.
Una vez nos hemos llevado los cambios a la clase del management-apis, lanzamos un git status desde línea de comandos y veremos que aparece marcado que se va a borrar la clase del control-panel y que está modificada la clase del management-apis:

Si hacemos ahora un git add * meterá nuestros cambios de la clase de management-apis pero no va a eliminar la clase del control-panel, lo cual estaría mal. Por lo que el siguiente paso es eliminar manualmente la clase del control-panel (y el paquete si aplica) directamente desde el eclipse.

Añadimos todos los cambios con un git add * (o solo los ficheros que queramos añadir, teniendo especial cuidado de añadir tanto el borrado de la clase del control-panel como las modificaciones de la clase en mangement-apis)

Una vez resueltos todos los conflictos lanzamos un git commit para terminar el merge. Una vez terminado el merge tendremos que:
1. Compilar desde la raíz
2. Probar que no se ha roto nada y que todo sigue funcionando correctamente, para ello tendremos que levantar en local los módulos correspondientes y probar tanto la funcionalidad de las clases que nos han dado conflicto cómo nuestros bugs/desarrollos.

Lo último sería mergear nuestra rama sacada de develop a develop ya con todos los conflictos resueltos.