maven-nar / nar-maven-plugin Goto Github PK

The web page contains the following dead link under "Developer" -> "Forum":

http://forum.freehep.org/index.php?t=threadt&frm_id=14&rid=4

Maybe github offers mailing lists or a forum, too?

Similar to issues with #71 the experimental maven parallel weave build requires knowledge of compile time artifacts to continue parallel dependencies.

mvn -T4W test
should complete the compilation similarly to
mvn -T4 compile

http://docs.codehaus.org/display/MAVENUSER/Weave+mode+characteristics

Hello,
as I wrote in the mailing list I want to contribute to this plugin.
Is there any possibility to move the plugin to Jdk 5 or Jdk 6?
Is there any compelling reason to hold the plugin on Jdk 1.4 which is very old (the support ended 4 years ego)?

Hi.

Please try to prepare a merge of your fork into the new official maven-nar-plugin. POM changes or changes already done to other forks may need a review.

We are discussing the maven-nar-plugin at https://groups.google.com/forum/?fromgroups#!forum/maven-nar
Please join :)

Thanks.

Found today that I couldn't attach a sources jar to a project using NAR. After searching for the message I came across NAR-193, reported by Tony Lin:

NOT adding sources to artifacts with classifier as Maven only supports one classifier per artifact. Current artifact [xxxxx] has a [] classifier.

Problem reproduce:

1. run mvn org.apache.maven.plugins:maven-source-plugin:2.1.2:jar-no-fork on
   any NAR project
2. sources are not packaged with the warning "NOT adding sources to artifacts with classifier as Maven only supports one classifier per artifact. Current artifact [xxxxx] has a [] classifier."

After google, it seems the root cause is related to the classifier specified in "/src/main/resources/META-INF/plexus/components.xml". The classifier must be null but not empty. The solution can be removing the classifier tag in components.xml.

There is a very similar bug found in other plugin and can be referred as the example: https://bugs.eclipse.org/bugs/show_bug.cgi?id=351908

Please merge your fork into the maven-nar-plugin

The C folder split from the CPP folder, however compilers appear to only be configured in CPP mode.

Believe the aol properties is not currently configured to make this difference, both are treated as CPP.
http://msdn.microsoft.com/en-us/library/032xwy55.aspx
http://stackoverflow.com/questions/172587/what-is-the-difference-between-g-and-gcc

In particular should we add a whole linker definition for gpp when it represents the c++ compiler name or should it be a part of the GCC linker.

Add some properties about what NAR has compiled/unpacked.

Mostly those related to testing the current NAR outputs come to mind, there may of course be others.

nar.library.path>target/nar/aol/shared/lib;dependency/aol/shared/lib
nar.library.path.AOL>
nar.classpath>target/classes;target/artifact.jar

To run surefire as unit tests for example

<plugin> 
  <groupId>org.apache.maven.plugins</groupId> 
  <artifactId>maven-surefire-plugin</artifactId> 
  <configuration> 
    <forkMode>once</forkMode>
    ...
    <environmentVariables> 
      <PATH>${basedir}\..;${nar.library.path}</PATH> 
    </environmentVariables> 
.. or
    <argLine>-Djava.library.path=${nar.library.path}</argLine>
    ...
  </configuration> 
</plugin> 

Windows resource only modules contain no functions/code. /NOENTRY
Could be resource generated/linked with any MS toolset.
Should have option to not include manifest - not needed when no code present. /MANIFEST:NO
Could be Layed Out to noarch
As a dependency it could be used by any arch

