使用 Maven 进行 Coldfusion 项目

发布于 2024-08-03 00:17:00 字数 421 浏览 5 评论 0原文

我必须处理相当丑陋且大量的 ColdFusion 代码，到目前为止，这些代码都是通过在生产服务器上直接修改来维护的（不要问）。我设法清除它的重复和备份并将其放入 Subversion，现在我需要选择一个 make 系统以便能够将其放入持续构建 (TeamCity) 和计划的版本中。令我惊讶的是，我只在如何使用 Maven 改造 CF 项目，所以问题是 - 有没有人有在 CF 上成功使用 Maven 的经验以及一般人用什么来管理大型 CF 项目？我们将非常感谢您的建议、提示和链接因为我不想引发宗教战争 - Maven 几乎是公司标准（相对于 Ant）

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

一笔一画续写前缘 2024-08-10 00:17:00

首先，这是您可能会发现有帮助的另一个博客。

build-tools-maven-and-coldfusion

我没有尝试过使用 Maven 构建 ColdFusion，但我有为一家大公司管理 Maven 构建的经验。有几件事需要您考虑。

项目结构

Coldfusion cfm 和 cfc 文件应该放在 src/main/resources 中，以便将它们捆绑在 jar 中（上面引用的博客覆盖了 Maven 约定，将它们放在 src 中。这是可以的，但是如果您稍后需要向项目添加其他任何内容，则可能会出现问题）。

我可能会将 cfc 和 cfm 文件保留在单独的项目中，并使用适当的依赖项声明来链接它们，这使您的 cfc 项目保持为库并有助于重用。还值得考虑氟氯化碳项目的粒度。一般来说，Maven 的依赖管理可以帮助您保持较小的工件，几乎不需要担心找到所有的 jar。

部署

交付工件的最简单方法是使用 maven -war-plugin 创建一个包含您的工件及其所有传递依赖项的战争。这使得每个应用程序都是独立的，这很有用。这样做的缺点是您最终会重复捆绑相同的工件，而且它们可能会非常大。为了缓解这种情况，您可以使用 assembly-plugin 创建自定义包，不包括通用组件，或者您可以指定某些组件（例如 ColdSpring）是提供的范围，这意味着它们不会包含在战争中。

版本管理

Maven 鼓励依赖项的扩散，默认情况下每个依赖项声明都有一个版本，这可能会导致维护问题，特别是当您想要更改外部依赖项的版本时。您可以通过定义父 POM 或“应用程序”POM 来缓解这种情况。两者都有一个 dependencyManagement 部分，声明常见工件的详细信息（groupId、artifactId 和版本）。任何从父级继承的 POM 都不需要声明依赖项版本，因为它将被继承（请注意，这并不意味着所有子级都将拥有所有依赖项，只是声明依赖项的任何 POM 都不需要声明版本）。如果您定义了一个带有打包“pom”和 dependencyManagement 部分的“app”项目，您可以使用范围 import 引用它（从 Maven 2.0.9 开始），这将从“ app”项目添加到项目 POM。有关更多详细信息，请参阅依赖项文档。

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

命名约定
您需要为包制定命名约定以避免冲突。
最好遵循 Maven 约定并使用类似 java 包的 groupId（对于 maven.apache.org 为 org.apache.maven）以及工件的 jar 名称。此约定将为 ColdSpring 提供 groupId“org.coldspringframework”和artifactId“coldspring”。

整个公司可能需要进一步区分。例如，如果您有一个 Web 和核心团队，您可以为 Web 团队提供 groupId com.mycompany.web.*，为核心团队提供 com.mycompany.core.*

依赖管理

需要将 CFC 包添加到 Maven 存储库，例如 Nexus，以便整个企业中的其他构建可以访问它们。

如果您想将 CFC 包与 jar 分开。您可以指定自定义打包类型，这样它们就不会与任何 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 的插件来描述 plexus 机制（使用什么存档器、什么扩展名）输出等）

。

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

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>

回复收藏 0 原文