Maven，Hudson和动态Clearcase视图 [英] Maven, Hudson and Dynamic Clearcase Views

问题描述

这是从询问Apache Maven和IBM Rational ClearCase是否集成得很好的问题开始的.我以为我应该写出我发现的内容-需要进行各种编辑，但是我最终将设法添加所有希望的内容.

环境

ClearCase -ClearCase 7.0.1.2版.

Maven -全部来自 Maven网站.

>

哈德逊-直接从哈德森网站

---

问题

• Maven是否从VOB运行?

我将所有版本的Maven2安装到了一个堆叠的" VOB中，即我添加了2.0版-对其进行了标记，锁定了该标签-然后在顶部添加了2.0.1.

为了防止存在无关的文件，我在clearfsimport中使用了-rnname标志.

这样，我可以简单地使用标签来指定我想要在我的配置规范中访问的Maven版本，但是仍然保持Maven可执行文件的相同路径-/maven/bin/mvn.

一旦安装了所有版本，我就可以通过 Dynamic 视图从那里运行Maven了.像往常一样，将存储库从Nexus的内部安装下载到用户的主目录-这样可以避免签入和签出的任何麻烦.

将该工具保留在源代码控制中的一个好处是，您可以设置公司范围的设置(例如，指向内部存储库)-然后在任何平台上从VOB运行该Maven的单个实例，该实例将保留您的设置原始设置！

在Maven项目中，我仅将src目录和pom.xml保留在源代码控制中，因为其他所有内容随后都可以自动生成.

• Hudson是否与ClearCase合作?

我将Hudson设置为与ClearCase Dynamic Views一起运行没有问题.它所要做的只是从Hudson的工作目录到视图根目录(在本例中为/view/xxx)的符号链接. ClearCase插件成功运行了 ct lshistory ，以查找开发人员合并到的集成分支中是否有任何更改.

我确实编写了一个小脚本来设置作业的初始环境-仅设置config.xml和动态视图符号链接-以便在作业中列出正确的视图，并且初始设置正确.然后，用户进行的任何增强操作都将更改为默认模板，而不是他们自己进行设置.

在Hudson的总体设置中，我使用$ CLEARCASE_VIEW环境变量来设置Maven可执行文件的路径.这样，Maven的版本取决于配置规范中设置的版本-而不是他们在Hudson中选择的版本.

这可以节省我(管理员)和用户这两个方面的额外管理.

• 您使用了什么内部存储库管理器?

我将Sonatype Nexus设置为内部存储库管理器-主要是因为我阅读了解决方案

我在ClearCase之外有一些Maven存储库，用于某些第三方库的引用.

但是我从来没有将Maven 与一起使用，因为它们遵循不同的逻辑(Maven需要文件的签名名称，例如myfile-1.2.jar，而ClearCase只能存储myfile.jar并记录它标有1.2的事实)

这可能已经由 Maven2 ClearCase插件改变了. "https://stackoverflow.com/questions/298228#298239">romaintaz ，但是此新产品中仍然存在一些错误，如此

This led on from the question about asking if Apache Maven and IBM Rational ClearCase integrated well. Thought I should write up what I found out - will require various edits, but I shall eventually get round to adding it all I hope.

Environment

ClearCase - Version 7.0.1.2 of ClearCase.

Maven - All of them, from the Maven website.

Hudson - Version 1.307 downloaded straight from the Hudson website

---

Questions

• Does Maven run from a VOB?

I installed all the versions of Maven2 into a VOB 'stacked', i.e. I added Version 2.0 - labelled it, locked the label - then added 2.0.1 on top.

To prevent there being extraneous files, I used the -rnname flag in clearfsimport.

This way, I could simply use a label to specify the version of Maven I wanted access to in my configuration spec, but still keep the same path for the maven executable - /maven/bin/mvn.

Once all the versions were installed, I had no problem running Maven from there via a Dynamic View. Repositories are downloaded from an internal installation of Nexus to the users home directory as normal - and this saves any problems with checking in and out.

A benefit of keeping the tool in source control is that you can set company-wide settings (such as pointing to a internal repository) - then run that single instance of Maven from the VOB on any platform, which retains the settings you originally set!

In Maven projects, I only kept the src directory and the pom.xml in source control, as everything else can be auto-generated afterwards.

• Does Hudson work with ClearCase?

I had no problem setting up Hudson to run with ClearCase Dynamic Views. All it took was a symlink from the working directory for Hudson to the root of the view (in this case /view/xxx). The ClearCase plugin successfully ran ct lshistory to find if there had been any changes in the integration branch that developers merge into.

I did write a small script to set-up the initial environment for a job - just the config.xml and dynamic view symlink - so that the correct view was listed in the job and the initial settings were correct. Any enhancements by the users afterwards were then changes to the default template, rather than them setting it up themselves.

In the overall settings of Hudson, I used the $CLEARCASE_VIEW environment variable to set the path to the Maven executable. That way, the version of Maven depended on the version set in the configuration specification - rather than the one they selected within Hudson.

This saves extra administration on both the part of me (the admin) and my users.

• What Internal Repository Manager did you use?

I set up Sonatype Nexus to be the Internal Repository Manager - primarily because I read in the Sonatype blog that Hudson was going to get more integrated with Nexus, and we may as well be prepared for new enhancements in the future. I also believed, when I got it set up and tried it, that it was more prepared for a large commercial environment because you could tune the groups within the repository manager to be more flexible - useful for a great number of projects.

解决方案

I have some Maven repositories outside of ClearCase, for some third-parties libraries referential.

But I have never used Maven with ClearCase since they follow a different logic (Maven needs signed names for files, like myfile-1.2.jar, whereas ClearCase can store only myfile.jar, and record the fact it is version labeled 1.2)

That may have changed with the Maven2 ClearCase plugin reported by romaintaz, but there is still some bugs in this new product, as shown by this thread, when one runs it a second time without unco'ing the pom file. Maven is getting through the checkout fine but is not able to whatever the next step is.

INFO Checking out file: /opt/viewstore/common/maven/my_lf_ss/vobs/test_alm/LF_Build/pom.xml
INFO ERROR BUILD FAILURE
INFO INFO Unable to enable editing on the POM
Provider message:
The cleartool command failed.
Command output:
cleartool: Error: Element "/opt/viewstore/common/maven/my_lf_ss/vobs/test_alm/LF_Build/pom.xml" is already checked out to view "my_lf_ss".

这篇关于Maven，Hudson和动态Clearcase视图的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！