在大会中进行一场无休止的战争 [英] Including an unpacked War in the Assembly

查看:56
本文介绍了在大会中进行一场无休止的战争的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我有一个建立战争的项目(没问题).而且,那场战争需要与一些shell脚本一起打包.由于该战争包含的属性文件因站点而异,因此我们不能简单地按原样安装战争,而是在其中存储属性文件.这就是Shell脚本的作用.

I have a project which builds a war (no problem). And, that war needs to be packaged with a few shell scripts. Because that war contains properties files that vary from site-to-site, we can't simply install the war as is, but munge the properties files in it. That's what the shell scripts do.

我想将我的战争打包为拆开的战争.我在Assembly Descriptor中看到了<unpacked>,但是我无法使其正常工作.

I'd like to package my war in my assembly as a unpacked war. I see <unpacked> in the Assembly Descriptor, but I haven't been able to get that to work.

这是我的第一个bin.xml,我只是按原样打包战争.效果很好:

Here's my first bin.xml where I just packed the war as is. This works fine:

<assembly xmlns="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.2" 
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.2 http://maven.apache.org/xsd/assembly-1.1.2.xsd">
    <id>bin</id>
    <formats>
        <format>zip</format>
    </formats>
    <includeBaseDirectory>false</includeBaseDirectory>
    <fileSets>
        <fileSet>
            <directory>${project.basedir}/src/assembly/scripts</directory>
            <includes>
                <include>deploy.sh</include>
                <include>lock_build.sh</include>
                <include>description.sh</include>
                <include>url-encode.pl</include>
            </includes>
            <outputDirectory>/</outputDirectory>
        </fileSet>
        <fileSet>
            <directory>${project.build.directory}/${project.artifactId}-${project.version}</directory>
            <outputDirectory>${project.artifactId}</outputDirectory>
        </fileSet>
    </fileSets>
</assembly>

这是我第一次尝试打开包装:

Here's my first attempt at unpacked:

<assembly xmlns="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.2" 
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.2 http://maven.apache.org/xsd/assembly-1.1.2.xsd">
    <id>bin</id>
    <formats>
        <format>zip</format>
    </formats>
    <includeBaseDirectory>false</includeBaseDirectory>
    <fileSets>
        <fileSet>
            <directory>${project.basedir}/src/assembly/scripts</directory>
            <includes>
                <include>deploy.sh</include>
                <include>lock_build.sh</include>
                <include>description.sh</include>
                <include>url-encode.pl</include>
            </includes>
            <outputDirectory>/</outputDirectory>
       </fileSet>
    </fileSets>
    <moduleSets>
        <moduleSet>
            <includes>
                <include>{$project.groupId}:${project.artifactId}:war</include>
            </includes>
            <binaries>
                <includes>
                    <include>${project.build.directory}-${project.artifactId}-${project.version}.${project.packaging}</include>
                </includes>
                <outputDirectory>${project.artifactId}</outputDirectory>
                <unpack>true</unpack>
            </binaries>
        </moduleSet>
    </moduleSets>
</assembly>

这是我进行无包装战争的最后尝试:

Here's my last try at getting the unpacked war:

<assembly xmlns="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.2" 
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.2 http://maven.apache.org/xsd/assembly-1.1.2.xsd">
    <id>bin</id>
    <formats>
        <format>zip</format>
    </formats>
    <includeBaseDirectory>false</includeBaseDirectory>
    <fileSets>
        <fileSet>
            <directory>${project.basedir}/src/assembly/scripts</directory>
            <includes>
                <include>deploy.sh</include>
                <include>lock_build.sh</include>
                <include>description.sh</include>
                <include>url-encode.pl</include>
            </includes>
            <outputDirectory>/</outputDirectory>
        </fileSet>
    </fileSets>
    <moduleSets>
        <moduleSet>
            <binaries>
                <attachmentClassifier>war</attachmentClassifier>
                <outputDirectory>${project.artifactId}</outputDirectory>
                <unpack>true</unpack>
                <includeDependencies>true</includeDependencies>
                <dependencySets>
                    <dependencySet/>
                </dependencySets>
            </binaries>
        </moduleSet>
    </moduleSets>
