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).
Add Generics

Add generics to a couple of classes. Reduces raw type warnings
by a couple hundred but still a long way to go.
Merge pull request #127 from marschall/generics

Add Generics
Force m2e to execute most goals (non-incrementally)

Eclipse's Maven integration requires certain extra steps of each Maven
plugin, to state how compatible the plugin is with Eclipse's version of
a lifecycle. With this change, we tell Eclipse to execute most NAR
goals, but only when building from scratch (because the steps are pretty
expensive).

Some of the goals are also triggered upon configuration, e.g. the
generation of a NarSystem class or downloading/unpacking dependencies.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
eclipse style fixed.
Let Eclipse know about generated NarSystem classes

According to http://wiki.eclipse.org/M2E_compatible_maven_plugins we
should use the BuildContext to inform Eclipse about updated and created
source files.

Happily, the BuildContext allows us to do that without having to link to
Eclipse proper, let alone having to write and deploy a full-blown Eclipse
plugin.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Merge pull request #130 from maven-nar/eclipse

Improve Eclipse support
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.
Hotfix: do not expect BuildContext to be available

Outside of Eclipse, the BuildContext is not necessarily available. So
let's be prepared for the case that the buildContext variable is
actually null.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Use correct file name for history.xml files

Correct a tendency of the plugin to leave temporary XML files lying around
that ended up in the nar archive. The change here rearranges the code to
delete the temporary XML rather than leave it around.

This fixes issue #106.

Johannes Schindelin was the original author of the change. IT's pass, no
wierd files.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Spell out XML as a String, not as hex numbers

This clarifies how we initialize the history.xml file.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Merge pull request #114 from benson-basis/history-xml-fun

Issue #106: apply @dscho's suggested change.

Basically, it fixes the problem that the history.xml file was added
with a long semi-random number suffix and therefore could not be
used effectively, neither would it accumulate the build history.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
fix #126 arch vs architecture in docs/code

Documentation refered to mojo parameter arch, but in implementation it was named architecture.

For backward compatibility of working code using this parameter documentation was fixed to refere
to parameter named architecture instead of arch.
Merge pull request #132 from NiematojakTomasz/archvsarchitecture

fix #126 arch vs architecture in docs/code