Maven"shaded"JAR在文件名中以"original"为前缀

Ste*_*ins 35 java maven-2

我正在使用"shade"Maven2插件来构建一个单独的JAR,并将所有Java依赖项捆绑在一起.相关部分pom.xml非常简单:

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-shade-plugin</artifactId>
    <version>1.4</version>
    <executions>
        <execution>
            <phase>package</phase>
            <goals>
                <goal>shade</goal>
            </goals>
            <configuration>
                <finalName>${project.artifactId}-${project.version}-SHADED</finalName>
                <transformers>
                    <transformer implementation="org.apache.maven.plugins.shade.resource.ManifestResourceTransformer">
                        <mainClass>com.mypackage.MyClass</mainClass>
                    </transformer>
                </transformers>
            </configuration>
        </execution>
    </executions>
</plugin>
Run Code Online (Sandbox Code Playgroud)

但是,构建结果很奇怪.看来这两个文件实际上是由这个Maven插件创建的:

myartifact-1.0.0-SHADED.jar  (zero bytes)
original-myartifact-1.0.0-SHADED.jar  (10 MB)
Run Code Online (Sandbox Code Playgroud)

带有前缀"original"的JAR文件已正确构建,并且运行正常.我想我可以重命名它以剥去那个前缀,并继续我的快乐方式.

但是,我非常好奇这里的"阴影"插件可能会发生什么.看起来"原始"文件是临时工作空间类型的东西,打算在进程结束时重命名,并且最终重命名根本不会完成.但是,没有明显的解释(即文件系统权限等).有没有人见过这个?

Ste*_*art 49

我知道这个问题很老,但认为值得添加以下信息.

我认为史蒂夫最初想要的输出是在maven-shade-plugin文档的这个页面上给出的.

<shadedArtifactAttached>true</shadedArtifactAttached>
<shadedClassifierName>jar-with-dependencies</shadedClassifierName>
Run Code Online (Sandbox Code Playgroud)

  • Maven 是关于合理的默认值;但是这里的 Shale 默认值几乎不合理:它更改了 jar 的内容,该 jar 具有原始默认名称而没有构建 Shale。正因为如此,一些依赖于默认命名的 jar 的 IDE 现在只有原始默认内容,因为他们看到了那个 jar 中的额外/Shaled 内容。从这个意义上说,程序集插件具有更合理的默认值 - 保持默认 jar 的原始名称和内容不变,并为胖 jar 指定一个不同的名称。 (2认同)

Ano*_*non 20

Maven的构建步骤将创建jar target/artifact-version.jar.

然后阴影插件运行.它通常将该jar重命名为target/original-artifact-version.jar,并为阴影JAR指定名称target/artifact-version.jar.

但是,您正在配置Shade插件以使用其他名称.除非有充分的理由,否则我<finalName>将从您的配置中删除,并使用Shade插件希望为您提供的内容.

  • 就是这样.叹息......我很享受与Maven的实验,我喜欢它给我带来的力量.但是,在这个社区中,我可以做很多"不要对抗Maven"和"做Maven想要的"文化.如果你要求Maven执行一个不好的练习,我可以理解抛出错误或警告信息......但是当Maven只是以错误的方式失败时,这些短语听起来像是空洞的借口.如果插件"不希望"我在`<finalName>`元素中声明一个自定义的最终名称...那么为什么要提出`<finalName>`元素作为模式的一部分?这只是一个错误. (14认同)
  • 哦,不打算抱怨你,Anon ......只是抓住了Maven及其普通社区!:) 我感谢您的帮助. (2认同)
  • 你好.你说首先Maven构建没有依赖关系的原始jar,然后使用前缀"original-"重命名它,然后使用shade plugin构建带有所有依赖项的最终jar.为什么没有依赖关系构建原始jar,然后重命名呢?是否可以设置忽略没有依赖项的原始jar的构建,并构建一个具有所有依赖项的jar?没有所有这些围绕着建造无用的罐子,然后重命名它们? (2认同)

Rob*_*ade 8

跟随@Stewart提供一个稍好的答案(对任何一个都没有冒犯:D):

你得到原始混乱的原因可以是双重的:

  1. 指定<finalName>意味着您希望名称与Maven默认提供的名称不同(即:与工件名称相同:artifactId-version.jar或artifactId-version-shaded.jar).如果您指定的最终名称与两者中的一个相同,它将尝试将旧的名称作为原始名称 - *.jar,然后使用新的阴影覆盖它.在你的情况下,你告诉它制作最终的JAR*-shaded.jar,这是Maven出现时的情况(默认情况下它们进入artifactId-version.jar之前),所以它首先支持了旧*-shaded.jaroriginal-*-shaded.jar,然后虫子写字节到新外出时*-shaded.jar给旧的消失了(他们似乎将其重命名).

  2. (这是我的情况)使用<shadedClassifierName>,只改变Maven用于生成*-shaded.jar的后缀,结合使用<finalName>也可以产生相同的结果.如果您愿意,您可以使用<shadedClassifierName>并指定不同的后缀,并且无需指定<finalName>整个内容即可完成.在我的情况下,我都设置了输出相同的名称:ie:artifactId-version-all.jar但使用'all'作为Classifier使我回到#1中描述的场景.