</assembly>

在这最后两次尝试中的每一次尝试中,我仅打包脚本,战争没有结束.

In each of these last two attempts, I am only packaging the scripts and the war isn't coming over.

我知道我可以使用${project.build.directory}/${project.artifactId}-${project.version}目录,该目录包含战争中的几乎所有文件,但是它不包含我的MANIFEST.MF条目,其中包括将战争链接回特定的Jenkins构建和Subversion修订版的信息.

I know I could use the ${project.build.directory}/${project.artifactId}-${project.version} directory which contains almost all of the files in the war, but it doesn't contain my MANIFEST.MF entries which includes information linking the war back to a particular Jenkins build and Subversion revision.

我需要怎么做才能在我的装配体中加入无包装的战争?

What do I need to do to include an unpacked war into my assembly?

<assembly xmlns="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.2" 
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.2 http://maven.apache.org/xsd/assembly-1.1.2.xsd">
    <id>bin</id>
    <formats>
        <format>zip</format>
    </formats>
    <includeBaseDirectory>false</includeBaseDirectory>
    <fileSets>
        <fileSet>
            <directory>${project.basedir}/src/assembly/scripts</directory>
            <includes>
                <include>deploy.sh</include>
                <include>lock_build.sh</include>
                <include>description.sh</include>
                <include>url-encode.pl</include>
            </includes>
            <outputDirectory>/</outputDirectory>
        </fileSet>
    </fileSets>
    <dependencySets>
        <dependencySet>
            <outputDirectory>${project.artifactId}</outputDirectory>
            <unpack>true</unpack>
            <scope>runtime</scope>
        </dependencySet>
    </dependencySets>
</assembly>

当我运行它时,我得到了:

When I ran this, I got:

[INFO] ------------------------------------------------------------------------
[INFO] Building My Project 1.0.0
[INFO] ------------------------------------------------------------------------
[INFO] 
[INFO] --- maven-assembly-plugin:2.5.2:single (default-cli) @ myproj ---
[INFO] Reading assembly descriptor: src/assembly/bin.xml
[WARNING] Cannot include project artifact: \
          com.vegicorp:myproj:war:1.0.0; \
          it doesn't have an associated file or directory.
[INFO] Building zip: ~/workdir/trunk/myproj/target/archive/myproj.zip
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------

拉链里面是战争中所有精美的罐子,没有包装,但没有包装.

Inside the zip are all the jars in the war nice and unpacked, but not my unpacked war.

推荐答案

我知道我 应该 可以将解压后的战争添加到我的程序集中.我看到了unpack选项,并且我知道它适用于其他依赖项.但是,看来我只能通过<dependencySet><moduleSet>访问它.我 应该 可以将我的项目指定为自己的模块.一定是我做错了.

I know I should be able to add the unpacked war into my assembly. I see that unpack option, and I know it works for other dependencies. However, it looks like I can only access it via a <dependencySet> or a <moduleSet>. I should be able to specify my project as its own module. There must be something I am doing wrong.

这是我讨厌Maven的最大事情:Maven很好地向您隐藏了东西,这很不错,因为它可以阻止您执行不应做的事情.当开发人员构建Ant build.xml文件时,我讨厌它,因为大多数开发人员不了解如何进行构建,并且build.xml变得不可读.使用Maven,这不是问题.只需配置您的项目,Maven就会为您解决这个问题.

This is the big thing I hate about Maven: Maven does a great job hiding things from you which is nice because it prevents you from doing stuff you shouldn't. I hate it when developers build Ant build.xml files because most developers don't understand how to do a build, and the build.xml becomes an unreadable mess. With Maven, this isn't an issue. Just configure your project, and Maven will take care of this for you.

但是有时候Maven就像一个黑盒子,上面有一堆操纵杆和按钮.您坐在那里推动和拉动操纵杆和按钮,试图弄清楚如何使它完成您想做的事情.我花了太多时间来帮助开发人员配置他们的Maven项目.他们想做一些不同的事情,例如使用休眠或从WSDL文件构建源代码,却不知道如何让Maven来做他们想要的事情.

