Added ARM support
Allow additional options for nar-testCompile phase

Provide a second method to extend the default CompilerDef and LinkerDef
argument lists with a new 'testOptions' collection. Currently these
options are additive only, and are appended to the standard
configuration.

Test-specific compilation options are useful e.g. for instrumentation of
test code for coverage purposes (such as `-fprofile-arcs -ftest-coverage`
for gcov), or for enabling debug macros in test executions.
Add unit test for testOptions compilation flags

Add a very simple C unit test class which verifies the testOptions
compiler arguments.

Note that in its current implementation the testOptions do not apply to
the main source code.
Verify that <testOptions> are inactive for src/main/c/

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

This branch provides a second method to extend the default CompilerDef
and LinkerDef argument lists with a new 'testOptions' collection.

It is a slightly enhanced version of
https://github.com/maven-nar/nar-maven-plugin/pull/92.

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

This branch adds initial ARM support.

Note that this is basically a copy-edit of the '# Linux' section, i.e.
Linux i386.

This merge accepts the pull request
https://github.com/maven-nar/nar-maven-plugin/pull/89.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
mailmap: correct some names
Patch for skipping test-related goals when 'maven.test.skip=true'

I noticed that the NAR-plugin didn't respect the flag 'maven.test.skip', so
I added this in my snapshot. Here's a diff of that.

[JES: adjusted whitespace]

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Avoid addition of compiler's default options to the command line when the clearDefaultOptions tag is set to true
Merge pull request #96 from dacanal/master

Avoid addition of compiler's default options to the command line when the clearDefaultOptions tag is set to true.
Resolve SNAPSHOT artifacts with multiple platform nar

Use getBaseVersion() instead of getVersion() when constructing file
paths for lib and include directories for nar dependencies in the
AbstractDependencyMojo.java. This change is same as #79 which probably
missing the AbstractDependencyMojo.java.

Without this change build will be failed if there have multiple nar in
the repositories.  For example:

hw-1.0-20140117.030545-15-x86-Windows-gpp-shared.nar
hw-1.0-20140117.093209-16-amd64-Linux-gpp-shared.nar

The Linux nar is built after the Windows nar. When building the windows
nar, maven will resolve the dependency base on the later timestamp which
will result in resolve failure. Using getBaseVersion will fix this
problem.

This fixes issue #80.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Fix NarTestCompileMojo resolve dependencies SNAPSHOT artifacts

In NarTestCompileMojo after resolving dependencies in
downloadAttachedNars, the SNAPSHOT dependencies will unpack using full
version names instead of SNAPSHOT version name (e.g.
hw-1.0-20140117.030545-15-x86-Windows-gpp-shared.nar). This causes the
testCompile to fail if has SNAPSHOT dependencies.

The change is a workaround to explicitly unpack the NarArtifacts. This
will unpack SNAPSHOT artifacts with expected version names.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Add a test to verify that SNAPSHOT dependencies are resolved correctly

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

In this topic, the problem is addressed when the NAR plugin would unpack
SNAPSHOT dependencies with an explicit timestamp in their file names,
breaking the linkage.

This closes the pull request #94.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Support parameter "gnuConfigureInPlace".

Some source tree uses symbolic link.
But previous versions of Java doesn't API to create symlinks.
So it may causes strange behavior on the build stage. (refs #82)

GNU configure can build binaries on the different place from its source directory.
[like: "mkdir bin; cd bin; ../src/configure" ]
So in some cases, we don't need to copy.
But some source tree may have no configure but configure.ac.
In such cases, we should copy sources into target/gnu/** .

This patch provides parameter named "gnuConfigureInPlace".
It has boolean value.
True means "not copy sources, not run autogen/buildconf."
The default is false. So it keeps the backward compatiblity.

gnuConfigureInPlace has a good side-effect.
You can reduce your disk usage.
It may be remarkable if you build huge system like GCC.
Merge branch 'monami/pr-support-gnuConfigurePrepareSkip'

This addresses the problem that copying all files just to run
./configure and build the project may pose an undue cost.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Improve NarAssemblyMojo performance by skip copying older files
By calling org.codehaus.plexus.util.FileUtils.copyDirectoryStructureIfModified
to skip copying files with old timestamps.
Merge pull request #102 from raycray/narassembly

Improve NarAssemblyMojo performance by skip copying older files
Fix NarTestCompileMojo to exclude executable dependency

NarTestCompileMojo will be failed if dependent project is an executable. The fix
is simply by-passing the dependent executable projects. NarCompileMojo has the
same logic to filter executable projects.
Merge pull request #103 from raycray/testfix

Fix NarTestCompileMojo to exclude executable dependency