使用Maven进行Coldfusion项目 [英] Using Maven for Coldfusion project

问题描述

我必须处理什么是相当丑陋和大块的ColdFusion代码，直到今天，通过直接修改生产服务器（不要问）。我设法从清除它的备份和备份，并把它放到Subversion，现在我需要tp选择一个make系统，以便能够把这个连续构建（TeamCity）和计划发布。
令我惊讶的是，我只发现了一个关于如何改进CF项目与Maven ，所以问题是 - 是否有任何人有成功使用Maven的CF上的经验和一般人用什么管理大型CF项目？
你的建议，提示和链接将非常感谢
因为我不想开始religions战争 - Maven是相当多的公司标准（vs Ant）

blogspot.com/2007/09/build-tools-maven-and-coldfusion.htmlrel =nofollow noreferrer> build-tools-maven-and-coldfusion

我没有试图用Maven构建ColdFusion，但是我有一个管理Maven builds为一家大公司的经验。

$ b

Coldfusion cfm和cfc文件应该放在src / main / resources中，以便它们在jar中绑定（上面引用的博客覆盖了Maven的约定，把它们放在src中），这是确定的，但是如果你以后需要添加

我可能将cfc和cfm文件保存在单独的项目中，并使用适当的依赖性声明来链接它们，这会将您的cfc项目保存为库，有助于重用。这也值得考虑cfc项目的粒度。

部署

提供工件的最简单的方法是使用 maven-war-plugin 创建一个包含您的工件和所有传递依赖的war。这使每个应用程序自包含，这可能是有用的。这样做的缺点是，你会最终捆绑相同的工件反复，他们可能是相当大。要减轻此情况，您可以使用程序集插件创建自定义包不包括公共组件，或者您可以指定某些组件（例如ColdSpring）的范围 ，这意味着它们不会包含在战争中。

版本管理

Maven鼓励增加依赖关系，默认情况下每个依赖关系声明都有一个版本，特别是当你想要颠覆一个外部依赖的版本。您可以通过定义父POM或应用程序POM来缓解此问题。或者有一个dependencyManagement部分声明公共工件的详细信息（groupId，artifactId和version）。从父类继承的任何POM不需要声明依赖性版本，因为它将被继承（注意，这并不意味着所有的孩子都将具有所有的依赖性，只有声明依赖性的任何声明不需要声明版本）。如果你定义一个包含pom和dependencyManagement部分的app项目，你可以使用范围 import （从Maven 2.0.9起）引用它，这将导入dependencyManagement部分从 app项目到项目POM。有关详细信息，请参见依赖性文档。 p>

如果您在dependencyManagement部分中声明一个范围的依赖项，那么该范围将被继承，除非它在子POM中被覆盖。与上述部署部分相关，这意味着您可以在父级中声明公共库范围 ，以确保它们不会捆绑在每个应用中。

命名惯例
您需要一个命名约定来避免程序包的冲突。
最好遵循Maven约定并使用类似java包的groupIds（org.apache.maven for maven.apache.org）和工件的jar名称。这个约定将为ColdSpring提供groupIdorg.coldspringframework和artifactIdcoldspring。

可能需要在整个公司进行进一步区分。例如，如果您有网络和核心团队，您可以为网络团队提供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> 
<！ - 自定义打包类型有助于保持与Java工件分离 - > 
< type> cfc< / type> 
< / dependency> 
  

Nexus书籍中有一节描述 custom lifecycles （按照链接获取更多详细信息）本质上，你需要创建一个插件一个META-INf / plexus / components.xml来描述丛的力学（使用哪个archiver，输出什么扩展等）。

像这样：

 < 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>每次查找< / 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>每次查找< / instantiation-strategy> 
< / component> 
< / components> 
< / component-set> 
  

I have to deal with what is pretty ugly and large blob of ColdFusion code which up to this day is maintained by direct modifications on production server (don't ask). I managed to clean it up from dupes and backups and put it into Subversion, now I need tp pick a make system to be able to put this onto continuous build (TeamCity) and also scheduled releases. To my surprise I only found pretty much a single blog article on how to retrofit CF project with Maven, so the question is - does anyone have experience successfully using Maven on CF and what in general people use to manage large CF projects? Your suggestions, tips and links will be much appreciated Since I don't want to start religions wars - Maven is pretty much company standard (vs Ant)

解决方案

First, here's another blog you might find helpful.

build-tools-maven-and-coldfusion

I haven't tried to build ColdFusion with Maven, but I have experience with managing Maven builds for a large company. There are a few things for you to consider.

Project structure

Coldfusion cfm and cfc files should be put in src/main/resources so they are bundled in the jar (the blog referenced above overrides the Maven convention to put them in src. this is ok, but could be a problem if you later need to add anything else to the project).

I'd probably keep cfc and cfm files in separate projects with appropriate dependency declarations to link them, this keeps your cfc projects as libraries and helps reuse. It is also worth considering the granularity of the cfc projects. Generally Maven's dependency management helps you keep artifacts small, with little need to worry about finding all the jars.

Deployment

The simplest way to deliver the artifacts is to use the maven-war-plugin to create a war containing your artifacts and all their transitive dependencies. This makes each application self-contained, which can be useful. The downside of this is that you'll end up bundling the same artifacts repeatedly and they can be quite large. To mitigate this you can either use the assembly-plugin to create custom packages excluding the common components, or you can specify that certain components (e.g. ColdSpring) are scope provided, this means they won't be included in the war.

Version Management

Maven encourages a proliferation of dependencies, by default each dependency declaration has a version, this can cause maintenance issues, particularly when you want to bump the version of an external dependency. You can mitigate this by defining a parent POM or an "app" POM. Either would have a dependencyManagement section declaring the details (groupId, artifactId, and version) for common artifacts. Any POM inheriting from the parent need not declare the dependency version as it will be inherited (note this doesn't mean that all children will have all dependencies, only that any that declare a dependency don't need to declare the version). If you define an "app" project with packaging "pom" and a dependencyManagement section, you can reference it with scope import (from Maven 2.0.9 onwards), this will import the dependencyManagement section from the "app" project to the project POM. See the dependency documentation for more details.

If you declare a dependency with a scope in the dependencyManagement section, that scope will be inherited unless it is overridden in the child POM. Related to the deployment section above, this means that you can declare the common libraries scope provided in the parent to ensure they are not bundled in each applciation.

Naming Conventions You'll need a naming convention for the packages to avoid collisions. It's probably best to follow the Maven convention and use java package-like groupIds (org.apache.maven for maven.apache.org) and the jar name for the artifact. This convention would give the groupId "org.coldspringframework" and artifactId "coldspring" for ColdSpring.

Further distinctions might need to be made across the company. For example, if you have a web and core team, you could give the web team the groupIds com.mycompany.web.* and the core team com.mycompany.core.*

Dependency Management

You'll need to add your CFC packages to a Maven repository such as Nexus so they are accessible to other builds across the enterprise.

If you want to keep the CFC packages separate to the jars. You can specify a custom packaging type, so that they won't be mixed up with any Java artifacts. If you create a custom packaging type, the artifacts can have the ".jar" extension, but any dependency declaration must have the type set.

Here's an example following those conventions:

<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>

There's a section in the Nexus book that describes custom lifecycles (follow the links for more details. Essentially you need to create a plugin with a META-INf/plexus/components.xml to describe the plexus mechanics (what archiver to use, what extension to output etc).

The components.xml would look something like this:

<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>

这篇关于使用Maven进行Coldfusion项目的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！