But sometimes Maven is like a black box with a bunch of levers and buttons. You sit there pushing and pulling levers and buttons trying to figure out how to get it to do something you want to do. I spend way too much of my time trying to help developers to configure their Maven projects. They want to do something a little different like use hibernate or build source from WSDL files, and have no idea how to get Maven to do what they want.

一个开发人员将其描述为自动驾驶汽车,无法完全驶向您想要的地方.您甚至可能会在窗口外看到目的地,但无法弄清楚如何操纵汽车的目的地才能到达目的地.

One developer describes it as a self driving car which can't quite go where you want. You may even see the destination out the window, but you can't figure out how to manipulate the car's destination to get you there.

我想做的应该很容易.我只想创建一个程序集,而不是使用压缩的war文件,而是希望将其解压缩.

What I want to do should be easy. I just want to create an assembly, and instead of using the packed war file, I want it unpacked.

在Ant中,这可以在单个任务中完成.在Maven中,这是一个神秘的过程.我想我快要走了,我可能会缺少一个小的配置参数,它将使所有工作正常进行,但是我已经花了数小时来进行此工作.

In Ant, this can be accomplished in a single task. In Maven, it's a mysterious process. I think I'm close, I am probably missing one little configuration parameter that will make it all work, but I've already spent hours working on this.

我使用了 maven-dependency-plugin 解开我的战争.我不确定这是否行得通,因为我不想依赖插件下载war,但是似乎可以理解,当我指定war时,我正在谈论当前版本,而没有下载任何内容. (我的Maven回购中甚至没有战争).

