Maven: enlace la ejecución del complemento a la ejecución de otro complemento, no a una fase del ciclo de vida

maven-release-plugin git-flow

Question

Nota sobre la respuesta aceptada: acepté la respuesta debido a una fuerte evidencia circunstancial. No obstante, esta es una evidencia circunstancial, así que tómela con un grano de sal.

¿Cómo puedo activar un complemento cuando el usuario ejecuta un objetivo de complemento, no una fase de ciclo de vida? (Esto se ha preguntado anteriormente, pero la respuesta fue usar una fase del ciclo de vida).

Caso en cuestión: necesito release:branch para invocar regex-plugin para generar una rama con la versión actual como su nombre, menos el sufijo -SNAPSHOT . Esto es lo que tengo, lo que requiere que el desarrollador active un perfil e invoque la fase de verify . Necesito que el desarrollador simplemente invoque release:branch , que a su vez debería hacer que se ejecute regex-plugin . En un poco de un matrimonio con Gitflow.

<profile>
    <id>Release Branch</id>
    <build>
        <plugins>
            <!-- On validate, compute the current version without -SNAPSHOT. -->
            <!-- Put the result in a property. -->
            <plugin>
                <groupId>org.codehaus.mojo</groupId>
                <artifactId>build-helper-maven-plugin</artifactId>
                <version>1.7</version>
                <executions>
                    <execution>
                        <phase>validate</phase>
                        <goals>
                            <goal>regex-property</goal>
                        </goals>
                        <configuration>
                            <value>${project.version}</value>
                            <regex>^(.*)-SNAPSHOT$</regex>
                            <replacement>$1</replacement>
                            <name>project.unqualifiedVersion</name>
                        </configuration>
                    </execution>
                </executions>
            </plugin>
            <!-- Also on validate, run the branch plugin, and use -->
            <!-- the non-SNAPSHOT version thus computed in the branch name. -->
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-release-plugin</artifactId>
                <version>2.3.2</version>
                <executions>
                    <execution>
                        <phase>validate</phase>
                        <goals>
                            <goal>branch</goal>
                        </goals>
                        <configuration>
                            <branchName>release/${project.unqualifiedVersion}</branchName>
                            <updateWorkingCopyVersions>true</updateWorkingCopyVersions>
                            <updateBranchVersions>false</updateBranchVersions>
                        </configuration>
                    </execution>
                </executions>
            </plugin>
        </plugins>
    </build>
</profile>

La intención es release:branch para mover la versión de la instantánea actual (por ejemplo, 1.0.5-SNAPSHOT ) a una nueva rama, que debe tener el nombre de la versión pero sin el sufijo -SNAPSHOT superfluo ( 1.0.5 ). La rama actual debería tomar una nueva versión de instantánea ( 1.1.0-SNAPSHOT , no 1.0.6-SNAPSHOT , porque queremos que la versión 1.0.x tenga espacio para las revisiones, por lo que la reservamos para la rama) t tiene el cómputo automático de la próxima versión de instantánea resuelto aún, por lo tanto, si ejecuta la configuración de Maven anterior con validate , tendrá que ingresarla cuando se le solicite).

Answer 1

La evidencia presentada hasta ahora es más bien circunstancial. He investigado por mi cuenta, así que es mejor que lo comparta aquí. Los siguientes son más del mismo "no es posible", o los componentes básicos de las alternativas.

portals.apache.org/jetspeed-2/buildguide/… --- ejecuta una secuencia específica de plugins; la configuración a ejecutar puede variar a través de una propiedad del sistema; Preocupaciones de integración IDE

Ejecutar objetivos antes de que se ejecute el complemento (StackOverflow) --- misma pregunta respondida en el contexto de un Mojo personalizado

Haz que Mojo ejecute otros objetivos (StackOverflow) --- de nuevo, desde el contexto de un Mojo personalizado

Configuración de ejecuciones predeterminadas de Mojo --- Página de Maven que describe cómo se ejecutan los Mojos - más evidencia circunstancial

Desencadenando fases antes de la ejecución del objetivo (StackOverflow) --- solución indirecta a mi problema, desafortunadamente respondida negativamente

INTERESANTE : Guía para el desarrollo de complementos de Ant --- atractivo para mí, porque, aunque requiere la escritura de un complemento personalizado, es toda la configuración de Ant + Maven, no es necesario compilar ningún código; presumiblemente una barrera de entrada más baja

Creación de un ciclo de vida paralelo: un enfoque atractivo, ya que podía controlar completamente los contenidos del ciclo de vida hasta donde usaría los verbos de Gitflow; no está claro cómo los IDE integrarán esto; curva de aprendizaje y las preocupaciones de barrera de adopción existen

Answer 2

No, no puede enlazar un complemento a otro complemento. Sólo a una fase.

En términos internos de Maven, un "Mojo" es la cosa que sí funciona. Un "complemento" es una colección de mojos envueltos para que puedas consultarlos desde el POM. Los Mojos se unen solo a las fases.

De la documentación de desarrollo del plugin :

Cada Mojo especificado dentro de un descriptor de complemento debe proporcionar lo siguiente

...

fase ... Define una fase predeterminada para vincular una ejecución mojo a si el usuario no establece explícitamente una fase en el POM. Nota: esta anotación no hará automáticamente que se ejecute un mojo cuando se agregue la declaración del complemento al POM. Simplemente permite al usuario omitir el elemento <phase> elemento <execution> rodea.

Para obtener más información, consulte la fuente de MojoExecution (el JavaDoc para esta clase no es útil) y observe que hay dos posibles fuentes de ejecución enumeradas:

Una ejecución que se origina a partir de la invocación directa de un objetivo del CLI

y

Una ejecución que se origina desde un objetivo vinculado a una fase del ciclo de vida.

Ninguna otra forma de iniciar una ejecución significa que está fuera de suerte (salvo medidas extraordinarias, como rodar su propio complemento que combina los efectos de los dos complementos que desea vincular y luego usar su complemento personalizado).