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>
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>