NOTE: bold print is NOT implemented yet.
This plugin for Maven 2 allows you to compile native code (c++, c and fortran) on a number of different architectures (Linux, Windows, MacOSX, Solaris, ...) and with a number of different compilers/linkers (g++, Microsoft Visual C++, CC, ...) The output produced is wrapped up in Native ARchive files (.nar) some of which are machine independent (-noarch), while others are machine specific and thus depend on a combination of machine architecture(A), operating-system(O) and linker(L) identified as AOL. These nar files can be installed in the local maven repository and deployed to a standard maven (web) server, using the standard maven-install-plugin and maven-deploy-plugin.
Other maven projects may specify dependencies on these nar files using the standard maven dependency declaration. Nar files get downloaded, unpacked and installed in the local maven repository, just like jar files are (apart from the unpacking).
The NAR plugin executes the following goals, in the order below, to create and deploy nar files. The goals are part of the nar packaging/lifecycle, which inserts the nar goals into the standard lifecyle. Using nar packaging allows you to build a jar file as well as nar files. The list below shows the sequence of the NAR goals:
The NAR Plugin starts off by setting and deducing all kinds of property values for usage in the goals below. The configuration section of the NAR plugin allows one to override most of the default settings. The default settings come from the AOL properties file which allows us to specify different defaults depending on the architecture-os-linker combination, see AOL Properties.
The NAR Plugin tries to deduce the "Operating System" and the "Architecture" of the machine. Both can be overridden by setting os and arch in the configuration.
The name of the linker is looked up in a architecture-os specific way, but can be overridden by setting linker.name (this means the subtag <name> of the <linker> tag in the configuration section). Now that the linker name is known all other properties are looked up with a prefix of [arch.[os.[linker.]]] from the AOL Properties file, but can be overridden in the configuration section (which can be made AOL specific by putting it inside a profile.
The NAR plugin makes sure the linker name can be found and that at least one compiler exists for this linker. It further check the version number of the linker to see if the linker is actually found on the path.
Your NAR artifact(s) may be dependent on other nar artifacts. The standard maven dependency declaration in the POM is used to describe such dependencies of type "nar", see nar-dependencies. By the time this goal is running maven will have already downloaded all dependent jar and nar files some of which may include a nar.properties file. This property file contains information on what other machine dependent and machine independent nar files to download. This goal will download any further necessary nar files into the local repository.
Since a nar file is of no use to any native compilation process the nar-unpack goal unpacks the nar into the "nar/dependencies" subdirectory of the target directory.
If you store files in the gnuSourceDirectory (src/gnu) the NAR plugin will try to run autogen and configure over them with a target set to gnuTargetDirectory. This process can be inhibited by setting gnuAutogenSkip and or gnuConfigureSkip and normally does not take place on Windows, unless gnuUseOnWindows is set. The generated and configured files are all stored in gnuTargetDirectory and will be handled in subsequent NAR goals.
This goal generates a NarSystem class if necessary. This class contains helper methods for your code to handle things at run-time. The static method "loadLibrary()" is currently the only method generated and will load your JNI library with name "artifactId-version". This goals only executed if you produce a JNI library and you specify a packageName as subtag of library. The NarSystem class will then end up in this package.
This is an optional goal. It will take any resources in src/nar/resources and copy them into specific areas under target/nar. Resources may include pre-compiled/linked libraries and other shareable items. This goal can be used to create a nar library from a distribution that comes with compiled shareable libraries.
Copies the resourceIncludeDir (include) from the gunSourceDirectory (src/gnu) into the noarch area inside target.
This goal will run the javah tool on any class file in the javah.classDirectory directory that has native methods in it. The actual class files are inspected (rather than their sources). The javah tool is picked up from the java installation and is run with a classpath of the javah.classDirectory and all depencies' classpaths, unless you specify a list in javah.classPaths. You can also set a boot classpath using javah.bootClassPaths.
This goal has no effect if there are no java sources, or if none of the java classes contain a native method.
runs "make" followed by "make install" to put the final files in position for copying to the NAR target areas by the nar-gnu-process goal.
This goal will compile the native source code (c, c++ or fortran) and archive it into a shared library. You can also produce a jni or a static library by setting library.type. To handle the variety of compilers and linkers, the NAR plugin uses the cpptasks from the ant-contrib project, with some minor improvements and additions of compilers, see cpptasks. Most of the settings for cpptasks, such as compiler, linker, options and include dirs are available through the NAR plugin, see configuration.
The NAR plugin searches the directory structure under COMPILER.sourceDirectory, which defaults to src/main. The standard way to separate your sources for different languages would be src/main/c, src/main/c++ and src/main/fortran, but any file under src/main is searched for.
The nar plugin will automatically select the correct compiler (c, c++ or fortran) based on the type of source, as specified in the patterns in AOL.c.includes, AOL.cpp.includes and AOL.fortran.includes, where AOL is a dotted qualifier of the architecture, os and linker (x86.Windows.msvc for example).
Include paths are added in this order from:
The static or dynamic library is linked against:
All include files from COMPILER.includePaths are copied to be included in the noarch nar file.
TBD If you set maven.nar.includefilesonly to true the compilation step will be skipped. This flag can be used if you want to distribute a library that only contains pure abstract classes in include files.
Copies the gnu "install"-ed area into the NAR target area for testing and packing.
This goal will compile the native test source code (c, c++ or fortran) and create executables from it. To handle the variety of compilers and linkers, the NAR plugin uses the cpptasks from the ant-contrib project, with some minor improvements and additions of compilers, see cpptasks. Most of the settings for cpptasks, such as compiler, linker, options and include dirs are available through the NAR plugin, see configuration.
The NAR plugin searches the directory structure under COMPILER.sourceDirectory, which defaults to src/test. The standard way to separate your sources for different languages would be src/test/c, src/test/c++ and src/test/fortran, but any file under src/test is searched for.
The compiler will automatically select the correct compiler (c, c++ or fortran) based on the type of sources, as specified in the patterns in AOL.c.includes, AOL.nar.src.includes and AOL.fortran.includes, where AOL is a dotted qualifier of the architecture, os and linker (x86.Windows.msvc for example).
TBD If you set maven.nar.includefilesonly to true the compile-tests goal will be skipped.
Runs any native tests as well as any executables that have been produced.
This goal creates the artifact jar/nar file(s). The jar file is created by the standard package goal. The following jar and nar files are created:
This goal runs tests against the packaged jar and nar files. Currently this is useful only to test a jni library. The jni library is added to the java.library.path and the tests are forked to pick up this path.
To use this goal you need to put the test sources in the regular test directories but disable the running of the tests by the maven-surefire-plugin.
TBD integration tests for other types of libraries than jni
This goal installs the produced artifacts in your local repository. The unpacking is done in the unpack goal of a dependent artifact upon first usage.
This goal deploys the produced artifacts on a maven (web) server. The jar and nar files only consists in their full form on the server and are never unpacked on the server.