Fix dependency linkages on Windows

When determining whether to include the version in file names, we used to
special-case Windows (excluding the version always). But this broke
linking, so let's stop treating Windows specially.

[JES: reworded the commit message]

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Remove duplicate property/method from AbstractCompileMojo

Its superclass, AbstractNarMojo, has narInfo/getNarInfo already.

[JES: reworded the commit message]

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

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Read the nar.properties from the ${buildDirectory}

The properties might be modified by nar-maven-plugin's goals, therefore we
need to read the properties from the output directory rather than from the
sources (but we fall back to reading the sources if the properties have
not bee written yet).

[JES: un-hardcoded "classes/", reworded commit message]

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Ask NarInfo for the libraries' file names even when compiling tests

The output name of libraries can be overridden via the <output> section in
the configuration of the nar-maven-plugin; Hence we need to ask NarInfo
for the file name.

This imitates the way we are linking in NarCompileMojo#createLibrary.

[JES: reworded the commit message]

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Write out narInfo in generate-test-sources

We need NarInfo to know, say, the output name when compiling tests...

[JES: reworded the commit message]

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Add an integration test for the <output> section

The nar-maven-plugin allows to override the name of the generated library
via the optional <output> section in the configuration. Verify that it
actually works.

[JES: reworded the commit message, fixed DOS line endings, renumbered the
test, prepared for the dependencee by making it0024 an aggregator project
and putting the nar project into the lib/ module]

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
prepare-package: use the correct output directory

Earlier, we wrote into target/META-INF/... but that is obviously
incorrect: we need to use the ${buildDirectory}, i.e.
target/classes/META-INF/...

[JES: reworded the commit message]

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Add an integration test for dependencies with overridden output name

The nar-maven-plugin needs to use the correct library name when linking,
even if the dependency has an overridden output name via the <output>
section in the configuration.

[JES: reworded the commit message, fixed DOS line endings, moved the test
into the dep/ module of the it0024 aggregator project]

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Fix integration tests of shared libraries

Even shared libraries' (in addition to JNI libraries) need to be added
to the java.library.path so that the integration tests find them...

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Verify that NarSystem can handle overridden output names

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Merge branch 'reducePath-dscho'

This fixes problems with overridden output names and adds tests. The
bulk of the work was performed by Greg Domjan, the issue was reported
by Alexandra de Paula and described by Greg Domjan as issue no 61:
https://github.com/maven-nar/nar-maven-plugin/issues/61

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