Muestra las diferencias entre dos versiones de la página.
plugins:microcomponents [2020/02/21 15:03] fcristina [Exportando un componente] |
plugins:microcomponents [2021/04/30 19:19] |
||
---|---|---|---|
Línea 1: | Línea 1: | ||
- | ====== Soporte para desarrollo de microcomponentes ====== | ||
- | |||
- | Las modificaciones aquí detalladas aplican tanto para el desarrollo de micro componentes como para componentes tradicionales. | ||
- | |||
- | ===== Definición general ===== | ||
- | |||
- | Micro componentes refiere a desarrollos con tiempo de vida acotado, encapsulando modificaciones de LY CORE específicamente (CORELEVEL = 0), sobre una base de datos independiente y un proyecto en Eclipse independiente que referencia a org.libertya y que modifica clases de CORE exclusivamente. | ||
- | |||
- | Los micro componentes nacen de requerimientos para LY CORE o bien a partir de necesidades de modificaciones de CORE sobre una instancia en producción de un cliente en particular; pero que luego estos cambios eventualmente serán parte de LY Standard (bbdd libertya_core y proyecto org.libertya). | ||
- | |||
- | Un micro componente implica: | ||
- | |||
- | * Ítem de lista desordenadaCreación de una BBDD exclusiva para su desarrollo y de un componente (con CORELEVEL 0) con un prefijo que denote la finalidad del desarrollo | ||
- | * Ítem de lista desordenadaCreacion de un proyecto en Eclipse que referencia a org.libertya y solo modifica clases de CORE (además del preinstall, etc). | ||
- | |||
- | Los micro componentes se incorporarán a LY Standard cuando se considere necesario, mediante merge de fuentes y el uso de COPYTOCHANGELOG para metadatos. Los UIDs serán únicos desde el momento de su creación y para siempre, bajo una nueva definición de los mismos. Por consiguiente bajo la nueva metodología, | ||
- | |||
- | Una instancia en producción que requiera actualizar su versión de CORE y que tenga micro componentes necesitará “certificar” la instancia en cuestión, realizando los merges necesarios si es que dichos micro componentes deben mantenerse en la instancia. | ||
- | |||
- | Cabe destacar la diferencia de una redefinición específica de una clase de CORE alojada en un componente tradicional (plugin de customización) con respecto a los desarrollos en un micro componente. | ||
- | |||
- | |||
- | ===== Nueva ventana para prefijos de micro componentes ===== | ||
- | |||
- | Existe una nueva ventana **Prefijos de Micro Componentes** para la reserva de prefijos. | ||
- | |||
- | Los prefijos tendran una longitud de 10 caracteres y deberán ser únicos. | ||
- | |||
- | La descripción que acompaña al prefijo deberá ser una intuitiva, a fin de dar una idea sobre la funcionalidad y alcance del micro componente que se está desarrollando. | ||
- | |||
- | Estos prefijos luego se referencian desde la ventana de Componentes. | ||
- | |||
- | ===== Desarrollando un micro componente ===== | ||
- | |||
- | El inicio del desarrollo es similar al desarrollo de un componente tradicional. | ||
- | |||
- | Sin embargo, si al iniciar el desarrollo se detectan entradas en la bitácora (AD_Changelog) registradas para este micro componente, se presentará un warning a modo de aviso, indicando que ya hubo desarrollo previo para dicho micro componente, por ejemplo: | ||
- | |||
- | WARNING: Existes 3675 entradas en el changelog con el prefijo de microcomponente EXAMPLE | ||
- | |||
- | |||
- | ===== Nuevo formato para AD_ComponentObjectUID ===== | ||
- | |||
- | El nuevo formato de los **AD_ComponentObjectUID** se conforma de la siguiente manera: | ||
- | |||
- | * Prefijo del micro componente | ||
- | * Nombre de tabla | ||
- | * Timestamp | ||
- | * 6 dígitos adicionales: | ||
- | |||
- | Esto garantiza unicidad ante cualquier tipo de desarrollo en paralelo. | ||
- | |||
- | ABCDEFGHIJ-AD_Message-20191206142716886-780778 | ||
- | |||
- | Este valor **no cambiará nunca**, y se mantendrá el mismo al momento de incorpora el desarrollo del micro componente a CORE (mediante [[plugins: | ||
- | |||
- | |||
- | ===== Nuevas columnas en AD_Changelog ===== | ||
- | |||
- | Se incorporan dos nuevas columnas en **AD_Changelog**: | ||
- | |||
- | * **ChangeLogUID**: | ||
- | * **ChangeLogGroupUID**: | ||
- | |||
- | Gracias a dichos campos UID, es posible tener un seguimiento a un desarrollo de un micro componente más allá de la evolución de los IDs del master de libertya_core, | ||
- | |||
- | Esta será la información relevante al exportar el micro componente y al instalarlo. | ||
- | |||
- | Para dar un ejemplo, la información resultante a guardar en la tabla AD_ChangeLog ante la creación de un registro en la tabla de mensajes será (además de otros campos): | ||
- | |||
- | * AD_ChangeLog_ID: | ||
- | * ChangeLogGroupID: | ||
- | * ChangeLogUID: | ||
- | * ChangeLogGroupUID: | ||
- | * AD_Column_ID: | ||
- | * AD_ComponentObjectUID: | ||
- | * NewValue: **Insertando un nuevo mensaje de ejemplo** | ||
- | |||
- | Incluso luego de instalado en el master de Libertya, la información de los campos **ChangeLogUID** y **ChangeLogGroupUID** es rastreable hasta la BBDD de desarrollo del micro componente **ABCDEFGHIJ**. | ||
- | |||
- | ===== Exportando un componente ===== | ||
- | |||
- | Al exportar un componente, se incorporará la siguiente información (en negro la nueva información): | ||
- | |||
- | # Manifest del plugin El abecedario loco | ||
- | VERSION = 1 | ||
- | PREFIX = ABCDEFGHIJ | ||
- | PACKAGENAME = org.libertya.core.micro.r1234.abcdario | ||
- | PUBLICNAME = Micro componente de ejemplo | ||
- | AUTHOR = null | ||
- | CORELEVEL = 0 | ||
- | MICROCOMPONENT = Y | ||
- | FIRST_CHANGELOG = 2449355 | ||
- | LAST_CHANGELOG = 2449420 | ||
- | FIRST_CHANGELOG_UID = ABCDEFGHIJ-2449355 | ||
- | LAST_CHANGELOG_UID = ABCDEFGHIJ-2449420 | ||
- | FIRST_CHANGELOG_GROUP_UID = ABCDEFGHIJ-1234859 | ||
- | LAST_CHANGELOG_GROUP_UID = ABCDEFGHIJ-1234863 | ||
- | EXPORT_TIMESTAMP = 2019/ | ||
- | | ||
- | # AUTOGENERADO - NO MODIFICAR | ||
- | COMPONENTUID = ABCDEFGHIJ-AD_Component-1010188 | ||
- | COMPONENTVERSIONUID = ABCDEFGHIJ-AD_ComponentVersion-1010202 | ||
- | | ||
- | # DESCOMENTAR SI SE DESEA INCORPORAR A OTRO COMPONENTE (POR EJEMPLO CORE). INDICAR COMPONENT Y COMPONENTVERSION ADECUADOS! | ||
- | # COPYTOCHANGELOG = Y | ||
- | # MAPTOCOMPONENTUID = | ||
- | # MAPTOCOMPONENTVERSIONUID = | ||
- | # DESCOMENTAR SI SE DESEA MAPEAR LOS AD_ComponentObjectUIDs (ejemplo FOO2CORE) EN COPYTOCHANGELOG. DESACTIVADO POR DEFECTO (MICROCOMPONENTS YA NO LO UTILIZA) | ||
- | # MAPUIDS = Y | ||
- | |||
- | La semántica de los campos es la siguiente: | ||
- | |||
- | ^ Campo ^ Descripción | ||
- | | MICROCOMPONENT | Indica si el desarrollo es de tipo micro componente (Y / N). Por el momento solo es información de referencia, pero eventualmente podría ser de utilidad para otras funcionalidades. | | ||
- | | FIRST_CHANGELOG_UID | Valor del primer registro de la columna ChangeLogUID exportado. | ||
- | | LAST_CHANGELOG_UID | Valor del último registro de la columna ChangeLogUID exportado. | ||
- | Esta es la real referencia de instalación para saber qué rango de changelogs del micro componente contiene el archivo .jar. | | ||
- | | FIRST_CHANGELOG_GROUP_UID | Valor del primer registro de la columna ChangeLogGroupUID exportado. | ||
- | Esta es la real referencia de instalación para saber qué rango de changeloggroupss del micro componente contiene el archivo .jar. | | ||
- | | LAST_CHANGELOG_GROUP_UID | Valor del último registro de la columna ChangeLogGroupUID exportado. | ||
- | Esta es la real referencia de instalación para saber qué rango de changeloggroupss del micro componente contiene el archivo .jar | | ||
- | | COPYTOCHANGELOG | Indica si se desea copiar el changelog al insertar. | ||
- | Si bien ya existía funcionalidad relacionada con este campo, ahora al exportar un componente, ya se inserta (comentado) en el manifest. | | ||
- | | MAPTOCOMPONENTUID | Indica si se desea mapear el desarrollo a un component específico. | ||
- | Si bien ya existía funcionalidad relacionada con este campo, ahora al exportar un componente, ya se inserta (comentado) en el manifest. | | ||
- | | MAPTOCOMPONENTVERSIONUID | Indica si se desea copiar el changelog a un componentversion. | ||
- | Si bien ya existía funcionalidad relacionada con este campo, ahora al exportar un componente, ya se inserta (comentado) en el manifest. | | ||
- | | MAPUIDS | Permite especificar si se desea mapear los UIDs (ejemplo FOO2CORE) o no. Bajo la nueva lógica de micro components, esto ya no es necesario, y por lo tanto la lógica por defecto se encuentra desactivada. | ||
- | |||