Pasos de Migración para IPF-2024.1.0

Requisitos previos

El 2024.1.0 la versión ha sido actualizada a Java 17 y MPS v2022.3.1. Debe asegurarse de tener estas versiones disponibles e instaladas antes de actualizar.

Antes de comenzar

Preparación de los azulejos

Como parte de la actualización, le recomendamos que adopte el nuevo enfoque de mosaicos para la configuración de DSL. Para ello, deberá poder proporcionar los nombres del modelo y de la solución para su proyecto. Estos se pueden encontrar consultando su MPS proyecto:

En la captura de pantalla anterior, el nombre de la solución es com.iconsolutions.migrationsolution y el nombre del modelo es com.iconsolutions.migrationmodel. Asegúrese de recordar incluir un nombre de paquete si está definido (como el com.iconsolutions aquí), y tenga en cuenta que la distinción entre mayúsculas y minúsculas es importante.

Puede copiar directamente los nombres de la solución y del modelo haciendo clic derecho sobre ellos en MPS.

Java Eliminación de 11 referencias

Cualquier codificación fija Java Se deben eliminar 11 referencias en el pom antes de iniciar el proceso de migración, por ejemplo:

<properties>
    <maven.compiler.source>11</maven.compiler.source>
    <maven.compiler.target>11</maven.compiler.target>
    <maven.compiler.release>11</maven.compiler.release>
</properties>

Base Docker actualización de imagen

Cualquier imagen de aplicación ahora debe construirse sobre una base de JDK 17. Cualquier referencia a una imagen base de JDK 11 (por ejemplo,openjdk:11) en docker la generación de imágenes debe actualizarse a una versión de JDK 17 (por ejemplo,ubi8-minimal-openjdk-17:latest)

Migrar a la nueva `ipf-bom`

Como parte de la 2024.1.0 lanzamiento, hemos implementado un nuevo ipf-bom, que proporciona acceso a todas las utilidades de IPF en un solo lugar. Le recomendamos que cambie a utilizar este BOM como parte del proceso de migración. Por ejemplo, si el padre actual de su proyecto es ipf-release-core-bom, ahora debe usar:

<parent>
    <groupId>com.iconsolutions.ipf</groupId>
    <artifactId>ipf-bom</artifactId>
    <version>2024.1.0</version>
</parent>

 El nuevo `ipf-bom` estandariza las definiciones de propiedad para la canela. Por lo tanto, cualquier cosa que solía referirse a la antigua propiedad `lightbend-cinnamon.version` debe referirse ahora al nuevo nombre `cinnamon.version`.
Tenga en cuenta que si utiliza docker generación de imágenes, esto incluye el comando de generación dentro de la aplicación pom por ejemplo:

 <cmd>exec java -javaagent:/${project.artifactId}/lib/com.lightbend.cinnamon-cinnamon-agent-${cinnamon.version}.jar -agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=*:5005 -cp "/${project.artifactId}/conf:/${project.artifactId}/lib/*" $IPF_JAVA_ARGS com.iconsolutions.com.iconsolutions.migrationsolution.app. Application -startup</cmd>

Actualice la configuración del pom para proyectos DSL.

Como se mencionó anteriormente, la estructura de los proyectos DSL ha sido modificada. Esto proporciona una serie de beneficios en el futuro en lo que respecta a simplificar la integración de los proyectos DSL dentro de su aplicación. Para migrar, se deben realizar los siguientes pasos:

En su pom raíz, añada las siguientes propiedades:

<properties>
    <solution.name>com.iconsolutions.migrationsolution</solution.name>
    <model.name>com.iconsolutions.migrationmodel</model.name>
</properties>

Donde el <solution.name> y <model.name> los valores son los descritos en el Antes de comenzar sección anterior.

Actualice el padre de los submódulos del dominio

El padre de los submódulos de la [name of app]-domain el módulo ya no necesita ser una referencia especial al respectivo flo-starter-xxx artefactos, y ahora debería ser solo el padre 'natural' del módulo. Por ejemplo, si su MPS Los artefactos se encuentran todos bajo un módulo "migration-example-domain" de la siguiente manera:

Entonces, el padre de cada uno de los submódulos debería verse ahora así:

<parent>
    <groupId>com.iconsolutions.com.iconsolutions.migrationsolution.domain</groupId>
    <artifactId>migration-example-domain</artifactId>
    <version>0.0.1-SNAPSHOT</version>
</parent>

Después de este cambio, ya no necesita el adicional <groupId>..</groupId> etiqueta fuera del padre, por lo que puede ser eliminada.

Puede confirmar que el padre se ha actualizado correctamente en cada uno de los submódulos comparándolos con el padre en el existente.external-libraries submódulo.

Actualice las referencias de versión de dependencia

Cualquier versión de dependencia en los submódulos que se refiera a la propiedad flo.version necesita ser actualizado a icon-flo.version:

<dependency>
    <groupId>com.iconsolutions.ipf.core.flow</groupId>
    <artifactId>library-dependencies</artifactId>
    <version>${icon-flo.version}</version>
