2009-09-10 11 views
19

que tienen esta tarea para el proyecto con 4 subproyectos anidados utilizando Maven:El uso de Maven para el despliegue

  1. Para cada niño: directorio de recursos frasco-up incluyendo las dependencias del proyecto
  2. pasar al proyecto principal
  3. Con un solo comando, extraiga todos los archivos creados en varios destinos remotos (instalación completa), que pueden incluir servidor http, servidor de aplicaciones, servidor de archivos, etc. (principalmente * NIX). Destino se proporciona en el nivel de subproyecto
  4. También debe ser posible descomprimir/copiar del subproyecto individuales (instalación parcial)

archivos no son de Java - en su mayoría diferentes scripts y HTML

Busco en los diversos complementos para ayudar con la tarea: ensamblado, dependencia, antrun, descomprimir. La dependencia parece prometedora, pero necesito descomprimir no solo los contenedores de dependencia, sino también el contenido del (sub) proyecto. Además, dado que no puedo realmente ajustar la operación al ciclo de vida de Maven, ¿cómo activaría la instalación remota? dependencia mvn: descomprimir? Eso no es muy descriptivo o intuitivo. ¿Es posible crear un objetivo personalizado (por ejemplo, proyecto: instalar) sin escribir un complemento?

El uso de Maven es estándar de la compañía así que por favor no ofrecen alternativas - estoy bastante atascado con lo que tengo

+1

Ja ja. Ojalá estuviera "atascado" con Maven en mi compañía. – SingleShot

+0

No lo quise decir de manera despectiva :) – Bostone

+0

No entiendo qué significa "Destino en el nivel de subproyecto" significa. ¿Entregan todos los archivos a cada destino? –

Respuesta

12

Ok, creo que el siguiente podría hacer lo que necesita. El inconveniente de este enfoque es que habrá un intervalo entre cada despliegue a medida que se ejecuta la compilación subsiguiente. ¿Es esto aceptable?

Defina un perfil en cada proyecto con el mismo nombre (digamos "publicar"). Dentro de ese perfil, puede definir una configuración para usar el antrun-plugin para entregar los archivos con FTP (ver a continuación).

En el proyecto principal, tendrá un elemento de módulos, definiendo cada proyecto como un módulo. Si ejecuta mvn install -P publish, cada proyecto se construirá a su vez con el perfil de publicación habilitado y el artefacto final publicado en el destino durante la fase de instalación. Si necesita implementar archivos adicionales, modifique el include element en consecuencia.

Tenga en cuenta que los parámetros para la tarea FTP se han establecido como propiedades, esto permite que se anulen desde la línea de comandos y/o se hereden del POM principal.

<profiles> 
    <profile> 
    <id>publish</id> 
    <plugin> 
     <groupId>org.apache.maven.plugins</groupId> 
     <artifactId>maven-antrun-plugin</artifactId> 
     <executions> 
     <execution> 
      <id>ftp</id> 
      <phase>install</phase> 
      <configuration> 
      <tasks> 
       <ftp action="send" 
        server="${ftp.host}" remotedir="${ftp.remotedir}" 
        userid="${ftp.userid}" password="${ftp.password}" 
        depends="${ftp.depends}" verbose="${ftp.verbose}"> 
       <fileset dir="${project.build.directory}"> 
        <include 
        name="${project.build.finalName}.${project.packaging}"/> 
       </fileset> 
       </ftp> 
      </tasks> 
      </configuration> 
      <goals> 
      <goal>run</goal> 
      </goals> 
     </execution> 
     </executions> 
     <dependencies> 
     <dependency> 
      <groupId>commons-net</groupId> 
      <artifactId>commons-net</artifactId> 
      <version>1.4.1</version> 
     </dependency> 
     <dependency> 
      <groupId>ant</groupId> 
      <artifactId>ant-commons-net</artifactId> 
      <version>1.6.5</version> 
     </dependency> 
     <dependency> 
      <groupId>ant</groupId> 
      <artifactId>ant-nodeps</artifactId> 
      <version>1.6.5</version> 
     </dependency> 
     </dependencies> 
    </plugin> 
    <properties> 
     <ftp.host>hostname</ftp.host> 
     <ftp.remotedir>/opt/path/to/install</ftp.remotedir> 
     <ftp.userid>user</ftp.userid> 
     <ftp.password>mypassword</ftp.password> 
     <ftp.depends>yes</ftp.depends> 
     <ftp.verbose>no</ftp.verbose>   
    </properties> 
    </profile> 
</profiles> 

Actualización: basado en su comentario: Se puede usar el plugin de dependencia para descargar cada dependencia, excepto que un padre no puede tener una dependencia de un niño, y que se construirá antes de que el niño . Tendría que ser otro proyecto. también necesita tener en algún lugar la información de dónde desplegarlos. Por el momento, tiene la información del objetivo en los proyectos individuales, por lo que no está accesible en el proyecto del implementador.

