创建 webapp war 发布“maven 方式”

发布于 2024-11-07 21:18:55 字数 444 浏览 8 评论 0原文

我的 web 应用程序主要包含两个工件:java-server.jar 和 js-client.war。两者都被聚合/覆盖并获取目标环境的附加属性文件。最后,我得到了战争文件。

一些 war 文件是使用 tomcat 部署的:通过脚本部署一些文件,但此时这应该不重要。

我的方法有几件事是我不喜欢的:

  • 服务器和客户端是使用 maven-release-plugin 发布的,但最终的 web 应用程序不是。
  • 仅通过最终的战争文件我无法确定它是为哪个服务器构建的。
  • 我通常同时需要多个客户端/服务器组合:当我使用稳定版本构建测试服务器时,夜间构建服务器应在最新快照上运行。

如何维护、发布和部署(到 Maven 存储库)稳定/测试版 Web 应用程序?如何维护目标服务器特定的配置设置?如何保留不同的版本?你们有很多分店吗?

谢谢,简

my webapp consists in mainly two artifacts, java-server.jar and js-client.war. Both are aggregated/overlayed and get additional property files for the target environment. Finally, i get the war file.

Some war files are deployed using tomcat:deploy some by a script but that shouldn't matter at this point.

There are several things I don't like with my approach:

  • server and client are released with the maven-release-plugin, the final webapp is not.
  • Just by having the final war file I cannot determine for which server it was built.
  • I usually need several client/server combinations at once: While I build the beta server with the stable versions, the nightly build server shall operate on the latest snapshots.

How do you maintain, release and deploy (to maven repo) stable/beta webapps? How do you maintain target-server specific configuration settings? How do you keep different versions? Do you have a lot of branches?

Thanks, Jan

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

扫码二维码加入Web技术交流群

发布评论

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

评论(3

暮倦 2024-11-14 21:18:55

我正在做的是使用 Jenkin 的额外 Maven 构建步骤在

tomcat:deploy

每次构建后执行。有了正确的 Maven 配置文件,就可以将构建指向我们的开发服务器。然后,当我们想要推送到暂存阶段时,我们使用 Maven 发布插件(再次使用 Jenkins)来创建一个版本号不是快照的版本。假设我们随后发布了 2.0beta3 版本。这是通过以下内容完成的:

tomcat:deploy -P staging-deploy

然后,配置文件确保我们推送到登台服务器而不是带有如下 pom 条目的开发服务器:

    <profile>
        <id>deploy-staging</id>
        <build>
            <plugins>
                <plugin>
                    <groupId>org.codehaus.mojo</groupId>
                    <artifactId>tomcat-maven-plugin</artifactId>
                    <configuration>
                        <server>tomcat-staging</server>
                        <url>http://tomcat-staging.internal:${tomcat-staging.port}/manager/text</url>
                        <path>${tomcat.path}</path>
                    </configuration>
                </plugin>
            </plugins>
        </build>
    </profile>

最后,从登台到上线完全是在 Maven 和 jenkins 之外完成的。我只是不相信 Maven 不会破坏:-)

What I'm doing is using Jenkin's extra maven build steps to execute

tomcat:deploy

after every build. With the right maven profile, that points the builds to our dev server. Then when we want to push to staging, we use the maven release plugin (with Jenkins again) to create a release with a version number that isn't a snapshot. Say we then release 2.0beta3 to staging. This is done with something like:

tomcat:deploy -P staging-deploy

The profile then ensures we push to the staging server instead of the dev server with a pom entry like this:

    <profile>
        <id>deploy-staging</id>
        <build>
            <plugins>
                <plugin>
                    <groupId>org.codehaus.mojo</groupId>
                    <artifactId>tomcat-maven-plugin</artifactId>
                    <configuration>
                        <server>tomcat-staging</server>
                        <url>http://tomcat-staging.internal:${tomcat-staging.port}/manager/text</url>
                        <path>${tomcat.path}</path>
                    </configuration>
                </plugin>
            </plugins>
        </build>
    </profile>

Finally, getting from staging to live is done completely outside maven and jenkins. I just don't trust maven to not break :-)

与他有关 2024-11-14 21:18:55

我建议使用 hudson 这样的构建服务器。它有 Maven 和 rcs 支持。
例如,您可以指定要构建源代码的哪个分支以及要执行的 Maven 目标。

我们还使用 hudson 将构建部署到我们的 Web 服务器。

I can recommend using a build server like hudson. It has maven and rcs support.
You can specify for instance what branch of your source code to build and what maven targets to execute.

We also use hudson to deploy builds to our web servers.

铁轨上的流浪者 2024-11-14 21:18:55

我的情况没有你那么复杂,所以我只能回答这个问题:

如何维护目标服务器特定的配置设置?

我尝试将所有配置外部化,以便将完全相同的 WAR 文件部署到 stage/prod。我为此使用 Spring 的 context:property-placeholder 标签。 WAR 中有“默认”属性文件,这些文件被 /etc/app/*.properties 中的属性覆盖(在 Windows 上为 c:/etc/app/*.properties)。

至于实际部署,我目前手动上传 WAR 文件,但计划在不久的将来实现自动化。

My situation isn't as complex as yours, so I can only answer this question:

How do you maintain target-server specific configuration settings?

I try to externalize all configuration so that I'm deploying the exact same WAR file to stage/prod. I use Spring's context:property-placeholder tag for this. There are "default" properties files in the WAR, which are overridden by properties in /etc/app/*.properties (c:/etc/app/*.properties on Windows).

As for actual deployment, I currently upload the WAR file by hand, but plan to automate this in the near future.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文