使用MinGW编译器和nar-maven-plugin避免依赖于机器的POM

时间:2017-06-29 21:16:57

标签: java c++ maven java-native-interface maven-nar-plugin

我有一个简单的基于JNI的项目,可以试用nar-maven-plugin。我正在运行Windows 10并且正在使用MinGW编译器。我正在将本机代码编译为C ++而不是C,尽管我认为这对于这个问题并不重要。 (“真实”项目中的本机实现将使用C ++,因此,一旦我超越了这个初始测试,只需更改它就不是一件容易的事。)

为了通过Eclipse IDE使用maven install进行构建,我需要在POM文件中明确指定链接器作为插件configuration的一部分。相关部分如下:

        <plugin>
            <groupId>com.github.maven-nar</groupId>
            <artifactId>nar-maven-plugin</artifactId>
            <version>3.5.1</version>
            <extensions>true</extensions>
            <configuration>
                <linker>
                    <name>g++</name>
                    <options>
                        <option>-Wl,--kill-at</option>
                    </options>
                </linker>
                <libraries>
                    <library>   
                        <type>jni</type>
                        <narSystemPackage>com.mycompany.sandbox</narSystemPackage>
                    </library>
                </libraries>
            </configuration>
        </plugin>

如果我这样做,那么我在本地机器上很好,但我相信我已经将我的POM专门用于某些机器/连接器。如果我把它完全拿出来,那么我会收到这个错误:

[INFO] --- nar-maven-plugin:3.5.1:nar-validate (default-nar-validate) @ nar-test ---
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 0.786 s
[INFO] Finished at: 2017-06-29T17:05:34-04:00
[INFO] Final Memory: 8M/23M
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal com.github.maven-nar:nar-maven-plugin:3.5.1:nar-validate (default-nar-validate) on project nar-test: Execution default-nar-validate of goal com.github.maven-nar:nar-maven-plugin:3.5.1:nar-validate failed. NullPointerException -> [Help 1]

如果我离开<name>g++</name>部分并仅删除选项,那么它会编译,但我的测试失败,因为它无法在运行时链接到本机实现。 (这与--kill-at标志和已知问题有关,所以这并不是一个可怕的惊喜。)

有没有一种已知的方法可以处理这个问题,这样我就能得到一个与机器无关的POM?

2 个答案:

答案 0 :(得分:1)

这是Build Profiles的典型用例:

  

然而,有时便携性并非完全可能。 [...]在其他时候,您甚至可能需要在构建生命周期中包含整个插件,具体取决于检测到的构建环境。

因此,将不同的插件配置放入配置文件中,并在构建时相应地激活它们。

另一种方法是使用如下属性:

<option>${options}</option>

在以下情况下用以下值定义:

mvn ... -Doptions=-Wl,--kill-at

答案 1 :(得分:1)

Gerold Broser的回答似乎与我想要的相反,但它确实让我走上了使用配置文件的正确道路。对我来说,其中一个技巧就是要意识到在配置文件中对单个插件进行部分规范,同时在主build部分中为同一个插件添加其他参数是可以的。虽然在这种情况下不需要,因为我不需要在默认情况下指定任何不同的内容,但我也得出结论,我在默认设置上需要activeByDefault而不是{ {1}}正如所建议的那样。

为完整起见,工作POM的相关部分如下:

activeProfiles