NAR package as dependency of a "normal" Java Library

[steffen....@gmail.com]

The situation: i made an NAR package for accessing a native C-library via JNI. The NAR package contains the native wrapping code (the JNIEXPORT stuff) and the Java Class to access the native code (Java native methods). This all is tested and works fine.

Now I want to use the Wrapping-Java class in another project - a JAR library. My intention was to add the NAR package as dependency to the maven pom.xml of the JAR library (as dependency <type>nar</type>). Dependency resolution in Maven works fine, but I'm not able to use the Java class until I made the JAR package itself a NAR package. This is no option because their are other depending project modules which cannot be altered to NAR packages.

Q: Is it possible to have a NAR module as dependency of a "normal" Java Library of packaging type JAR with full access to Java Classes defined inside the NAR module?

Thx.

[Roland Asmann]

Not sure, I don't have JNI in my applications, but reading the documentation I thought that your artifacts should contain a .JAR file as well... Is that correct? If so, just leave out the <type>-tag and you should be fine...

Roland

[steffen....@gmail.com]

There is a *.jar file in the target directory of the NAR module, but this one is not installed on the local Maven repository (~/.m2 folder). The Maven repository contains only *.nar files, which includes the native libraries as well as the Java class files. If I leave out the <type>nar</type> tag Maven expects a *.jar for dependency resolution which leads to an error ("could not find *.jar...").

For me, there are two possible solutions: 1) do some configuration tricks to get a *.jar file besides the *.nar files as output of the NAR modules, or 2) find some configuration for the normal JAR module to consume Java class files from a *.nar file instead of *.jar file.

Any hints?

[Curtis Rueden]

Hi Steffen,

Did you look at the imagej-launcher project linked from the NAR examples in the FAQ? It is very similar to your use case in that it is a single module project that generates both a NAR and a JAR. In our case both get installed and deployed successfully so maybe the answer you seek can be gleaned from its POM configuration.

Regards,
Curtis

--
You received this message because you are subscribed to the Google Groups "NAR Maven plugin" group.
To unsubscribe from this group and stop receiving emails from it, send an email to maven-nar+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Tobias Pietzsch]

Hi Steffen,

Did you find a solution yet? I'm having the same problem… When I manually copy the nar file in my .m2 to have a jar extension it works

best regards,

Tobias

[Tobias Pietzsch]

Hi,

just as a comment to save others the work:

I couldn't find any clue how to solve this in the imagej-launcher project linked from the NAR examples in the FAQ.

I just cloned the imagej-launcher project and tried it and for me the following happens with "mvn clean install"

I get a imagej-launcher-3.0.3-SNAPSHOT.jar in the projects target/ directory.

