Usando Maven para el proyecto Coldfusion

Question

Tengo que lidiar con lo que es bastante feo y una gran cantidad de código de ColdFusion que hasta el día de hoy se mantiene mediante modificaciones directas en el servidor de producción (no preguntes). Logré limpiarlo de duplicados y copias de seguridad y ponerlo en Subversion, ahora necesito elegir un sistema make para poder ponerlo en construcción continua (TeamCity) y también lanzamientos programados. Para mi sorpresa, solo encontré prácticamente un único artículo de blog en how to retrofit CF project with Maven, por lo que la pregunta es: ¿Alguien tiene experiencia en usar con éxito Maven en CF y qué personas en general usan para administrar grandes proyectos de CF? Sus sugerencias, consejos y enlaces serán muy apreciados Como no quiero comenzar guerras de religiones - Maven es bastante estándar de la empresa (frente a Ant)

Answer 1

Primero, aquí hay otro blog que puede ser útil.

build-tools-maven-and-coldfusion

no he tratado de construir ColdFusion con Maven, pero tengo experiencia con el manejo de Maven construye para una compañía grande. Hay algunas cosas que debes considerar.

estructura del proyecto

archivos cfm ColdFusion y CFC se deben poner en src/main/resources por lo que se encuentran agrupados en el frasco (el blog mencionado anteriormente anula la convención Maven para ponerlos en src. Esto es está bien, pero podría ser un problema si luego necesita agregar algo más al proyecto).

Probablemente mantendría los archivos cfc y cfm en proyectos separados con declaraciones de dependencia adecuadas para vincularlos, esto mantiene sus proyectos cfc como bibliotecas y ayuda a reutilizar. También vale la pena considerar la granularidad de los proyectos cfc. En general, la administración de dependencias de Maven te ayuda a mantener los artefactos pequeños, sin necesidad de preocuparte por encontrar todos los frascos.

despliegue

La forma más sencilla de entregar los artefactos es utilizar el maven-war-plugin para crear una guerra que contiene los artefactos y todas sus dependencias transitivas. Esto hace que cada aplicación sea independiente, lo que puede ser útil. La desventaja de esto es que terminarás agrupando los mismos artefactos repetidamente y pueden ser bastante grandes. Para mitigar esto, puede usar el assembly-plugin para crear paquetes personalizados sin incluir los componentes comunes, o puede especificar que ciertos componentes (por ejemplo, ColdSpring) tengan el alcance provisto, esto significa que no se incluirán en la guerra.

gestión de versiones

Maven estimula la proliferación de las dependencias, por defecto cada declaración de dependencia tiene una versión, esto puede causar problemas de mantenimiento, sobre todo cuando se quiere topar la versión de una dependencia externa. Puede mitigar esto definiendo un POM padre o un POM "de aplicación". Cualquiera de los dos tendría una sección de gestión de dependencias que declarara los detalles (ID de grupo, ID de artefacto y versión) para artefactos comunes. Cualquier POM que herede del padre no necesita declarar la versión de dependencia, ya que se heredará (tenga en cuenta que esto no significa que todos los hijos tendrán todas las dependencias, solo que cualquiera que declare una dependencia no necesita declarar la versión). Si define un proyecto de "aplicación" con el paquete "pom" y una sección de gestión de dependencias, puede hacer referencia al alcance importar (desde Maven 2.0.9 en adelante), esto importará la sección de gestión de dependencias del proyecto "aplicación" al proyecto POM. Vea el dependency documentation para más detalles.

Si declara una dependencia con un ámbito en la sección de gestión de la dependencia, ese ámbito se heredará a menos que se invalide en el POM hijo. En relación con la sección de implementación anterior, esto significa que puede declarar que el alcance de las bibliotecas comunes proporcionó en el elemento principal para garantizar que no se incluyen en cada aplicación.

