如何为Jetty的Maven Cargo插件指定jetty-env.xml文件？
我正在从Maven的jetty插件迁移到Cargo插件（cargo-maven2-plugin），因为Cargo将很乐意从依赖的Maven模块运行WAR。 在web-app中，我们花了很大力气通过JNDI外部化所有配置。 这些JNDI定义是特定于Web应用程序的，因此放在WAR外部的jetty-env.xml文件中。 使用Jetty插件，我们将此文件指定如下：
org.mortbay.jetty maven-jetty-plugin ${basedir}/target/config/jetty-env.xml 如何在Cargo Plugin中指定它？ 这是我到目前为止的配置。 当然，由于缺少JNDI配置，它会失败：
org.codehaus.cargo cargo-maven2-plugin jetty6x embedded com.mycompany my-war-module war / false ......
根据CARGO-804 ，Cargo的Jetty部署者现在支持在你的战争中嵌入jetty-env.xml （从版本1.0.3开始）。
为了使jetty-env.xml保持在“真正的”战争之外，我的建议是创建一个额外的war模块来托管jetty-env.xml文件并配置Cargo来合并WAR文件 （特别注意
我有同样的问题，希望有一个干净的安装。 我没有被WAR文件的合并所吸引。 相反，我使用程序集来维护所有外部属性的ZIP文件。 作为一个单独的模块，我可以将ZIP文件的内容部署到JETTY环境。 反过来，我利用Jetty如何使用Web应用程序的名称来加载一个免费的环境文件（对于webapps / foo.war，Jetty使用contexts / foo.xml进行配置）。 因此，虽然它不像纯货物解决方案那么紧凑，但我更喜欢它，因为WAR文件在整个推广过程中都没有掺杂。 该解决方案也是管理所有配置活动的一般机制。 如果有人有兴趣，我可以指出更多细节。
Mond的回答引发了一个想法，也许我可以使用Cargo的配置将我的（重命名的和略微修改的）jetty-env.xml存入“contexts”目录。 令我惊讶的是Just Worked。 我在这做了什么：
对于我的货物配置，我添加了以下内容：
${basedir}/../config/jetty-env.xml contexts ${jetty6.context}.xml
但为了将我的jetty-env.xml转换为真正的context.xml，我添加了以下内容：
- org.mortbay.jetty.webapp.WebInfConfiguration
- org.mortbay.jetty.plus.webapp.EnvConfiguration
- org.mortbay.jetty.plus.webapp.Configuration
- org.mortbay.jetty.webapp.JettyWebXmlConfiguration
- org.mortbay.jetty.webapp.TagLibConfiguration
/${jetty6.context} true
我担心CARGO会在它复制我的文件后转储它自己的上下文文件，但它很聪明，可以最后复制我的文件。
我想做的其他事情是过滤属性。 到目前为止我有这个：
deploy-properties false properties zip UserFromDeploymentPom PasswordFromDeploymentPom ${project.groupId} ${deployable.artifactId} ${deployable.classifier} ${deployable.type} ${project.version} maven-dependency-plugin process-resources unpack ${project.groupId} ${deployable.artifactId} ${deployable.classifier} ${project.version} ${deployable.type} true /tmp/${deployable.artifactId} maven-resources-plugin 2.4.3 copy-resources package copy-resources ${deploy.jettyHome} true /tmp/${deployable.artifactId} true
它比我喜欢的要复杂一些，但允许我在将它们添加到Jetty时过滤属性。 这使得可以使用系统属性覆盖密码和其他机密数据。 我们正在使用Bamboo（我猜哈德森是相似的），人们可以调整每个环境的计划。 计划可能受访问控制。 这使我们可以在一个地方设置所有部署属性，因此不再有管理员在Unix机器上进行攻击。