This is installed into my .m2 as imagej-launcher-3.0.3-SNAPSHOT.nar (it's the same file, just the extension is changed).

So, same problem there.

best regards,

Tobias

[Curtis Rueden]

Hi Tobias,

> I just cloned the imagej-launcher project and tried it and for me the

> following happens with "mvn clean install" I get a

> imagej-launcher-3.0.3-SNAPSHOT.jar in the projects target/ directory.

>

> This is installed into my .m2 as imagej-launcher-3.0.3-SNAPSHOT.nar

> (it's the same file, just the extension is changed).

>

> So, same problem there.

Thanks for the additional information. I understand the problem now.

Indeed, in my tests the same problem occurs. Adding a dependency with <type>nar</type> does not do the trick, because the NAR archive (unsurprisingly) is not put onto the classpath by Maven.

In the case of ImageJ, we never encountered the problem before because we actually do not have any downstream Java modules that depend on imagej-launcher directly. We simply ship that JAR as part of the application bundle using the dependency:copy goal.

So: I fear this is a bug in the nar-maven-plugin which needs to be fixed, if people want to be able to depend on mixed native/Java Maven projects. Or as a workaround, you could separate the Java portion of the code into its own Maven module.

Patches very welcome. Unfortunately, neither Dscho nor I currently have time to investigate, as the ImageJ 2.0.0 release looms. I also want to emphasize that though we are doing what we can to maintain the NAR project, we (especially in my case) are not experts on the codebase. So it's not really any less time consuming for us to attempt bug-fixes than for any other member of the NAR community to do so. Which means that when I say "patches very welcome" I really do mean it. We need all the contributions we can get!

Regards,

Curtis

[Johannes Schindelin]

Hi Curtis,

On Fri, 23 May 2014, Curtis Rueden wrote:

> Hi Tobias,
>
> > I just cloned the imagej-launcher project and tried it and for me the
> > following happens with "mvn clean install" I get a
> > imagej-launcher-3.0.3-SNAPSHOT.jar in the projects target/ directory.
> >
> > This is installed into my .m2 as imagej-launcher-3.0.3-SNAPSHOT.nar
> > (it's the same file, just the extension is changed).
> >
> > So, same problem there.
>
> Thanks for the additional information. I understand the problem now.
>
> Indeed, in my tests the same problem occurs. Adding a dependency with
> <type>nar</type> does not do the trick, because the NAR archive
> (unsurprisingly) is not put onto the classpath by Maven.

Me, too, I am a relative new-comer, and I am still amazed how I got myself
talked into (co-)maintaining this project. To be perfectly honest, I have
next to no clue about most of the internals of the plugin itself. Whenever
I have a problem with the NAR plugin, I have to do exactly the same as
everybody else, just as Curtis described: study the code.

Having said that, I do have a gem of experience to share: My personal
go-to place when trying to figure out how to do things with the NAR plugin
is src/it/. And there is indeed an integration test that tries to link to
a dependency with 'nar' packaging:

https://github.com/maven-nar/nar-maven-plugin/blob/master/src/it/it0004-java-dep-jni/src/main/java/it0004/test/Hello.java

depends on

https://github.com/maven-nar/nar-maven-plugin/blob/master/src/it/it0003-jni/src/main/java/it0003/HelloWorldJNI.java

and as you can see, the dependency is specified as Curtis suggested:

https://github.com/maven-nar/nar-maven-plugin/blob/b4605b8cf1325589b28526f90eac43d11a42f782/src/it/it0004-java-dep-jni/pom.xml#L68-L73

The *difference* is that it0004's packaging is *also* set to 'nar':

https://github.com/maven-nar/nar-maven-plugin/blob/b4605b8cf1325589b28526f90eac43d11a42f782/src/it/it0004-java-dep-jni/pom.xml#L33

That will work as a workaround in the meantime.

But as Curtis mentioned in his mail, this project does not work if users
expect the maintainers to patch the code to their needs.

Patches *will* be welcome, of course, because a project workflow with
users contributing patches addressing their issues with the NAR plugin,
that *does* work.

Ciao,
Johannes

[Trevor Robinson]

Hi all,

I think I may have a solution for consuming a NAR project from a JAR project. The first step is to bind the appropriate lifecycle phases to NAR plugin goals in the JAR project POM:

  <build>

    <plugins>

      <plugin>

        <groupId>com.github.maven-nar</groupId>

        <artifactId>nar-maven-plugin</artifactId>

        <version>3.1.1-SNAPSHOT</version>

        <executions>

          <execution>

            <id>nar-download</id>

            <goals>

              <goal>nar-download</goal>

            </goals>

          </execution>

          <execution>

            <id>nar-integration-test</id>

            <goals>

              <goal>nar-integration-test</goal>

            </goals>

          </execution>

        </executions>

      </plugin>

    </plugins>

  </build>

The nar-download bit works fine as-is, and allows compilation to proceed. To get integration tests working, however, I had to fix what appears to be two bugs in how NarIntegrationTestMojo processes dependencies:

• NarIntegrationTestMojo.getArtifacts() overrides AbstractDependencyMojo.getArtifacts() to get test artifacts, but it has two problems:
  
• It calls MavenProject.getTestArtifacts(), which filters out the NAR artifacts. This is because getArtifactHandler().isAddedToClasspath() returns false for the NAR artifact, for whatever reason.
• It doesn't include the NarManager.getNarDependencies() logic from AbstractDependencyMojo.
• The Surefire boot classpath is built from the project.testClasspathElements property, which also seems to exclude NAR artifacts. This may be for the reason above.
  

Patch is here: https://github.com/trevorr/nar-maven-plugin/compare/nar-from-jar?expand=1

If that looks reasonable, I can submit a pull request.

Thanks,

Trevor

[Curtis Rueden]

Hi Trevor,

> Patch is here: https://github.com/trevorr/nar-maven-plugin/compare/nar-from-jar?expand=1

>

> If that looks reasonable, I can submit a pull request.

Thanks very much for following up! I would definitely encourage you to file the PR; we can discuss the details further there.

Also: would it make sense to amend it0004 to use jar packaging, to prevent regressions once these improvements are merged?

Regards,

Curtis

[Johannes Schindelin]

Hi Trevor,

On Mon, 9 Jun 2014, Trevor Robinson wrote:

> If that looks reasonable, I can submit a pull request.

I submitted the PR for you: this makes it much easier to discuss the code
and keep track of changes.

In short, I would like to ask you to split this into at least three, more
likely four commits (also to make it easier for me to review because there
are about ten different tickets my mind thinks about at the same time
these days).

To get an idea what I mean by "splitting commits", see
http://git-scm.com/book/en/Git-Tools-Rewriting-History#Splitting-a-Commit;
After rewriting the branch thusly, you can easily force-push (git push
<repository> +HEAD) to update the pull request.

Thank you for your contribution!
Johannes

[Trevor Robinson]

Hi Johannes,

Thanks. However, after further investigation, I've found that the changes are unnecessary. Because I wasn't building a NAR, I hadn't included <extensions>true</extensions> for the NAR plugin. This causes its artifact handler not to be registered, which results in the default artifact handler being used, which doesn't include artifacts in the classpath. Once I enabled it as an extension, simply binding the plugin to the correct phases was adequate. I've submitted a separate PR for an integration test demonstrating this. The original PR can be canceled.

-Trevor

[Johannes Schindelin]

Hi Trevor,

On Thu, 12 Jun 2014, Trevor Robinson wrote:

> Thanks. However, after further investigation, I've found that the
> changes are unnecessary. Because I wasn't building a NAR, I hadn't
> included <extensions>true</extensions> for the NAR plugin. This causes
> its artifact handler not to be registered, which results in the default
> artifact handler being used, which doesn't include artifacts in the
> classpath. Once I enabled it as an extension, simply binding the plugin
> to the correct phases was adequate. I've submitted a separate PR for an
> integration test demonstrating this. The original PR can be canceled.

Thanks for the detailed analysis! I closed the PR, but please feel free to
close your PRs when you feel they are superseded by others. GitHub will
preserve the history for future's record.

Thank you!
Johannes

[bimar...@gmail.com]

I'm not succeeding at this with 3.1.0. dependency:tree shows the nar dependency, but compiling doesn't see any classes.

[Trevor]

Can you try cloning the NAR plugin source ("git clone https://github.com/maven-nar/nar-maven-plugin.git"), running the integration tests ("mvn -Prun-its"), and seeing if the new it0025 test is working for you? That would eliminate any Maven version doubt.

Next, do you see that the NAR plugin is unpacking the NAR before the compile phase? This should be visible in the default log output.

If that is occurring, the next step would be to verify the classpath being used. You would need to run "mvn -X" to see that. There will be lots of output, but you should be able to find the classpath being provided to the compiler.

If the NAR path is not showing up there, make sure you're using <extensions>true</extensions> when configuring the NAR plugin in your JAR POM. If you are, then share your POM and I can take a look.

-Trevor

[bimar...@gmail.com]

It got happy when I did a clean and tried another build. Go figure?

Yes the IT's pass for me.