分发要包含在构建中的通用 ant 文件有哪些好方法？
我在一个团队工作，我们生产许多小型应用程序，并在构建过程中使用 ANT。
我们希望以通用的方式容纳一些常用的指令。目前，我们需要将驱动器映射到公共位置，并且使用
<import file="${env.MAPPED_DRIVE}/common_directive.xml">
必须有更好的方法来分发公共ant文件以包含在许多项目中，而无需映射驱动器。您还有其他建议吗？
Import 是一个“顶级”指令，这意味着它无法在目标内部工作。因此，我不能简单地创建一个下载文件的目标，然后导入它。
I work in a group where we produce many small apps, and use ANT for our build processes.
We would like to have some of our commonly used directives housed in a common way. Currently, we require a mapped drive to a common location, and use
<import file="${env.MAPPED_DRIVE}/common_directive.xml">
There must be a better way to distribute a common ant file to include in many projects without having to map a drive. Do you have any other suggestions?
Import is a "top level" directive, which means it won't work inside of a target. Therefore, I cannot simply create a target that downloads the file, and then import it.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
如果您使用 ANT 1.8+，您可以指定一个 URL 并托管通用的在网站上构建片段。
If you are using ANT 1.8+, you could specify a URL and host the common build fragment on a website.
我已经制定了一个解决方案，在目录中创建一个包含可重用构建脚本的 jar 文件，例如 com/example/ant/sharedbuild，该文件可以在 Ant 1.8 中导入：
在我的例子中，这定义了所有“公共”目标为项目进行基于 java 的构建。
语法有点冗长，尤其是当我添加越来越多的包含文件时（例如，添加创建 OSGi jar 的功能）。通过将包含 Macrodef 和 scriptdef 组合的 antlib.xml 添加到 jar 文件（与共享构建脚本位于同一目录中），构建文件现在看起来像这样（现在还创建了一个 OSGi jar 包）：
不幸的是，我无法共享 Macrodef 或 scriptdef 中的代码，但实际上这并不难：用一点 JavaScript 来解析 using 属性并循环每个属性，从中派生文件名，然后导入。
我在硬盘上的固定位置（相对于我的项目）引用了 jar 文件。我认为我们可以做得更好。理想情况下，我想从中心位置获取（版本控制！）jar 文件。由于我们已经在使用 Ivy（带有 HTTP 存储库），我们可以在那里发布 jar 文件（同样带有版本）并直接从那里获取它：
这样做有一些问题：
为了缓解这些问题，在每个包含 build.xml 的目录中，我还有一个 bootstrap.xml （名称并不重要）。然后，每个 build.xml 都包含此文件：
每个 bootstrap.xml 至少包含其父级的 bootstrap.xml：
顶级 bootstrap.xml（根），然后执行获取 jar 文件并创建自定义的工作任务，如上所述：
虽然与问题没有直接关系，但我实际上正在将 Macrodef 和 scriptdef 重新加工成自定义 ant 任务，因为我希望能够支持如下所示的语法：
我应该指出，只是创建可再发行的版本并不意味着它会有用。您仍然需要投入时间和精力来创建符合类似特征的设计的内聚的、模块化的、一致的实现。这一点更为重要，因为您需要跨项目、跨团队、跨组织边界等共享脚本。
总之，通过创建带有版本号的 jar 文件，该文件可以独立于特定文件位置或 SCM 工具进行分发我们可以获得真正共享但可复制的构建。
I've worked out a solution that creates a jar file containing our reusable build scripts in a directory, say com/example/ant/sharedbuild, which can be imported in Ant 1.8:
In my case this defines all of the "public" targets for the project to do a java-based build.
The syntax is a little verbose, especially as I add more and more include files (say, to add the ability to create an OSGi jar). By adding an antlib.xml that contains a combination of a macrodef and scriptdef to the jar file (in the same directory as the shared build scripts), the build file can now look like this (and now also creating an OSGi jar bundle):
Unfortunately, I can't share the code in the macrodef or scriptdef, but really it isn't hard: a little javascript to parse the using attribute and loop over each, derive a file name from it, and import.
I reference the jar file in a fixed location (relative to my project) on my hard drive. I think we can do better. Ideally, I'd like to fetch a (versioned!) jar file from a central location. Since we're already using Ivy (with an HTTP repository) we can publish the jar file there (again, with a version) and fetch it directly from there:
There are some problems with this:
To mitigate these problems, in each directory containing a build.xml I also have a bootstrap.xml (the name doesn't really matter). Each build.xml then includes this file:
Each bootstrap.xml, at a minimum, includes it's parent's bootstrap.xml:
The top-level bootstrap.xml (the root), then does the work of getting the jar file and creating the custom tasks, as above:
Though not directly related to the question, I'm actually reworking the macrodef and scriptdef into a custom ant task, because I want to be able to support a syntax that looks like this:
I should point out that just creating a redistributable build doesn't mean it's going to be useful. You still need to put in the time and effort to create a cohesive, modular, consistent implementation in line with a design of similar characteristics. This is more important as you need to share scripts across projects, across teams, across organizational boundaries, etc.
In conclusion, by creating a jar file, with a version number, that can be distributed independent of a specific file location or an SCM tool we can get real shared but reproducible builds.
Dominic Mitchell 关于 URL 引用的评论是一个坏主意，如果你想要可重复的构建，这让我思考......
如果您使用 SVN 进行版本控制，则需要考虑的另一个解决方案是创建 SVN 外部定义，指向
common_directive.xml。然后，只需使用 ANT 导入文件引用的相对路径即可。
Dominic Mitchell's comment about the URL reference being a bad idea if you want repeatable builds got me thinking...
Another solution to consider, if you are using SVN for version control, is to create an SVN Externals Definition that points to the
common_directive.xml.Then, just use a relative path for your ANT import file reference.