I used the maven-dependency-plugin to unpack my war. I wasn't sure whether this would work because I didn't want the dependency plugin downloading the war, but it seems to understand that when I specify my war, I am talking about the current build, and nothing is downloaded. (I don't even have the war in our Maven repo).

我还必须将Maven从2.x升级到3.x,因为我需要确保maven-dependency-pluginmaven-assembly-plugin之前运行.由于两者都在构建的 packaging 阶段中运行,因此Maven 2.x无法保证插件的运行顺序.

I also had to upgrade Maven from 2.x to 3.x because I need to make sure that the maven-dependency-plugin ran before the maven-assembly-plugin. Since both run in the packaging phase of the build, Maven 2.x can't guarantee the order the plugins run in.

一旦使用了该插件,我所要做的就是在我的程序集插件中指定解压缩战争文件的目录,并且该目录包含在我的zip中.

Once I used that plugin, all I had to do was specify the directory where I unpacked the war in my assembly plugin, and it was included in my zip.

我仍然想知道如何在程序集插件本身中使用<unpack>实体,而不用不得不使用另一个插件来解散战争.如果有人可以告诉我如何在汇编文件本身中进行解压缩,我会将其标记为正确的答案.

I still want to know how to use the <unpack> entity in the assembly plugin itself instead of having to use another plugin to unpack my war. If anyone can tell me how to do the unpack in the assembly file itself, I'll mark that as the correct answer.

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-dependency-plugin</artifactId>
    <version>2.9</version>
    <executions>
        <execution>
            <id>unpack</id>
            <phase>package</phase>
            <goals>
                <goal>unpack</goal>
            </goals>
            <configuration>
                <outputDirectory>${project.build.directory}/unwar/${project.artifactId}</outputDirectory>
                <artifactItems>
                    <artifactItem>
                        <groupId>${project.groupId}</groupId>
                        <artifactId>${project.artifactId}</artifactId>
                        <version>${project.version}</version>
                        <type>war</type>
                    </artifactItem>
                </artifactItems>
            </configuration>
        </execution>
    </executions>
</plugin>
<plugin>
    <artifactId>maven-assembly-plugin</artifactId>
    <version>2.5.2</version>
    <configuration>
        <finalName>${project.artifactId}</finalName>
        <appendAssemblyId>false</appendAssemblyId>
        <outputDirectory>${project.build.directory}/archive</outputDirectory>
        <descriptors>
            <descriptor>src/assembly/bin.xml</descriptor>
        </descriptors>
    </configuration>
    <executions>
        <execution>
            <id>make-assembly</id>
            <phase>package</phase>
            <goals>
                <goal>single</goal>
            </goals>
        </execution>
    </executions>
</plugin>

bin.xml(我的程序集)

<assembly xmlns="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.2" 
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.2 http://maven.apache.org/xsd/assembly-1.1.2.xsd">
    <id>bin</id>
    <formats>
        <format>zip</format>
    </formats>
    <includeBaseDirectory>false</includeBaseDirectory>
    <fileSets>
        <fileSet>
            <directory>${project.basedir}/src/assembly/scripts</directory>
            <fileMode>0755</fileMode>
            <lineEnding>lf</lineEnding>
            <includes>
                <include>deploy.sh</include>
                <include>lock_build.sh</include>
                <include>description.sh</include>
                <include>url-encode.pl</include>
            </includes>
            <outputDirectory>/</outputDirectory>
        </fileSet>
        <fileSet>
            <directory>${project.build.directory}/unwar</directory>
            <outputDirectory>/</outputDirectory>
        </fileSet>
    </fileSets>
</assembly>


实际答案

由于khmarbaise的链接(请参阅下面的评论),我复制了该项目的程序集插件,并且几乎正常工作.像我的尝试一样,它解压缩了所有运行时jar,而不仅仅是我想要的一个.但是,它也使我的战争也结束了.


The ACTUAL Answer

Thanks to khmarbaise's link (see the comment below), I copied that project's assembly plugin and it almost worked. Like my attempt, it unpacked all the runtime jars, and not just the one I wanted. However, it also unpacked my war too.

该链接的答案和我的尝试之间只有两个区别:

There were only two differences between that link's answer and my attempt:

  • 他们包括了<useProjectArtifact>true</useProjectArtifact>,而我没有.但是,这默认为true.删除它仍然可以使其正常工作.
  • 它们在<outputDirectory>中目录名称的前面包括一个/.删除它没有任何作用.
  • They included <useProjectArtifact>true</useProjectArtifact> and I didn't. However, this defaults to true. Removing it still allowed it to work.
  • They included a / in front of the directory name in the <outputDirectory>. Removing this made no difference.

这意味着它现在与我以前尝试过的匹配.所以,为什么这次能正常工作.

This meant that it now matched what I had previously tried. So, why was it working this time.

结果是,我正在通过简单地运行mvn assembly:single来测试程序集更改.毕竟,当我只是想使程序集正常工作时,为什么要整个构建并重新打包.仅运行mvn assembly:single时-即使所有内容都已打包,也会出现此错误:

Turns out, I was testing the assembly changes by simply running mvn assembly:single. After all, why do the whole build and repackage when I am simply trying to get the assembly to work. When you run just mvn assembly:single -- even though everything is already packaged, you get this error:

[WARNING] Cannot include project artifact: \
      com.vegicorp:myproj:war:1.0.0; \
      it doesn't have an associated file or directory.

您的战争并没有结束.但是,如果将程序集置于打包阶段,然后运行mvn package,那么一切都会变得很简单.

And your war isn't unpacked. However, if you put the assembly into the package phase, and then run mvn package, everything works out just nifty.

然后我花了一些时间试图发动战争,而不是与之相关的所有运行时材料.我使用<includes/>来执行此操作,但是因为我打仗而不是罐子,所以必须在我的<include>中包括一个分类器.

I then spent time trying to just get my war and not all the associated runtime stuff with it. I used <includes/> to do this, but because I have a war and not a jar, I had to include a classifier in my <include>.

最后,我一切正常.我的程序集中有这个:

At last, I have everything working. I have this in my assembly:

<dependencySets>
    <dependencySet>
        <outputDirectory>${project.artifactId}</outputDirectory>
        <unpack>true</unpack>
        <scope>runtime</scope>
        <includes>
            <include>${project.groupId}:${project.artifactId}:*:${project.version}</include>
        </includes>
    </dependencySet>
</dependencySets>

只要我运行mvn package,它就可以工作.

And as long as I run mvn package, it works.

这比我使用maven-dependency-plugin时要好得多.现在,与程序集有关的所有信息都在程序集XML文件中.

This is way better than what I had with the maven-dependency-plugin. Now, all of the information having to do with the assembly is in the assembly XML file.

这篇关于在大会中进行一场无休止的战争的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