Tomando este enfoque, puede definir múltiples perfiles en el nuevo proyecto, uno para cada artefacto. Cada perfil define una dependencia: copia de ejecución para obtener el jar y una ejecución antrun para uno de los proyectos. La configuración común (como las dependencias para el plugin antrun) puede extraerse de los perfiles. También tenga en cuenta que las propiedades se fusionarán si define múltiples perfiles, por lo que es posible que necesite calificarlos con el nombre del artefacto, por ejemplo ftp.artifact1.host.

<profiles> 
    <profile> 
    <id>deploy-artifact1</id> 
    <plugin> 
     <groupId>org.apache.maven.plugins</groupId> 
     <artifactId>maven-dependency-plugin</artifactId> 
     <executions> 
     <execution> 
      <id>copy-dependency</id> 
      <phase>prepare-package</phase> 
      <goals> 
      <goal>copy</goal> 
      </goals> 
      <configuration> 
      <artifactItems> 
       <artifactItem> 
       <groupId>name.seller.rich</groupId> 
       <artifactId>artifact1</artifactId> 
       <version>1.0.0</version> 
       <type>jar</type> 
       <overWrite>false</overWrite> 
       </artifactItem> 
      </artifactItems> 
      <outputDirectory>${project.build.directory}/deploy-staging</outputDirectory> 
      <overWriteReleases>false</overWriteReleases> 
      </configuration> 
     </execution> 
     </executions> 
    </plugin> 
    <plugin> 
     <groupId>org.apache.maven.plugins</groupId> 
     <artifactId>maven-antrun-plugin</artifactId> 
     <executions> 
     <execution> 
      <id>ftp</id> 
      <phase>install</phase> 
      <configuration> 
      <tasks> 
       <ftp action="send" 
        server="${ftp.host}" remotedir="${ftp.remotedir}" 
        userid="${ftp.userid}" password="${ftp.password}" 
        depends="${ftp.depends}" verbose="${ftp.verbose}"> 
       <fileset dir="${project.build.directory} includes="deploy-staging/"/> 
       </ftp> 
      </tasks> 
      </configuration> 
      <goals> 
      <goal>run</goal> 
      </goals> 
     </execution> 
     </executions> 
    </plugin> 
    <properties> 
     <!--if the properties differ between targets, qualify them with the artifact name--> 
     <ftp.host>hostname</ftp.host> 
     <ftp.remotedir>/opt/path/to/install</ftp.remotedir> 
     <ftp.userid>user</ftp.userid> 
     <ftp.password>mypassword</ftp.password> 
     <ftp.depends>yes</ftp.depends> 
     <ftp.verbose>no</ftp.verbose>   
    </properties> 
    </profile> 
</profiles> 
+0

Esto debería funcionar. El perfil es lo que me he perdido todos juntos. Aquí hay otra idea que debería ayudar con los "contratiempos", en lugar de definir subproyectos ya que los módulos los definen como dependencias en el POM padre y extraer los JAR de artefactos en sus destinos usando el complemento de dependencia. ¿Eso funcionará? – Bostone

+0

