Hi Vincent,
Vincent Hardion wrote at Dienstag, 18. August 2009 01:00:
> Hi,
[snip]
>> Agree and it's quite pain with platform dependent languages such
>> C/C++
>> How do you cope with this problem ?
>
> In fact, there are more than one variable in this problem. In C++, we
> have to think also with release/debug mode et static/shared linking
> for library.
>
> We tried several solutions. The most integrated to maven should be to
> set the classifier field of pom used to distinguish jdk.
> But It doesn't work for 2 reasons :
> Nar plugin doesn't support it all (I had more than patch it)
Are you sure about this. We don't have such a deep dependency tree like you,
but for us the original plugin works using a forth "dummy" part in the
classifier:
================ %< ================
<project>
[...]
<plugin>
<groupId>org.freehep</groupId>
<artifactId>freehep-nar-plugin</artifactId>
<executions>
<execution>
<goals>
<goal>nar-download</goal>
<goal>nar-unpack</goal>
<goal>nar-assembly</goal>
</goals>
</execution>
</executions>
<configuration>
<classifiers>
<classifier>x86-Windows-msvc-DUMMY</classifier>
</classifiers>
</configuration>
</plugin>
[...]
<dependencies>
[...]
<dependency>
<groupId>com.acme.demo</groupId>
<artifactId>demo-dll</artifactId>
</dependency>
[...]
</dependencies>
[...]
</project>
================ %< ================
We got this insight also by code inspection of the NAR plugin. We have no
idea, what this 4th component in the classifier should be used for
normally, but it is necessary for the nar plugin to reference it.
[snip]
- Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
