Update the plugin to a Maven 3.0.4 platform.

* Parent pom updated to current version from upstream.
* Maven core components pulled from that version.
* Obsolete Maven artifacts removed: maven-project, maven-toolchain.
* maven-compat added to avoid rewriting code that uses the ArtifactResolver.
* Other dependencies brought to current.
* enforcer configured to disable unwanted check from parent.
* junit up to 4.11 to get access to rules.
Move all plugin configuration to @nnotations.

* fix pom configuration of maven-plugin-plugin to work for annotations.
* edit all the mojos and parameters.

Since the default value of defaultValue is "", I suppressed defaultValue = "".

Since the default value of a boolean is `false`, I suppressed defaultValue = "false".

In a few places I found that the doc, the @parameter defaultValue, and the
initial setting of the property disagreed. I made them agree. All the ITs pass, but
it might disturb someone's project which is accidentally depending on the
incorect setting in the @parameter (treating the doc as the definition of
correct).
Adding support for xlC compiler

xlC is a C/C++ compiler from IBM for AIX (an operating system from IBM). Here's a link for more info: http://www-03.ibm.com/software/products/en/xlcaix/
In aol.properties file, the xlC properties have been added.

These additions were necessary because aol.properties did not define xlC for AIX (or any other OS), it only defined g++ for AIX, although the necessary classes for xlC were defined (for example, it is found in CompilerEnum).
In Linker.java, in getVersion() method, the case of xlC was not handled.
Therefore a warning was generated saying "cannot find version number for
linker". This case is added and the warning is no longer generated.

In VisualAgeLinker.java, in the addImpliedArgs() method, the first
argument 'CCTask task' was missing. So this was not overriding the
addImpliedArgs() method of the AbstractLdLinker. This means that the
generated linking command was "xlc -shared", instead of "xlc
-qmkshrobj". Adding the argument fixed this issue.
Merge branch 'maven-3.0.4'

This branch updates the NAR plugin to the Maven 3.0.4 platform.

Conflicts:
	src/main/java/com/github/maven_nar/Compiler.java
	src/main/java/com/github/maven_nar/NarSystemMojo.java
POM: remove unneeded managed version override
Fix whitespace

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Add a few missing @Override annotations

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Merge remote-tracking branch 'origin/xlc'

This tackles PR #131, adding support for the xlC compiler.
NarSystemMojo: avoid using Iterator in favor of foreach loop

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Fix indentation of generated NarSystem class

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Teach NarProperties to extract a list of all known AOLs

In the upcoming support for using native-lib-loader to unpack and load
our native libraries, we will need to stay platform-independent. Hence
we will need to know what native libraries are bundled for the current
architecture/OS. Unfortunately, this is not enough information because
NAR uses a full AOL identifier (in particular, the linker name) to
identify the location of the native library in the .nar file. To remedy
this, we will simply look in the paths corresponding to all AOLs
matching the current "AO".

Side note: using properties.keySet() does *not* work in NarProperties
because the properties are usually empty. The properties inherit their
defaults from an opaque Properties object passed to the constructor, hence
the keys we are after are only available via the propertyNames() method.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
NarSystemMojo: use native-lib-loader when it is a dependency

When the native-lib-loader (https://github.com/scijava/native-lib-loader,
a library for unpacking and loading native libraries conveniently) is
among the dependencies, we should make use of it.

The current version of native-lib-loader (2.0.2) unfortunately expects
the native library to be bundled in a non-standard place, hence we have
to copy the library there.

To support the file layout produced by the NAR plugin, this uses
DefaultJniExtractor#extractJni directly instead of handing off to
NativeLibraryUtil (which would expect the bundled native libraries
in a different path).

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Add an integration test for the native-lib-loader support

The native-lib-loader library is an incredibly useful thing to have when
working with native libraries: it unpacks bundled native libraries and
loads them. To make sure that our support for that library is not broken,
here is an integration test, to be run by our faithful Joyce Jenkins.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
it0026: verify that native-lib-loader works also with .jar files

So far, we only tested whether the NarSystem generated in the presence
of the native-lib-loader dependency worked with *unpacked* classes.
However, the whole point of the exercise was to support bundled classes
and bundled native libraries.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Rename it0026 to reflect the name of native-lib-loader precisely

The dependency we are special-casing is called native-lib-loader, not
native-library-loader. Let's avoid confusion and use the correct name
consistently.

This issue was noticed when this developer was puzzled why

	mvn -Dinvoker.test=it0026-native-lib-loader

would not Do The Right Thing ;-)

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>