The native keyword in Java indicates that the actual code will be accessed via
a JNI procedure.
The javah will read a set of java source files and create a C header file for all
of the methods using the native keyword. In maven, the javah program is called using
the exec-maven-plugin (groupId:org.codehaus.mojo, artifactId:exec-maven-plugin).
In the current pom.xml file, the procedure is marked as belonging to the process-classesi phase and the
exec goal. However, the Eclipse IDE complains that the process-classes phase is
not supported.
In the pom.xml file, the plugin executes javah by running against the following
files and then putting the header file in Native/CoreMidi4J/CoreMidi4J.h
If there are any changes to the header file, the C++ (.cpp) files will have to be rewritten to correspond to the new version of the header file. It would probably be best to put notes in the code for the Java classes listed above that any changes to the native methods will require rerunning javah and modifying the C++ code. Since running javah will therefore produce code that is either unchanged or incorrect, it would seem that execution of this program should not be part of the pom.xml.
The exec-maven-plugin plugin is also used to create the dynamic library using XCODE. Having this
repeated for each build can be justified since software updates may be needed for fixes to the
development environment. The maven-resources-plugin is then used to copy the library to the correct location.
Both of these are listed as being executed in the prepare-package phase and they should be executed in the
order that they appear in the pom.xml file.
I would reccomend placing the Javadocs on the GitHub repository so that they be accessed by other builds. (See
http://bradleyross.io/tutorials) The websites are stored as
the gh-pages branch of a project. (Create the branch using git branch --orphan gh-pages. This
disconnects it from the code branches. You can then delete the files that are currently there and insert the files for
the website.)