Convenciones de nomenclatura Necesitará una convención de nomenclatura para los paquetes para evitar colisiones. Probablemente sea mejor seguir la convención de Maven y usar groupIds tipo paquete java (org.apache.maven para maven.apache.org) y el nombre jar para el artefacto. Esta convención le daría al grupo Id "org.coldspringframework" y artefactId "coldspring" para ColdSpring.

Es posible que haya que hacer más distinciones en toda la empresa. Por ejemplo, si tiene un equipo de la web y el núcleo, se puede dar el equipo web de la com.mycompany.web groupIds. * Y la com.mycompany.core equipo central. *

Dependencia de Gestión de

Deberá agregar sus paquetes de CFC a un repositorio de Maven, como Nexus, para que otras construcciones de la empresa puedan acceder a ellos.

Si desea mantener los paquetes de CFC separados para los tarros. Puede especificar un tipo de paquete personalizado, para que no se mezclen con ningún artefacto de Java. Si crea un tipo de paquete personalizado, los artefactos pueden tener la extensión ".jar", pero cualquier declaración de dependencia debe tener el tipo establecido.

He aquí un ejemplo siguiendo las convenciones:

<dependency> 
    <groupId>org.coldspringframework</groupId> 
    <artifactId>coldspring</artifactId> 
    <version>1.2</version> 
    <!--custom packaging type helps keep separate from Java artifacts--> 
    <type>cfc</type> 
</dependency> 

hay una sección en el libro de Nexus que describe custom lifecycles (siga los enlaces para obtener más detalles Esencialmente es necesario crear un plugin con una META-INF/plexo. /components.xml para describir la mecánica del plexo (lo archivador de usar, lo que la extensión de la producción, etc.)

El components.xml sería algo como esto:.

<component-set> 
    <components> 
    <component> 
     <role>org.apache.maven.lifecycle.mapping.LifecycleMapping</role> 
     <role-hint>cfc</role-hint> 
     <implementation>org.apache.maven.lifecycle.mapping.DefaultLifecycleMapping</implementation> 
     <configuration> 
     <phases> 
      <process-resources>org.apache.maven.plugins:maven-resources-plugin:resources</process-resources> 
      <package>com.hsbc.maven.plugins:maven-jar-plugin:jar</package>   
      <install>org.apache.maven.plugins:maven-install-plugin:install</install> 
      <deploy>org.apache.maven.plugins:maven-deploy-plugin:deploy</deploy> 
     </phases> 
     </configuration> 
    </component> 
    <component> 
     <role>org.apache.maven.artifact.handler.ArtifactHandler</role> 
     <role-hint>cfc</role-hint> 
     <implementation>org.apache.maven.artifact.handler.DefaultArtifactHandler</implementation> 
     <configuration> 
     <extension>jar</extension> 
     <type>cfc</type> 
     <packaging>cfc</packaging> 
     </configuration> 
    </component> 
    <component> 
     <role>org.codehaus.plexus.archiver.Archiver</role> 
     <role-hint>cfc</role-hint> 
     <implementation>org.codehaus.plexus.archiver.zip.ZipArchiver</implementation> 
     <instantiation-strategy>per-lookup</instantiation-strategy> 
    </component> 
    <component> 
     <role>org.codehaus.plexus.archiver.UnArchiver</role> 
     <role-hint>cfc</role-hint> 
     <implementation>org.codehaus.plexus.archiver.zip.ZipUnArchiver</implementation> 
     <instantiation-strategy>per-lookup</instantiation-strategy> 
    </component> 
    </components> 
</component-set> 

Answer 2

Maven me pareció interesante también, pero no pude encontrar recursos suficientes y no tuve tiempo suficiente para resolverlo, así que pasé a lo que también parecía bueno.

Entiendo que prefiere utilizar Maven, me he topado con varios artículos sobre Ant y Coldfusion, así como con uno reciente sobre Hudson con Coldfusion.

Coldfusion también tiene la etiqueta cfant (no documentada). Puede ejecutar scripts ANT directamente desde CF?