May be desirable to have a per locale matrix build to build from source (though I'm told by my localizers that they prefer one binary in english and not to touch source)

• associated filtering or additional paths
  ie.
  ${project.basedir}/src/main/res main resource content
  English US links with option /l 0x0409 and include path

${project.basedir}/src/main/res-locale/en-US

For example, I cannot specify the clang compiler in a custom aol.properties.

[INFO] -------------------------------------------------
[INFO] Build Summary:
[INFO] Passed: 19, Failed: 3, Errors: 0, Skipped: 0
[INFO] -------------------------------------------------
[ERROR] The following builds failed:
[ERROR] * it0017-toolchain/pom.xml
[ERROR] * it0018-fortran/pom.xml
[ERROR] * it0002-executable-static/pom.xml
[INFO] -------------------------------------------------

it0017-toolchain/pom.xml

[INFO] --- nar-maven-plugin:3.0.0-SNAPSHOT:nar-validate (default-nar-validate) @ it0017-toolchain ---
[INFO] Using AOL: amd64-Linux-gpp
[INFO] 
[INFO] --- maven-toolchains-plugin:1.0:toolchain (default) @ it0017-toolchain ---
Downloading: file:///home/jenkins/.m2/repository/org/apache/maven/doxia/doxia-sink-api/1.0-alpha-10/doxia-sink-api-1.0-alpha-10.pom
Downloaded: file:///home/jenkins/.m2/repository/org/apache/maven/doxia/doxia-sink-api/1.0-alpha-10/doxia-sink-api-1.0-alpha-10.pom (2 KB at 438.5 KB/sec)
Downloading: file:///home/jenkins/.m2/repository/org/apache/maven/doxia/doxia/1.0-alpha-10/doxia-1.0-alpha-10.pom
Downloaded: file:///home/jenkins/.m2/repository/org/apache/maven/doxia/doxia/1.0-alpha-10/doxia-1.0-alpha-10.pom (9 KB at 1490.9 KB/sec)
Downloading: file:///home/jenkins/.m2/repository/org/apache/maven/maven-parent/6/maven-parent-6.pom
Downloaded: file:///home/jenkins/.m2/repository/org/apache/maven/maven-parent/6/maven-parent-6.pom (20 KB at 206.1 KB/sec)
Downloading: file:///home/jenkins/.m2/repository/org/apache/maven/doxia/doxia-sink-api/1.0-alpha-10/doxia-sink-api-1.0-alpha-10.jar
Downloaded: file:///home/jenkins/.m2/repository/org/apache/maven/doxia/doxia-sink-api/1.0-alpha-10/doxia-sink-api-1.0-alpha-10.jar (10 KB at 2418.7 KB/sec)
[INFO] Type:jdk
[ERROR] Cannot find matching toolchain definitions for the following toolchain types:
jdk [ version='[1.4,)' ]
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 11.981s
[INFO] Finished at: Sat Nov 09 13:44:19 UTC 2013
[INFO] Final Memory: 9M/25M
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-toolchains-plugin:1.0:toolchain (default) on project it0017-toolchain: Cannot find matching toolchain definitions for the following toolchain types:
[ERROR] jdk [ version='[1.4,)' ]
[ERROR] Please make sure you define the required toolchains in your ~/.m2/toolchains.xml file.
[ERROR] -> [Help 1]

it0018-fortran/pom.xml

[INFO] --- nar-maven-plugin:3.0.0-SNAPSHOT:nar-compile (default-nar-compile) @ it0018-fortran ---
[INFO] Preparing Nar dependencies
[INFO] Unpacking 0 dependencies to /scratch/jenkins/workspace/maven-nar/nar-maven-plugin/target/it/it0018-fortran/target/nar
[INFO] Compiling 4 native files
[INFO] 4 total files to be compiled.
[INFO] 4 total files to be compiled.
[INFO] Found 1 processors available
[INFO] Found 1 processors available
[INFO] Limited processors to 1 due to ordering of source files
[INFO] Limited processors to 1 due to ordering of source files
[INFO] 
Starting Core 0 with 4 source files...
[INFO] 
Starting Core 0 with 4 source files...
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 20.258s
[INFO] Finished at: Sat Nov 09 13:47:12 UTC 2013
[INFO] Final Memory: 8M/25M
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal com.github.maven-nar:nar-maven-plugin:3.0.0-SNAPSHOT:nar-compile (default-nar-compile) on project it0018-fortran: NAR: Compile failed: Could not launch gfortran: java.io.IOException: Cannot run program "gfortran" (in directory "/scratch/jenkins/workspace/maven-nar/nar-maven-plugin/target/it/it0018-fortran/target/nar/obj/amd64-Linux-gpp"): error=2, No such file or directory -> [Help 1]
[ERROR] 

it0002-executable-static/pom.xml

[INFO] --- nar-maven-plugin:3.0.0-SNAPSHOT:nar-compile (default-nar-compile) @ it0002-executable-static ---
[INFO] Preparing Nar dependencies
[INFO] Unpacking 0 dependencies to /scratch/jenkins/workspace/maven-nar/nar-maven-plugin/target/it/it0002-executable-static/target/nar
[INFO] Compiling 1 native files
[INFO] 1 total files to be compiled.
[INFO] 1 total files to be compiled.
[INFO] Found 1 processors available
[INFO] Found 1 processors available
[INFO] 
Starting Core 0 with 1 source files...
[INFO] 
Starting Core 0 with 1 source files...
[INFO] Linking...
[INFO] Linking...
[INFO] Starting link {4.7.2 -static -static-libgcc}
[INFO] Starting link {4.7.2 -static -static-libgcc}
[ERROR] /usr/bin/ld: cannot find -lstdc++
[ERROR] /usr/bin/ld: cannot find -lm
[ERROR] /usr/bin/ld: cannot find -lc
[ERROR] collect2: error: ld returned 1 exit status
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 17.110s
[INFO] Finished at: Sat Nov 09 13:47:35 UTC 2013
[INFO] Final Memory: 8M/25M
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal com.github.maven-nar:nar-maven-plugin:3.0.0-SNAPSHOT:nar-compile (default-nar-compile) on project it0002-executable-static: NAR: Compile failed: g++ failed with return code 1 -> [Help 1]
[ERROR] 

It was mentioned on the Maven users list that we should strongly consider renaming maven-nar-plugin to nar-maven-plugin, because the maven-*-plugin naming scheme is reserved for official Apache Maven plugins. (E.g., the Codehaus plugins all use *-maven-plugin instead.)

The original plan (years ago) was for maven-nar-plugin to become part of the official Apache Maven suite, but that is on hold for the time being at least, so the current name should be nar-maven-plugin.

Maven always display c++ compiler warning message as "ERROR" log level. It may not be a real issue but would like to see any thoughts/workaround on this.

Attempt to compile header from Java fails.

Operating system: MacOSX 10.9.1
JDK: jdk1.7.0_45.jdk

Plug-in configuration

<plugin>
    <groupId>com.github.maven-nar</groupId>
    <artifactId>nar-maven-plugin</artifactId>
    <version>3.0.0</version>

    <extensions>true</extensions>
    <configuration>
        <linker>
            <name>g++</name>
        </linker>
        <gnuSourceDirectory>src/main/c</gnuSourceDirectory>
        <libraries>
            <library>
                <type>shared</type>
            </library>
        </libraries>
        <gnuMakeInstallSkip>true</gnuMakeInstallSkip>
        <output>computeEOFB</output>
    </configuration>
</plugin>

Error message

[INFO] --- nar-maven-plugin:3.0.0:nar-gnu-make (default-nar-gnu-make) @ bli-server-libcomputeeofb ---
[INFO] Running GNU make
[INFO] + cd /work/sources/epo/epoque/bli-server/bli-server-libcomputeeofb/target/nar/gnu/x86_64-MacOSX-gpp/src
[INFO] + make
[INFO] touch ComputeEOFB.u
[INFO] (cat ComputeEOFB.u;\
[INFO]  echo "include Makefile") > Makefile.tmp
[INFO] make -f Makefile.tmp all_1
[INFO] mkdir -p .
[INFO] gcc -c -pthread -fPIC -I. -I/Library/Java/JavaVirtualMachines/jdk1.7.0_45.jdk/Contents/Home/include -I/Library/Java/JavaVirtualMachines/jdk1.7.0_45.jdk/Contents/Home/include/linux  -o ComputeEOFB.o ComputeEOFB.c
[ERROR] In file included from ComputeEOFB.c:11:
[ERROR] In file included from ./ComputeEOFB.h:2:
[ERROR] /Library/Java/JavaVirtualMachines/jdk1.7.0_45.jdk/Contents/Home/include/jni.h:45:10: fatal error: 'jni_md.h' file not found
[ERROR] #include "jni_md.h"
[ERROR]          ^
[ERROR] 1 error generated.
[ERROR] make[1]: *** [ComputeEOFB.o] Error 1
[ERROR] make: *** [all] Error 2
[WARNING] com.github.maven_nar.NarUtil$2@6dfa351e
[WARNING] com.github.maven_nar.NarUtil$1@45b57cfa
[WARNING] com.github.maven_nar.NarUtil$3@e2024d7

Java to compile

package org.epo.bli.scenario.util.tiffeofb;

public class ComputeEOFB {

    static {
        System.loadLibrary("computeEOFB");
    }

    public ComputeEOFB() {
        super();
    }

    public native byte[] putEOFB(byte[] theInData, int theInLgth);

}

Please approve to the following plans:

• Joining eclipse foundation with additional projects (f.e. build integration etc.)
• Leaving the "core" project at github
• Applying epl to the maven-nar-plugin (dual-licensing model)

So that we can drive forward :)
See https://groups.google.com/forum/?fromgroups#!topic/maven-nar/EgjlVyvFOUM