</dependency>

También, en el test submódulo, el flo-test-common la versión de dependencia debe ser cambiada de project.parent.version to icon-flo.version:

<dependency>
    <groupId>com.iconsolutions.ipf.core.flow</groupId>
    <artifactId>flo-test-common</artifactId>
    <version>${icon-flo.version}</version>
    <type>test-jar</type>
    <scope>test</scope>
</dependency>

Agregue el/los azulejo(s) relevante(s) a la sección de construcción del pom

A continuación, en cada uno de los poms de los submódulos, necesitamos añadir el tile relevante para indicarles qué deben construir. Para ello, añadimos la siguiente sección al pom:

<build>
    <plugins>
        <plugin>
            <groupId>io.repaint.maven</groupId>
            <artifactId>tiles-maven-plugin</artifactId>
            <version>${tiles-maven-plugin.version}</version>
            <extensions>true</extensions>
            <configuration>
                <tiles>
                    <tile>com.iconsolutions.ipf.core.flow:flo-tilename-tile:${icon-flo.version}</tile>
                </tiles>
            </configuration>
        </plugin>
    </plugins>
</build>

Donde reemplazamos 'tilename' con el nombre de la baldosa apropiado para cada uno de los submódulos según se define en la lista a continuación:

docs usos docs
domain usos domain
mps usos mps-plugin
test usos test
sampleapp(si corresponde) utiliza sampleapp

Así que, por ejemplo, el <tile> etiqueta para el mps el submódulo debe ser:

<tile>com.iconsolutions.ipf.core.flow:flo-mps-plugin-tile:${icon-flo.version}</tile>