Olvidé mencionar que en nuestra empresa usamos NAC para poder mapear/acceder a cualquier servidor solo como directorio mapeado (tanto Win/* NIX) por lo que realmente no hay necesidad de FTP o SSH – Bostone

+0

en ese caso, la dependencia- el objetivo de copia del complemento es todo lo que necesita, simplemente modifique la propiedad outputDirectory a la ruta del destino –

0

Me gustaría utilizar el maven-assembly-plugin para hacerlo.

Algo como esto se puede utilizar para tomar los archivos de los proyectos secundarios y rellenarlos en los directorios de salida.

<assembly> 
    <id>xyzzy</id> 
    <formats> 
    <format>zip</format> 
    </formats> 
    <fileSets> 
    <fileSet> 
     <directory>../subproject1/target/</directory> 
     <outputDirectory>/foo</outputDirectory> 
     <includes> 
     <include>*.jar</include> 
     </includes> 
    </fileSet> 
    <fileSet> 
     <directory>../subproject1/target/html-output/</directory> 
     <outputDirectory>/foo</outputDirectory> 
     <includes> 
     <include>*.html</include> 
     <include>*.js</include> 
     <include>*.css</include> 
     </includes> 
    </fileSet>  
    <fileSet> 
     <directory>../subproject2/target/</directory> 
     <outputDirectory>/bar</outputDirectory> 
     <includes> 
     <include>**/**</include> 
     </includes> 
     <excludes> 
     <exclude>**/*.exclude-this</exclude> 
     </excludes> 
    </fileSet> 
    </fileSets> 
</assembly> 
+1

Según tengo entendido, el plugin de ensamblaje creará algún tipo de archivo (jar, war, zip) que no funciona para mí. Necesito que los archivos/carpetas reales se copien en el destino. En realidad, el complemento maven-dependency parece ser es más adecuado ya que puede "descomprimir" pero luego estoy atascado porque no puedo definir subproyectos como módulos y dependencias. Por lo tanto, la ruta que voy es en realidad después de las sugerencias de Rich: definir el perfil y copiar archivos durante la fase de instalación – Bostone

+0

dir crearía un directorio – sal

0

Maven no está diseñado para implementar tarros en una ubicación remota; su uso principal es compilar y empacar artefactos. Los objetivos de ensamblaje y dependencia se usan principalmente para reunir dependencias y archivos para empaquetar en un artefacto.

Habiendo dicho eso, maven tiene un objetivo de implementación que usa un componente llamado vagón. Esto está destinado principalmente a implementarse en un repositorio maven. Hay un complemento llamado Cargo que se puede usar para implementar artefactos en un servidor remoto, pero que no explota el contenido del contenedor por sí mismo (depende de que el servidor de aplicaciones de destino haga todo eso). Es posible que pueda extender la funcionalidad de Maven Wagon usted mismo.

Además, es posible empaquetar un ciclo de vida personalizado, pero eso se está convirtiendo en un maven mojo de bastante bajo nivel (juego de palabras).

+0

Terminé usando perfiles y antrun - ¡lo mejor de ambos mundos! – Bostone

+0

¡genial! Supongo que Antrun es la manera de eludir quién requisito de le Maven;) –

1

No funciona sin frase de contraseña.

<profile> 
     <id>publish</id> 
     <build> 
      <plugins> 
       <plugin> 
        <artifactId>maven-antrun-plugin</artifactId> 
        <executions> 
         <execution> 
          <id>scp</id> 
          <phase>deploy</phase> 
          <configuration> 
           <tasks> 
            <scp todir="[email protected]:some/remote/dir" 
             sftp="true" 
             keyfile="${user.home}/.ssh/devel-deploy.id_dsa" 
             failonerror="false" 
             verbose="true" 
             passphrase="nopass" 
            > 
             <fileset dir="${project.build.directory}"> 
              <include 
               name="${project.build.finalName}.${project.packaging}"/> 
             </fileset> 
            </scp> 
           </tasks> 
          </configuration> 
          <goals> 
           <goal>run</goal> 
          </goals> 
         </execution> 
        </executions> 
        <dependencies> 
         <dependency> 
          <groupId>org.apache.ant</groupId> 
          <artifactId>ant-jsch</artifactId> 
          <version>1.9.4</version> 
         </dependency> 
        </dependencies> 
       </plugin> 
      </plugins> 
     </build> 
    </profile> 

Sin embargo, mi favorito es

<profile> 
     <id>upload-devel</id> 
     <build> 
      <plugins> 
       <plugin> 
        <artifactId>maven-antrun-plugin</artifactId> 
        <executions> 
         <execution> 
          <id>upload-devel</id> 
          <phase>deploy</phase> 
          <configuration> 
           <target> 
            <exec executable="rsync" failonerror="false"> 
             <arg value="-aiz" /> 
             <arg value="${project.build.directory}/${project.artifactId}.${project.packaging}" /> 
             <arg value="[email protected]:some/remote/dir/." /> 
            </exec> 
           </target> 
          </configuration> 
          <goals> 
           <goal>run</goal> 
          </goals> 
         </execution> 
        </executions> 
       </plugin> 
      </plugins> 
     </build> 
    </profile> 

aunque no sé cómo compatible que es a través de diferentes plataformas.

+0

Para hacer que 'rsync' funcione de esta manera, tuve que agregar' 1.8 'después de' maven-antrun-plugin '. Sin eso, no ejecutó realmente el comando, aunque sí imprimió '[INFO] Tareas ejecutadas'. – Tom

5

Debajo POM ayudará a copiar el archivo de jar del directorio de construcción del proyecto al servidor SFTP/FTP remoto.

  1. Uso de comandos mvn instalar -Dftp.password = contraseña

Ya que quiero pasar la contraseña del símbolo del sistema por razones de seguridad, he utilizado -Dftp.password = contraseña Después ejecución del comando anterior todos los archivos jar de la carpeta de destino del proyecto maven se desplegarán en la carpeta MAVEN en server.com

<plugin>   <groupId>org.apache.maven.plugins</groupId> 
     <artifactId>maven-antrun-plugin</artifactId> 

    <executions> 
     <execution> 
      <id>ftp</id> 
      <phase>install</phase> 
      <configuration> 
       <tasks> 
        <scp todir="[email protected]:/MAVEN/" 
         sftp="true" port="22" trust="true" password="${ftp.password}" 
         failonerror="false" verbose="true" passphrase=""> 
         <fileset dir="${project.build.directory}"> 
          <include name="*.jar" /> 
         </fileset> 
        </scp> 
       </tasks> 
      </configuration> 
      <goals> 
       <goal>run</goal> 
      </goals> 
     </execution> 
    </executions> 
    <dependencies> 
     <dependency> 
      <groupId>org.apache.ant</groupId> 
      <artifactId>ant-jsch</artifactId> 
      <version>1.9.4</version> 
     </dependency> 
    </dependencies> 

</plugin> 
Cuestiones relacionadas