使用 Hudson 时出现 Maven WAR 覆盖问题人工工厂
我们有三个工件：
common.jar : with common classes.
public.war : depending on the common.jar, contains only public site resources.
internal.war : depends on both common.jar and public.war, adding authentication
information and security context resource files. Also contains
few administration site classes.
目前我已经以这种方式构建了这些工件，internal.war 用 public.war 覆盖本身。
在本地构建项目，将工件安装到本地存储库，效果非常好。
当尝试让 Hudson 构建按照以下顺序工作时，问题就开始了：
- 按依赖顺序构建所有项目。
- 修改common.jar（例如，添加一个新的类方法）
- 修改internal.war 类，使其在编译时依赖于第2 步中所做的更改。
- 提交这两项更改，触发 Hudson 构建。
- Internal.war 构建失败，因为它找不到步骤 2 中添加的符号。
不知何故，步骤 5 中的构建使用旧版本的 common.jar，并因此失败。
common.jar 版本号不会更改，在此示例中假设它是 1.0.0-SNAPSHOT。
如果我确实更改了 common.jar 版本号，则构建可以正常工作。 （据说是因为发布版本号只有一个发布）。
现在，什么可能导致 Hudson 构建中使用旧工件？
我们正在 Hudson 上运行 Maven 构建，命令“clean package -e -X -U”
已选中“将工件部署到 Maven 存储库”。
We have three artifacts:
common.jar : with common classes.
public.war : depending on the common.jar, contains only public site resources.
internal.war : depends on both common.jar and public.war, adding authentication
information and security context resource files. Also contains
few administration site classes.
Currently I have structured these in such way, that internal.war overlays itself with public.war.
Building the project locally, installing the artifacts to local repo, works perfectly.
Problems start when trying to get the Hudson builds working with following sequence:
- Build all projects in dependency order.
- Modify common.jar (say, add a new class method)
- Modify internal.war classes in such way that they are compile-time dependent on changes done in 2. step.
- Commit both changes, triggering the Hudson builds.
- Internal.war build fails because it can not find the symbols added in step 2.
Somehow the build in step 5. is using an old version of the common.jar, and failing because of it.
The common.jar version number does not change, let's say it's 1.0.0-SNAPSHOT for the purposes of this example.
If I DO change the common.jar version number, the build works. (Supposedly because there is only one release by a release version number).
Now, what could cause this using of old artifacts in Hudson builds?
We are running maven builds on Hudson with command "clean package -e -X -U"
"Deploy artifacts to maven repository" has been checked.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
如果不访问真实的 poms，很难明确回答这个问题，但我会这样做：
1）确保 Hudson 使用与本地计算机上完全相同的 Maven 版本
2）检查有效的 pom.xml通过
mvn help: effective-pom在终端中的 Hudson 机器上运行internal.war，确保您正在运行与 Hudson 作业相同的 mvn 可执行文件。您需要验证internal.war的有效pom.xml中common.jar的版本。由于配置文件或 settings.xml 的差异，它可能与您的预期不同。3) 检查 Hudson 安装的 Maven 的 settings.xml 文件。特别是，您需要验证您的发行版管理、服务器和存储库节中的一切是否正常。检查这一点的另一个好方法是转到您的internal.war项目并运行
mvn help: effective-settings并查看其中的内容是否与本地计算机上的内容匹配。有些地方出了问题，通过正确的分析很快就能找到。
It's hard to definitively answer this without access to the real poms, but here is what I would do:
1) Make sure Hudson is using the exact same version of Maven as you are on your local machine
2) Examine the effective pom.xml of internal.war on the Hudson machine in a terminal via
mvn help:effective-pommaking sure you are running the same mvn executable as your Hudson job does. You need to verify the version of the common.jar in the effective pom.xml of internal.war. It could be different than what you expect due to profiles or settings.xml differences.3) Check the settings.xml file for your Hudson install of Maven. In particular you need to verify all is well in your distributionManagement, servers, and repositories stanzas. Another good way to check this is to go to your internal.war project and run
mvn help:effective-settingsand see if what is there matches what is on your local machine.Something is awry and it won't take long to find with the right analysis.