Si su submódulo ya tiene un <build> sección en el pom.xml(como el mps(submódulo), entonces el azulejo deberá ser añadido como un complemento adicional en esta sección.

Las definiciones anteriores suponen que su proyecto no se va a utilizar como una dependencia de otro. MPS proyecto. Si lo es, necesitamos cambiar el `mps` definición para que utilice dos azulejos diferentes:

<tiles>
    <tile>com.iconsolutions.ipf.core.flow:flo-mps-tile:${icon-flo.version}</tile>
    <tile>com.iconsolutions.ipf.core.flow:flo-mps-archive-tile:${icon-flo.version}</tile>
</tiles>

en lugar de solo el definido anteriormente.

Agregue las dependencias requeridas

Finalmente, necesitamos agregar algunas dependencias adicionales a los módulos:

El domain el submódulo requiere las siguientes dos adiciones:

<dependency>
    <groupId>com.iconsolutions.ipf.core.flow</groupId>
    <artifactId>flo-starter-domain</artifactId>
</dependency>
<dependency>
    <groupId>com.iconsolutions.ipf.core.flow</groupId>
    <artifactId>flo-starter-domain-test</artifactId>
    <scope>test</scope>
</dependency>

El mps el submódulo necesita que se añada esta dependencia:

<dependency>
    <groupId>com.iconsolutions.ipf.core.flow</groupId>
    <artifactId>flo-starter-mps</artifactId>
</dependency>

El sampleapp el submódulo necesita que se añada esta dependencia:

<dependency>
    <groupId>com.iconsolutions.ipf.core.flow</groupId>
    <artifactId>flo-starter-sampleapp</artifactId>
</dependency>

El test el submódulo necesita que se añada esta dependencia:

<dependency>
    <groupId>com.iconsolutions.ipf.core.flow</groupId>
    <artifactId>flo-starter-test</artifactId>
    <scope>test</scope>
</dependency>

Migración y Actualizaciones dentro de MPS

Con los cambios anteriores completados, usted está ahora listo para realizar un estándar maven construir contra su proyecto. Esta construcción puede fallar porque el modelo aún no ha sido migrado. Puede obtener un fallo de construcción como este:

[ERROR] Failed to execute goal com.iconsolutions.plugins:icon-mps-runner:3.0.4:modelcheck (com.iconsolutions.ipf.core.flow_flo-mps-plugin-base-tile_3.17.0__modelcheck) on project mps: Command execution failed.: Process exited with an error: 255 (Exit value: 255) -> [Help 1]

O un error de compilación similar a:

[INFO] --- compiler:3.12.1:testCompile (default-testCompile) @ domain ---
[INFO] Recompiling the module because of changed dependency.
[INFO] Compiling 1 source file with javac [debug parameters release 17] to target/test-classes
[INFO] -------------------------------------------------------------
[ERROR] COMPILATION ERROR:
[INFO] -------------------------------------------------------------
[ERROR] /path/to/domain/src/test/java/com/mycorp/ipf/payments/debtor/debtor_ct/behaviour/DebtorCtBehaviourTest.java:[21, 53] package com.mycorp.ipf.payments.debtor.execution.testfw does not exist

Para resolver esto, abra su proyecto en MPS(Recordando que ahora debe usar 2022.3.1) y se le debe solicitar que migre su solución, haga clic Migrate.

Si no aparece la ventana emergente del Asistente de Migración, es probable que no tenga la Migration Support plugin habilitado en MPS. Esto será evidente si no ve Migration en la barra de herramientas. Para obtener orientación sobre cómo habilitar este complemento, consulte el Habilite el complemento de soporte para migración en MPS sección.

En el panel de navegación, debe ver que se requiere la regeneración del script de construcción:

Haga clic derecho y seleccione Rebuild Model [Your Model Name]. Ahora reconstruya utilizando Maven y su proyecto debería compilar correctamente.

Si su modelo de dominio es grande, la construcción del dominio puede fallar con una excepción de desbordamiento de pila. Para obtener orientación sobre cómo solucionar este problema, consulte el Corrija la excepción de construcción de Stack Overflow sección.

Los scripts de construcción ahora solo son necesarios para proyectos que deben ser utilizados como dependencias en otros. MPS proyectos. Si este no es el caso para su proyecto, puede simplemente eliminar la solución de compilación de su MPS proyecto.

Actualizaciones de Java17

Eliminación de `JUnitReportingRunner`

El Test Framework se ha actualizado para utilizar una versión más reciente de JBehave, y esto ha permitido la eliminación de com.github.valfirst.jbehave.junit.monitoring. JUnitReportingRunner.

Al compilar contra el nuevo 2024.1.0 BOM, su Test Framework los ejecutores podrían no compilar si están anotados con:

@RunWith(JUnitReportingRunner.class)

Esta anotación ya no es necesaria y puede ser eliminada.

Cambios como resultado de Spring 6/Spring Boot 3 actualización

Uno de los principales objetivos del IPF Java La actualización 17 debía permitir migrar a Spring 6 y Spring Boot 3 para beneficiarse de soluciones más rápidas para vulnerabilidades y correcciones de CVE. Los proyectos de Spring han realizado una serie de cambios disruptivos que no están relacionados con IPF, pero que puede encontrar como parte de cualquier actualización de Spring:

Moviendo de Java EE (javax.*) a Jakarta EE (jakarta.*) internamente. Aquí hay una tabla que puede ser útil:

Componente El paquete fue Empaque ahora

Componente	El paquete fue	Empaque ahora
Servlet de Jakarta	`javax.servlet.*`	`jakarta.servlet.*`
Validación de Jakarta	`javax.validation.*`	`jakarta.validation.*`
Anotaciones de Jakarta	`javax.annotation.*`	`jakarta.annotation.*`
Mensajería de Jakarta	`javax.jms.*`	`jakarta.jms.*`

Servlet de Jakarta

javax.servlet.*

jakarta.servlet.*

Validación de Jakarta

javax.validation.*

jakarta.validation.*

Anotaciones de Jakarta

javax.annotation.*

jakarta.annotation.*

Mensajería de Jakarta

javax.jms.*

jakarta.jms.*

Spring Web: Cambiando el comportamiento predeterminado de coincidencia de la barra diagonal final para que no esté habilitado por defecto (enlace)
Cliente de MongoDB 4.11.x: esto permite utilizar características introducidas hasta e incluyendo MongoDB 7.0(y es compatible hacia atrás con 3.6)
La primavera ha eliminado el LocalVariableTableParameterNameDiscoverer in 6.1. Esto significa que Spring ya no buscará dentro del LocalVariableTable como una pista. Esto podría resultar en la Primavera ApplicationContext ahora no inicia con errores similares a:
```
Caused by: org.springframework.beans.factory. NoUniqueBeanDefinitionException: No qualifying bean of type 'com.myorg. MyBean' available: expected single matching bean but found 2: myBean1, myBean2
```

Para superar esto, debe agregar esto a su POM raíz para generar metadatos de parámetros de método para reflexión:

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-compiler-plugin</artifactId>
    <configuration>
        <parameters>true</parameters>
    </configuration>
</plugin>

Ver Nombre del Parámetro Retención para más información sobre este tema. * Spring también ha eliminado el soporte para registrar auto-configuraciones en spring.factories usando el org.springframework.boot.autoconfigure. EnableAutoConfiguration clave, a favor de utilizar el META-INF/spring/org.springframework.boot.autoconfigure. AutoConfiguration.imports archivo introducido en Spring Boot 2.7.

Para más información sobre Spring 6 /Spring Boot 3, consulte el Spring Boot 3.0 Notas de la versión y Spring Boot 3.0 Guía de Migración.

Apéndice

Habilite el complemento de soporte para migración en MPS

Para habilitar el Migration Support complemento en MPS, vaya a Archivo > Configuración > Complementos y busque migration en su lista de complementos instalados. Marque el Migration Support plugin para habilitarlo.

Corrija la excepción de construcción de Stack Overflow

Si la construcción de su módulo de dominio falla debido a una excepción de desbordamiento de pila, añada el siguiente complemento a la <build> sección del mps submódulo pom.xml:

<plugin>
    <groupId>com.iconsolutions.plugins</groupId>
    <artifactId>icon-mps-runner</artifactId>
    <version>3.0.4</version>
    <configuration>
        <vmArgs>
            <vmArg>-Xss256m</vmArg>
        </vmArgs>
    </configuration>
</plugin>