I'm putting Maven build around cluster of amateur, poorly written and frankly - primitive C/C++ code (meaning some C, some C++). Problem is - there's lots of it in circulation currently and cannot be easily replaced. Building it requires a lot of tribal knowledge (you have to go from cube to cube just to find out how to compile/build various parts) and releasing is total nightmare. (No - I'm not going to rewrite it, plz don't ask)
My question is - should I use maven-native-plugin to replace multitude of short makefiles or use exec-maven-plugin to simply execute these?
I had pretty good experience so far with the latter doing .NET and don't know if I should invest into native plugin or stay with exec? If you had experience with "Mavenizing" C/C++ I would love to get some advice.
views:
835answers:
2I highly recommend the maven-nar-plugin. I find it superior in many ways to the alternatives. It doesn't require listing out source files, handles multiple OSes and architectures, handles unit and integration tests, and generally follows "the maven way". It introduces a new kind of packaging - the NAR, or "native archive", that contains the artifact you care about (.dll, .so, .a, .exe, etc.) but also metadata, headers, etc. in a way that makes sense.
It does require a bit of up front work to package third-party software up into NARs, but its pretty straightforward. Once they are NARs, you simply use the normal Maven dependency mechanism to link with them, for example:
<dependency>
<groupId>cppunit</groupId>
<artifactId>cppunit</artifactId>
<scope>test</scope>
</dependency>
One drawback is that it does not appear to be actively maintained, but it is full-featured and is a rather impressive example of Maven plugin authoring.