Во-первых, вот еще один блог, который вам может пригодиться.
встроенные инструменты-Maven-и-ColdFusion
Я не пытался собрать ColdFusion с Maven, но у меня есть опыт управления сборками Maven для большой компании. Есть несколько вещей, которые вы должны рассмотреть.
Структура проекта
Файлы Coldfusion cfm и cfc должны быть помещены в src / main / resources, чтобы они были объединены в jar (упомянутый выше блог переопределяет соглашение Maven для помещения их в src. Это нормально, но может быть проблемой, если вы позже нужно добавить что-нибудь еще в проект).
Я бы, вероятно, хранил файлы cfc и cfm в отдельных проектах с соответствующими объявлениями зависимостей, чтобы связать их, это сохраняет ваши проекты cfc в виде библиотек и помогает их повторное использование. Также стоит учитывать гранулярность проектов cfc. Как правило, управление зависимостями Maven помогает сохранять небольшие артефакты, и вам не нужно беспокоиться о поиске всех банок.
Развертывание
Самый простой способ доставки артефактов - использовать maven-war-plugin , чтобы создать войну, содержащую ваши артефакты и все их переходные зависимости. Это делает каждое приложение автономным, что может быть полезно. Недостатком этого является то, что вы будете в конечном итоге связывать одни и те же артефакты несколько раз, и они могут быть довольно большими. Чтобы смягчить это, вы можете использовать сборочный плагин для создания пользовательских пакетов, исключая общие компоненты, или вы можете указать, что определенные компоненты (например, ColdSpring) имеют область действия при условии , это означает, что они не будет включен в войну.
Управление версиями
Maven поощряет распространение зависимостей, по умолчанию каждое объявление зависимости имеет версию, это может вызвать проблемы с обслуживанием, особенно если вы хотите повысить версию внешней зависимости. Вы можете уменьшить это, определив родительский POM или POM «приложения». Любой из них будет иметь раздел dependencyManagement, объявляющий подробности (groupId, artifactId и version) для распространенных артефактов. Любой POM, наследующий от родителя, не должен объявлять версию зависимости, поскольку она будет наследоваться (обратите внимание, это не означает, что все дочерние элементы будут иметь все зависимости, только то, что любой, который объявляет зависимость, не должен объявлять версию). Если вы определили проект «app» с упаковкой «pom» и секцией dependencyManagement, вы можете сослаться на него с областью действия import (начиная с Maven 2.0.9 и далее), это приведет к импорту раздела dependencyManagement из приложения Проект к проекту ПОМ. Подробнее см. документацию по зависимостям .
Если вы объявляете зависимость с областью в разделе dependencyManagement, эта область будет наследоваться, если она не будет переопределена в дочернем POM. В связи с приведенным выше разделом развертывания это означает, что вы можете объявить область общих библиотек , предоставленную в родительском элементе, чтобы убедиться, что они не связаны в каждом приложении.
Соглашения об именах
Вам понадобится соглашение об именовании пакетов, чтобы избежать коллизий.
Вероятно, лучше всего следовать соглашению Maven и использовать групповые идентификаторы, подобные пакету java (org.apache.maven для maven.apache.org) и имя jar для артефакта. Это соглашение дает groupId "org.coldspringframework" и artifactId "coldspring" для ColdSpring.
Может потребоваться дальнейшее разграничение по всей компании. Например, если у вас есть веб-группа и основная группа, вы можете предоставить веб-группе groupIds com.mycompany.web. * И базовую группу com.mycompany.core. *
Управление зависимостями
Вам нужно будет добавить свои пакеты CFC в репозиторий Maven, например Nexus , чтобы они были доступны для других сборок по всему предприятию.
Если вы хотите хранить пакеты CFC отдельно от банок. Вы можете указать пользовательский тип упаковки, чтобы они не смешивались с какими-либо артефактами Java. Если вы создаете пользовательский тип упаковки, артефакты могут иметь расширение «.jar», но для любого объявления зависимости должен быть установлен тип.
Вот пример, следующий за этими соглашениями:
<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>
В книге Nexus есть раздел, описывающий пользовательские жизненные циклы (перейдите по ссылкам для получения более подробной информации. По сути, вам нужно создать плагин с META-INf / plexus / components.xml для описания сплетения механика (какой архиватор использовать, какое расширение для вывода и т. д.).
Component.xml будет выглядеть примерно так:
<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>