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
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>
Better "Windows" OS compatibility in native-lib-loader context.

In Windows case, operating systems are started-with "Windows *". Instead of using ao.equals(), ao.startsWith() is suitable for deciding OS types in such a case.
Add native-lib-loader case in [narSystemPackage] in configuration.apt

Loading multiple native libraries are supported with help of native-lib-loader.
The short description is added in [narSystemPackage] section.
FAQ: Add a native-lib-loader case for multiple platform support

Provide an example how to use native-lib-loader for multiple platforms.
One is about nar packaging and the other is for copying the libraries under "classes/lib/<aol>" use-case.