Using the JNI example:

[ERROR] Failed to execute goal com.github.maven-nar:nar-maven-plugin:3.1.0:nar-validate (default-nar-validate) on project tcl-regex-jni: Unable to parse configuration of mojo com.github.maven-nar:nar-maven-plugin:3.1.0:nar-validate for parameter library: Cannot find setter, adder nor field in com.github.maven_nar.Library for 'packageName' -> [Help 1]

hello , i had C++ source for windows specific codes.
But when i migrate all project to my OSX machine , tried to compile C++.
it compiles Windows sources also , i want to separate C++ source for all OS's

my source path:
/src/main/c++
but all os's compiling there.

How can we compile for OSX different path and Linux,Windows,BSD different?

When using NarUtil.runCommand to make system calls, many things can go wrong. Fortunately, OSes have a built-in age-old mechanism for this: the return code (a.k.a. error code). On zero, it means the command completed successfully. Other numbers indicate an error of some kind.

In general, we should respect these error codes and fail the build if non-zero is returned. The only exception is that some commands (MSVC, I'm looking at you!) sometimes return non-zero even when things worked. We should have explicit case logic handling those known situations, and continue the build in those cases. But in general it would be safest to fail the build with an error indicating the exact command that returned non-zero.

However, this change will break backwards compatibility for some builds. So to alleviate that, let's also add a property to make the failure configurable. Something like failOnNonZero with a default of true, but which can be switched back to false to regain the old behavior.

Some versions of MSVS have a link.exe that does not support the /version flag as expected. This flag is used in org.apache.maven.plugin.nar.Linker to detect the version of the software.

We need to experiment with non-working versions of link.exe to find a better way to ask it for its version. Maybe link /v? Or link /? gives a hint? For at least some versions of link.exe, the /version flag does something different than report the version number of the software!

I believe this is the same issue as #79. I found the same issue in AbstractDependencyMojo.getAttachedNarArtifacts:248.

I am more than happy to contribute, could anyone tell me the process to contribute? Sorry that i am new to opensource.

When creating a processLibraryCommand, it will fail with a NPE due to not being able to set the type.
Also, if you create a command with no arguments it will throw a NPE as well.

Please prepare a merge of your changes into the official repository.

I'm trying to replace a Makefile that calls javah using the maven-nar-plugin like this:

javah -classpath $(JAVAH_CLASSPATH) -d $(@dst) $(JNI_CLASSES) java.sql.Types

It seems that I cannot add a system class like java.sql.Types to the list of classes as only files below ... are used.

(as I'm not sure if this really is a missing feature, I would have asked this in the forum but the link is dead..)

• Setup a jenkins to compile the snapshots and do releases.
• Support for binary compilations and cross compilations (for test cases)

Greetings!

I couldn't figure out why a simple dependency gives unresolved symbols when linking on windows XP with Visual C++ 2010 Express Edition.

I had to turn debugging on in order to see that link command did not have the dependency artifact appended.

I changed the line 206 at file AbstractCompileMojo.java

return getNarInfo().getOutput( aol, getOutput( ! aol.getOS().equals( OS.WINDOWS ) && !  Library.EXECUTABLE.equals( type ) ) );

to

return getNarInfo().getOutput( aol, getOutput( true ) );

and now it works.

is it safe to modify it in that way?

Regards,

Edu.

When building third-party libraries, their sources and headers are often in the same directory. To work with this limitation, filtering is required to list only the header files to be included in the noarch deployment.

http://maven-nar.github.com/maven-nar-plugin/source-repository.html

says that the git repository is:

http://github.com/duns/maven-nar-plugin

although it seems to http://github.com/maven-nar/maven-nar-plugin now.

It would be nice to be able to specify environment variables (i.e. "${ANDROID_HOME}/bin/gcc") in the aol.properties files. Not sure if it's possible - but I'm planning on looking into it.

Should NAR (further) support a 'matrix' style build through a single <configuration>
NAR support already supports a matrix of libraries - static/shared/exe as many different settings as you like.
other attributes like architectures & linkers could be made into multiple entries
ie.

<architectures>
    <architecture>x86</architecture>
    <architecture>amd64</architecture>
</architectures>

There could be issues with a sparse matrix?

Or perhaps it should go the other way - no default compilation in the lifecycle, and each part of a matrix is defined as a seperate execution.

One of the things I found annoying especially with large 'include' areas was that the noarch copy of includes happened for each library.

I am using the com.github.maven-nar:nar-maven-plugin version 3.0.0-SNAPSHOT as of 19/11/2013.

I have two projects. Project A produces a shared library (.dll) which project B (also a .dll) depends on.

I have overridden the output name of project A's dll such that instead of the default ${project.artifactId}-${project.version}, we use ${project.artifactId}.

Project A builds correctly. Project B (which depends on A) fails when linking. Debugging shows that the linker is not passed a reference to the Project A library.

The issue seems to be that project A's shared library is not correctly resolved and hence not passed to the linker as a dependent library.

Not overriding the output name solves the issues but for our particular solution this is undesirable.

Dependencies have not been updated in some time.

For instance NAR is using quite an old version (2.0.5) of the plexus-utils, there have been some changes in more recent (3.0.16) to rely less on the actual command line to address security concerns with possible injection, which also made some changes to handling of quotes.

Noting this in particular after discussion on google groups

work around  for this issue: to break the compiler option into two option tags, like this:

<option>/AI"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.0"</option>

<option>/AI</option>
<option>C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.0</option>

Now, no quote is needed. The ant dependecy takes care of adding double quotes to the 'second' argument/option.

When execution of a command line program files, the return code is not checked, so the resulting error message is often very cryptic. One common such error is "Cannot deduce version number from:".

For example, OS X does not install the command line developer tools by default (e.g., gcc). If you attempt to build nar-maven-plugin in that case, one of the tests fails:

$ cat target/surefire-reports/org.apache.maven.plugin.nar.test.TestLinkerVersion.txt
-------------------------------------------------------------------------------
Test set: org.apache.maven.plugin.nar.test.TestLinkerVersion
-------------------------------------------------------------------------------
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.074 sec <<< FAILURE!
testVersion(org.apache.maven.plugin.nar.test.TestLinkerVersion)  Time elapsed: 0.048 sec  <<< ERROR!
org.apache.maven.plugin.MojoFailureException: Cannot deduce version number from: 
    at org.apache.maven.plugin.nar.Linker.getVersion(Linker.java:249)
    at org.apache.maven.plugin.nar.test.TestLinkerVersion.testVersion(TestLinkerVersion.java:56)
...

The issue is that NarUtil.runCommand( "gcc", new String[] { "--version" }, ... ); ends up matching a blank version rather than throwing an exception about gcc being unavailable.

In the example above, the workaround was easy: install the latest Xcode, go to Preferences > Downloads and install the command line tools. Once gcc is available, this problem does not happen. So consequently I was too lazy to improve the error message.

But this is a general issue, with many possible scenarios causing it across multiple platforms, so really the return code should be checked and the error message improved.

When using the C configuration, include files are not copied during nar-compile goal.

Debugging shows that the problem lies in the NarCompileMojo.

https://github.com/maven-nar/maven-nar-plugin/blob/master/src/main/java/org/apache/maven/plugin/nar/NarCompileMojo.java

try
        {
            // FIXME, should the include paths be defined at a higher level ?
            getCpp().copyIncludeFiles(
                                       getMavenProject(),
                                       getLayout().getIncludeDirectory( getTargetDirectory(),
                                                                        getMavenProject().getArtifactId(),
                                                                        getMavenProject().getVersion() ) );
        }

I've specifically set the includePaths in my configuration, but they're not being used because copying include files only uses the configuration.

Originally filed here

Alexandre de Paula raised in group https://groups.google.com/d/msg/maven-nar/XFp1X_mO_kQ/5ef6gOaMsbQJ

The linking static lib problem is back. Please, take a look at NarInfo class:

public final String getLibs( AOL aol ) {
// TODO: resolve output Vs libs.names
// nothing is available to set libs.names within the build.
// if there is an existing nar.properties that was hand crafter with libs.names then this would work - undocumented feature?
return getProperty( aol, "libs.names", getOutput( aol, artifactId + "-" + version ) );
}

The old piece of code that used to work was:

return getProperty( aol, "libs.names", artifactId + "-" + version );

I would appreciate very much if that issue could be solved before releasing version RC1.

With previous versions of the plugin my C code would just compile. Now I had to add the following to the section in my pom.xml to get the code to compile.

      <c>
        <includes>
          <include>**/*.c</include>
        </includes>
      </c>

There's a bug with the onlySpecifiedCompilers flag in AbstractCompileMojo for which I am submitting a pull request.

hello , i had big problem on 32 and 64 bit.
Its better to add both compile on same platform makes life easier.
I was using MSVC.

To use maven , i had to add these enviroment variables

INCLUDE
C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\INCLUDE;C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\include;C:\Program Files (x86)\Java\jdk1.8.0_05\include;C:\Program Files (x86)\Java\jdk1.8.0_05\include\win32;C:\Program Files (x86)\Java\jdk1.8.0_05\include\win32\bridge

LIB
C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\lib;C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\Lib;C:\Program Files (x86)\Java\jdk1.8.0_05\lib

PATH
%PATH%;C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\bin;C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE;C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\Bin;

But these options only compiling maven nar for 32 bit.
Why not 64 bit also ? is it possible to make 32 and 64 bit dll together?

Linker issues

target/it/it0007-lib-shared/build.log:

[INFO] Linking...
[ERROR] Undefined symbols for architecture x86_64:
[ERROR]   "_main", referenced from:
[ERROR]      implicit entry/start for main executable
[ERROR] ld: symbol(s) not found for architecture x86_64
[ERROR] clang: error: linker command failed with exit code 1 (use -v to see invocation)

target/it/it0010-lib-static/build.log:

[INFO] Linking...
[ERROR] Undefined symbols for architecture x86_64:
[ERROR]   "_main", referenced from:
[ERROR]      implicit entry/start for main executable
[ERROR] ld: symbol(s) not found for architecture x86_64
[ERROR] clang: error: linker command failed with exit code 1 (use -v to see invocation)

target/it/it0014-multi-module/build.log:

[INFO] Linking...
[ERROR] Undefined symbols for architecture x86_64:
[ERROR]   "_main", referenced from:
[ERROR]      implicit entry/start for main executable
[ERROR] ld: symbol(s) not found for architecture x86_64
[ERROR] clang: error: linker command failed with exit code 1 (use -v to see invocation)

target/it/it0016-layout/build.log:

[INFO] Linking...
[ERROR] Undefined symbols for architecture x86_64:
[ERROR]   "_main", referenced from:
[ERROR]      implicit entry/start for main executable
[ERROR] ld: symbol(s) not found for architecture x86_64
[ERROR] clang: error: linker command failed with exit code 1 (use -v to see invocation)

target/it/it0018-fortran/build.log:

[INFO] Linking...
[ERROR] ld: library not found for -lgfortran
[ERROR] clang: error: linker command failed with exit code 1 (use -v to see invocation)

target/it/it0023-local-aol-properties/build.log:

[INFO] Linking...
[ERROR] Undefined symbols for architecture x86_64:
[ERROR]   "_main", referenced from:
[ERROR]      implicit entry/start for main executable
[ERROR] ld: symbol(s) not found for architecture x86_64
[ERROR] clang: error: linker command failed with exit code 1 (use -v to see invocation)

Java configuration (looking for javah within the JRE)

target/it/it0003-jni/build.log:

[INFO] Running /Library/Java/JavaVirtualMachines/jdk1.7.0_21.jdk/Contents/Home/jre/bin/javah compiler on 2 classes...
[ERROR] /bin/sh: /Library/Java/JavaVirtualMachines/jdk1.7.0_21.jdk/Contents/Home/jre/bin/javah: No such file or directory

target/it/it0005-jni-static/build.log:

[INFO] Running /Library/Java/JavaVirtualMachines/jdk1.7.0_21.jdk/Contents/Home/jre/bin/javah compiler on 2 classes...
[ERROR] /bin/sh: /Library/Java/JavaVirtualMachines/jdk1.7.0_21.jdk/Contents/Home/jre/bin/javah: No such file or directory

target/it/it0006-jni-3rdparty/build.log:

[INFO] Running /Library/Java/JavaVirtualMachines/jdk1.7.0_21.jdk/Contents/Home/jre/bin/javah compiler on 1 classes...
[ERROR] /bin/sh: /Library/Java/JavaVirtualMachines/jdk1.7.0_21.jdk/Contents/Home/jre/bin/javah: No such file or directory

Missing snapshots?

target/it/it0004-java-dep-jni/build.log:

[WARNING] The POM for com.github.maven-nar.its.nar:it0003-jni:nar:1.0-SNAPSHOT is missing, no dependency information available
...
[ERROR] Failed to execute goal on project it0004-java-dep-jni: Could not resolve dependencies for project com.github.maven-nar.its.nar:it0004-java-dep-jni:nar:1.0-SNAPSHOT: Could not find artifact com.github.maven-nar.its.nar:it0003-jni:nar:1.0-SNAPSHOT in local.central (file:///Users/curtis/.m2/repository) -> [Help 1][ERROR] 

target/it/it0008-executable-dep-lib-shared/build.log:

[WARNING] The POM for com.github.maven-nar.its.nar:it0007-lib-shared:nar:1.0-SNAPSHOT is missing, no dependency information available
...
[ERROR] Failed to execute goal on project it0008-executable-dep-lib-shared: Could not resolve dependencies for project com.github.maven-nar.its.nar:it0008-executable-dep-lib-shared:nar:1.0-SNAPSHOT: Could not find artifact com.github.maven-nar.its.nar:it0007-lib-shared:nar:1.0-SNAPSHOT in local.central (file:///Users/curtis/.m2/repository) -> [Help 1]

target/it/it0009-jni-dep-lib-shared/build.log:

[WARNING] The POM for com.github.maven-nar.its.nar:it0007-lib-shared:nar:1.0-SNAPSHOT is missing, no dependency information available
...
[ERROR] Failed to execute goal on project it0009-jni-dep-lib-shared: Could not resolve dependencies for project com.github.maven-nar.its.nar:it0009-jni-dep-lib-shared:nar:1.0-SNAPSHOT: Failure to find com.github.maven-nar.its.nar:it0007-lib-shared:nar:1.0-SNAPSHOT in file:///Users/curtis/.m2/repository was cached in the local repository, resolution will not be reattempted until the update interval of local.central has elapsed or updates are forced -> [Help 1]

target/it/it0011-executable-dep-lib-static/build.log:

[WARNING] The POM for com.github.maven-nar.its.nar:it0010-lib-static:nar:1.0-SNAPSHOT is missing, no dependency information available
...
[ERROR] Failed to execute goal on project it0011-executable-dep-lib-static: Could not resolve dependencies for project com.github.maven-nar.its.nar:it0011-executable-dep-lib-static:nar:1.0-SNAPSHOT: Could not find artifact com.github.maven-nar.its.nar:it0010-lib-static:nar:1.0-SNAPSHOT in local.central (file:///Users/curtis/.m2/repository) -> [Help 1]

target/it/it0012-jni-dep-lib-static/build.log:

[WARNING] The POM for com.github.maven-nar.its.nar:it0010-lib-static:nar:1.0-SNAPSHOT is missing, no dependency information available
...
[ERROR] Failed to execute goal on project it0012-jni-dep-lib-static: Could not resolve dependencies for project com.github.maven-nar.its.nar:it0012-jni-dep-lib-static:nar:1.0-SNAPSHOT: Failure to find com.github.maven-nar.its.nar:it0010-lib-static:nar:1.0-SNAPSHOT in file:///Users/curtis/.m2/repository was cached in the local repository, resolution will not be reattempted until the update interval of local.central has elapsed or updates are forced -> [Help 1]

Other issues

target/it/it0013-gnu-executable/build.log:

[INFO] Running GNU autogen.sh
[INFO] args: [./autogen.sh]
[ERROR] ./autogen.sh: line 2: autoreconf: command not found

target/it/it0017-toolchain/build.log:

[INFO] Type:jdk
[ERROR] Cannot find matching toolchain definitions for the following toolchain types:
jdk [ version='[1.4,)' ]
[ERROR] Please make sure you define the required toolchains in your ~/.m2/toolchains.xml file.

Sometimes it causes strange behaviors when symlink is contained in the source tree.

I see it's difficult to support on ( JDK < 7) environments.
So I suggest to show warnings when simlinks is detected on the copy time.

While an empty might be broken configuration, it should generate a proper error message and not a NullPointerException.

Example:

  <plugins>
        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-nar-plugin</artifactId>
            <extensions>true</extensions>
            <configuration>
                  <javah>
         ...
                    <includes>
                        <include></include>
                    </includes>
        ...

[ERROR] Failed to execute goal org.apache.maven.plugins:maven-nar-plugin:2.1-SNAPSHOT:nar-javah (default-cli) on project pljava-so: Execution default-cli of goal org.apache.maven.plugins:maven-nar-plugin:2.1-SNAPSHOT:nar-javah failed. NullPointerException -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.apache.maven.plugins:maven-nar-plugin:2.1-SNAPSHOT:nar-javah (default-cli) on project pljava-so: Execution default-cli of goal org.apache.maven.plugins:maven-nar-plugin:2.1-SNAPSHOT:nar-javah failed.
        at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:225)
        at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
        at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
        at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
        at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
        at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
        at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
        at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
        at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
        at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
        at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
        at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:601)
        at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
        at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
        at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
        at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
Caused by: org.apache.maven.plugin.PluginExecutionException: Execution default-cli of goal org.apache.maven.plugins:maven-nar-plugin:2.1-SNAPSHOT:nar-javah failed.
        at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:110)
        at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
        ... 19 more
Caused by: java.lang.NullPointerException
        at org.codehaus.plexus.util.AbstractScanner.normalizePattern(AbstractScanner.java:327)
        at org.codehaus.plexus.util.AbstractScanner.setIncludes(AbstractScanner.java:286)
        at org.codehaus.plexus.compiler.util.scan.AbstractSourceInclusionScanner.scanForSources(AbstractSourceInclusionScanner.java:63)
        at org.codehaus.plexus.compiler.util.scan.StaleSourceScanner.getIncludedSources(StaleSourceScanner.java:84)
        at org.apache.maven.plugin.nar.Javah.execute(Javah.java:217)
        at org.apache.maven.plugin.nar.NarJavahMojo.narExecute(NarJavahMojo.java:64)
        at org.apache.maven.plugin.nar.AbstractNarMojo.execute(AbstractNarMojo.java:268)
        at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
        ... 20 more

In general I think the default warning flags specified in aol.properties should be a minimal set. You can specify additional warning flags by including an options section in your pom.xml but these warnings are just additional, they don't replace the entire set. So you can't remove a warning flag you don't want though this mechanism. (You can include your own version of aol.properties with edited warnings.)

One of the default warnings, the '-Wconversion' flag behaves differently based on what version of gcc is installed. The pre-4.3 version wasn't really useful ( "Wconversion was not recommended for general use", see below.) Unfortunately on OS X you still get version 4.2.1 if you install gcc through XCode. Of course you can install later versions too, via macports for example.

Discussed in:
http://gcc.gnu.org/wiki/NewWconversion

For post-4.3 gcc, -Wconversion also implies -Wsign-conversion, which I find particularly tedious. It has a special flag -Wno-sign-conversion to turn this off. I could specify this additional flag in my pom, but then the build will crash on another system with a pre-4.3 gcc that doesn't understand this flag.

On machines where the environment/path cannot be modified, plugin should allow for setting the environment through properties or some other class/factory.

Sorry for following ramble, wanted to get some thoughts down and start discussion.

It would be nice not to have to run multiple times to choose different versions of toolchain.

What is toolchain Vs what is dependency?

An MS VC compile has a default dependency on it's versions of C++ std lib, and if present on the Windows Platform SDK.
There are then 'cross compile' variations for arch where to find not just libs but also the tools to execute.
Some tool paths can be Language or SDK dependendant...
There are some default pairings of Compiler and platform SDK, and ability to change that choice.

I think I'd like to see NAR System dependencies able to support include/lib without having to package (not sure you could legally pacakge with MSVC headers/libs), Another problem being inconsistent cross architecture locations..

I've made local changes that are very specific to the Windows tool layout, can't just push it out for others.
Here is an aol config I have for Compiling against VC8/9/10/11 and WindowsSDK 7/7.1/8

#  VC8
Windows.msvc.8.toolspath=c:/Program Files/Microsoft Visual Studio 8

Windows.msvc.8.path=VC/VCPackages;Common7/IDE;Common7/Tools
Windows.msvc.8.include=VC/INCLUDE
Windows.msvc.8.include.ATLMFC=VC/ATLMFC/INCLUDE

#  V8 x86
x86.Windows.msvc.8.path=VC/bin
x86.Windows.msvc.8.lib=VC/LIB
x86.Windows.msvc.8.lib.ATLMFC=VC/ATLMFC/LIB

# V8 amd64
amd64.Windows.msvc.8.path=VC/bin/amd64
x86_amd64.Windows.msvc.8.path=VC/bin/x86_amd64
amd64.Windows.msvc.8.lib=VC/LIB/amd64
amd64.Windows.msvc.8.lib.ATLMFC=VC/ATLMFC/LIB/amd64

# V8 Intel
ia64.Windows.msvc.8.path=VC/bin/ia64
x86_ia64.Windows.msvc.8.path=VC/bin/x86_ia64
ia64.Windows.msvc.8.lib=VC/LIB/ia64
ia64.Windows.msvc.8.lib.ATLMFC=VC/ATLMFC/LIB/ia64

#  VC9
Windows.msvc.9.toolspath=c:/Program Files/Microsoft Visual Studio 9

Windows.msvc.9.path=VC/VCPackages;Common7/IDE;Common7/Tools
Windows.msvc.9.include=VC/INCLUDE
Windows.msvc.9.include.ATLMFC=VC/ATLMFC/INCLUDE

#  V9 x86
x86.Windows.msvc.9.path=VC/bin
x86.Windows.msvc.9.lib=VC/LIB
x86.Windows.msvc.9.lib.ATLMFC=VC/ATLMFC/LIB

# V9 amd64
amd64.Windows.msvc.9.path=VC/bin/amd64
x86_amd64.Windows.msvc.9.path=VC/bin/x86_amd64
amd64.Windows.msvc.9.lib=VC/LIB/amd64
amd64.Windows.msvc.9.lib.ATLMFC=VC/ATLMFC/LIB/amd64

# V9 Intel
ia64.Windows.msvc.9.path=VC/bin/ia64
x86_ia64.Windows.msvc.9.path=VC/bin/x86_ia64
ia64.Windows.msvc.9.lib=VC/LIB/ia64
ia64.Windows.msvc.9.lib.ATLMFC=VC/ATLMFC/LIB/ia64

#  V10
Windows.msvc.10.toolspath=c:/Program Files/Microsoft Visual Studio 10.0

Windows.msvc.10.path=VC/VCPackages;Common7/IDE;Common7/Tools
Windows.msvc.10.include=VC/INCLUDE
Windows.msvc.10.include.ATLMFC=VC/ATLMFC/INCLUDE

#  V10 x86
x86.Windows.msvc.10.path=VC/bin
x86.Windows.msvc.10.lib=VC/LIB
x86.Windows.msvc.10.lib.ATLMFC=VC/ATLMFC/LIB

# V10 amd64
amd64.Windows.msvc.10.path=VC/bin/amd64
x86_amd64.Windows.msvc.10.path=VC/bin/x86_amd64
amd64.Windows.msvc.10.lib=VC/LIB/amd64
amd64.Windows.msvc.10.lib.ATLMFC=VC/ATLMFC/LIB/amd64

# V10 Intel
ia64.Windows.msvc.10.path=VC/bin/ia64
x86_ia64.Windows.msvc.10.path=VC/bin/x86_ia64
ia64.Windows.msvc.10.lib=VC/LIB/ia64
ia64.Windows.msvc.10.lib.ATLMFC=VC/ATLMFC/LIB/ia64

#  V11
Windows.msvc.11.toolspath=c:/Program Files/Microsoft Visual Studio 11.0

Windows.msvc.11.path=VC/VCPackages;Common7/IDE;Common7/Tools
Windows.msvc.11.include=VC/INCLUDE
Windows.msvc.11.include.ATLMFC=VC/ATLMFC/INCLUDE

#  V11 x86
x86.Windows.msvc.11.path=VC/bin
x86.Windows.msvc.11.lib=VC/LIB
x86.Windows.msvc.11.lib.ATLMFC=VC/ATLMFC/LIB

# V11 amd64
amd64.Windows.msvc.11.path=VC/bin/amd64
x86_amd64.Windows.msvc.11.path=VC/bin/x86_amd64
amd64.Windows.msvc.11.lib=VC/LIB/amd64
amd64.Windows.msvc.11.lib.ATLMFC=VC/ATLMFC/LIB/amd64

# V11 Intel
ia64.Windows.msvc.11.path=VC/bin/ia64
x86_ia64.Windows.msvc.11.path=VC/bin/x86_ia64
ia64.Windows.msvc.11.lib=VC/LIB/ia64
ia64.Windows.msvc.11.lib.ATLMFC=VC/ATLMFC/LIB/ia64

# Windows SDK - likely to be customised on a per install - this should be wrapped up in a dependent artifact.
WindowsSdk.6a.toolspath=C:/Program Files/Microsoft SDKs/Windows/v6.0A
WindowsSdk.6.toolspath=C:/Program Files/Microsoft SDKs/Windows/v6.0
WindowsSdk.7a.toolspath=C:/Program Files/Microsoft SDKs/Windows/v7.0A
WindowsSdk.7.toolspath=C:/Program Files/Microsoft SDKs/Windows/v7.0
WindowsSdk.7.1.toolspath=C:/Program Files/Microsoft SDKs/Windows/v7.1
WindowsSdk.8.toolspath=C:/Program Files/Windows Kits/8.0

# Windows SDK 7a (comes with the Visual Studio Install)
WindowsSdk.7a.include=include

x86.WindowsSdk.7a.lib=lib
amd64.WindowsSdk.7a.lib=lib/x64
ia64.WindowsSdk.7a.lib=lib/ia64

x86.WindowsSdk.7a.path=bin
amd64.WindowsSdk.7a.path=bin/x64
ia64.WindowsSdk.7a.path=bin/x64

# Windows SDK 7 
WindowsSdk.7.include=include

x86.WindowsSdk.7.lib=lib
amd64.WindowsSdk.7.lib=lib/x64
ia64.WindowsSdk.7.lib=lib/ia64

# PATH=
x86.WindowsSdk.7.path=bin
amd64.WindowsSdk.7.path=bin/x64
ia64.WindowsSdk.7.path=bin/x64

#x86.WindowsSdk.7.path=bin;bin/NETFX 4.0 Tools
#amd64.WindowsSdk.7.path=bin/x64;bin/NETFX 4.0 Tools/x64
#ia64.WindowsSdk.7.path=bin/ia64;bin/NETFX 4.0 Tools/ia64

# Windows SDK 7.1 
WindowsSdk.7.1.include=include

x86.WindowsSdk.7.1.lib=lib
amd64.WindowsSdk.7.1.lib=lib/x64
ia64.WindowsSdk.7.1.lib=lib/ia64

# PATH=
x86.WindowsSdk.7.1.path=bin
amd64.WindowsSdk.7.1.path=bin/x64
ia64.WindowsSdk.7.1.path=bin/x64

# Windows SDK 8 
WindowsSdk.8.include=include/um;include/shared

x86.WindowsSdk.8.lib=Lib/win8/um/x86
amd64.WindowsSdk.8.lib=Lib/win8/um/x64
#ia64.WindowsSdk.8.lib=Lib/win8/um/ia64

# PATH=
x86.WindowsSdk.8.path=bin/x86
amd64.WindowsSdk.8.path=bin/x64
ia64.WindowsSdk.8.path=bin/x64

If I have a file and run nar-compile on my project, running nar-compile again (without making changes to either the source file or the created object file), the compilation process runs again.

It doesn't look like it's honoring the modification and creation timestamps.

As an example wxWidgets has some additional config in Windows
noarch
${nar.unpackDirectory}/wxBase-2.9.4-SNAPSHOT-noarch/include/wx

msvc specific
${nar.unpackDirectory}/wxBase-2.9.4-SNAPSHOT-??/include/msvc

wx #includes <msvc/wx/setup.h> and expects a -I to the msvc specific.

Maybe this is just a matter of repackaging?

I think there was a proposal on the sonatype issues for adding a version to the AOL. I think it was proposed as adding the OS version. But rather I think it should have been the c++ shared lib version.
ie. When you use shared lib <linkCPP> which defaults to true
msvc of msvcrt(80/90/100/110) or
g++ of glibc(1.5, 1.6).

Suggesting some thoughts on a resolution

• The linker name could be extended to include a version, or perhaps there could be included as a classifier.
  Gives generally the same result and this leaves it for NAR to manage and can vary for each AOL.
• It could be added as semantic version information, different OL would change co-ords. Don't like this as a solution as it makes a mess of cross OS.
• Could continue with the information not being visible from pom/narinfo, but include subfolders or naming conventions to include the version. (boost adds the vc runtime version the filenames on a default bjam build as an example).

This issue doesn't stop current binary distributions from supporting a latest compiler - in the case of boost they have a farm of test builds for different AOL even if they don't distribute them.

Whatever OS modules NAR might provide as examples/pre compilations to central would have that issue for almost all C++ shared run time.

One of our project modules fails on some developers machines during the linker phase using msvc. The linker error given is 1104.

Some investigation showed this was due to reaching the 260 character limit for the resulting lib output file path on windows. This limitation is however overcome using the "?" prefix to file paths as described in the following MSDN article http://msdn.microsoft.com/en-us/library/aa365247%28VS.85%29.aspx#maxpath

Perhaps paths passed to the msvc linker may be prefixed such that this problem will not occur.

I have multi-module project with various inter-dependencies between nar modules. Under normal circumstances, the maven "install" goal is set as the default goal for each nar project. This ensures that dependency headers are available during native code compilation to dependent modules. If a "mvn compile" were to run, the multi-module build would fail.

When performing a release, the above still holds true. However, the "work around" is a little different, requiring undocumented configuration (as far as I can tell). In order for a release to work, the release plugin must have additional configuration applied so as to execute the "clean install" goals during release preparation:

<plugin>
  <groupId>org.apache.maven.plugins</groupId>
  <artifactId>maven-release-plugin</artifactId>
  <version>2.4.1</version>
  <configuration>
    <preparationGoals>clean install</preparationGoals>
  </configuration>
</plugin>

Although this might not be considered a bug, as I see it there are at least two options that might be taken to help others better deal with the release scenario:

1. If possible, use plugin extensions to automatically ensure clean install is run during a release preparation.
2. At the very least, add appropriate documentation to the plugin site.

The following seems to have no affect:

<linker>
  <options>
    <option>/NOLOGO</option>
    <option>/DLL</option>
    <option>/SUBSYSTEM:CONSOLE</option>
  </options>
  <clearDefaultOptions>true</clearDefaultOptions>
...
</linker>

Running with debug on I can clearly see that the default linker options are not overriden:

[DEBUG] Execute:Java13CommandLauncher: Executing 'link' with arguments:
'/MANIFEST'
'/NOLOGO'
'/DLL'
'/SUBSYSTEM:CONSOLE'
'/NOLOGO'
'/DLL'
'/SUBSYSTEM:CONSOLE'
'/INCREMENTAL:NO'

-Michael

The documentation for the goal nar:nar-resources basically just says "throw files into src/nar/resources"

So, I put some .so files in src/nar/resources, but nar:nar-resources did not see these files.

Then I put files into src/nar/resources/noarch and src/nar/resources/x86_64-Linux-g++. The files under "noarch" were picked up, but the files under "x86_64-Linux-g++" were not.

Java 7's javah requires all referenced classes to be classpath. This includes classes that are only referenced as method parameters and are never instantiated.

This was not a requirements of the Java 6 version of javah. In order to overcome this, the -classpath option must specify dependencies as well as the current project's built classes directory. I have tried adding ${maven.compile.classpath} to the various nar plugin javah configurations but they are always evaluated as null.