-
Notifications
You must be signed in to change notification settings - Fork 160
Frequently_Asked_Questions
Q: Is this repository (https://github.com/maven-nar/nar-maven-plugin) the official home of the NAR plugin?
A: Yes. @duns, the original author, donated the plugin (with Sonatype's approval) to the community, since he no longer has time to maintain it.
A: Only a little. It was rather dormant until 2013, but a burst of community activity resurrected it. As of this writing, however, most of the people responsible for relaunching the project on GitHub have since stepped away from the project. There are still a few people sporadically participating in the development, but no one is taking full ownership of the project anymore.
We are actively seeking co-maintainers, as well as more people pledged to offer community support on GitHub and via the mailing list.
A: NAR is a volunteer project; no one is paid to work on it full time. So development is driven by community contributions. This means you! If there is a bug or feature you want addressed, we encourage you to file a pull request with your patch. The maintainers are very happy to help you, if you take the first step.
The maintainers often write "patches welcome" in response to bug reports, a phrase which unfortunately has grown to have negative connotations. But in the case of this project, we truly mean it! The reality is that none of the NAR maintainers have time to actively investigate bug reports or improve the codebase on our own. We do what we can to maintain the NAR project, but we are not experts on the codebase. It is no 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 we say "patches very welcome" we really do mean it. We need all the contributions we can get!
See the How to contribute page!
A: To comply with the permitted usages of the Maven trademark. According to the Apache Project Management Committee:
The pmc is permitting persons who develop plugins for maven to use the mark maven in their plugin name provided the name and its usage meets certain criteria, amongst which is the "___-maven-plugin" naming scheme.The NAR plugin was previously named `maven-nar-plugin` because it was slated for adoption as an official Maven plugin, but that never happened. So the `artifactId` has been changed to `nar-maven-plugin`. (The `groupId` also changed from `org.apache.maven.plugins` to `com.github.maven-nar`.)
A: The maven-nar Google group.
A:
GitHub Issues. There
was a category for NAR in the Sonatype
JIRA, which was active until May 2013,
but it has apparently been deleted, so we unfortunately cannot migrate those
issues to GitHub. If you had filed an issue there which is still relevant to
the latest master branch, please file a new GitHub issue for it. Thanks!
A: Yes, releases are deployed to Sonatype's OSS repository. Version 3.0.0 was released on December 6th, 2013. Version 3.1.0 was released on June 7th, 2014. Maven Central mirrors the Sonatype OSS repository, including the nar-maven-plugin.
A: Yes, stable releases are now available on Central!
<plugin>
<groupId>com.github.maven-nar</groupId>
<artifactId>nar-maven-plugin</artifactId>
<version>3.0.0</version>
</plugin>
The source for 3.0.0 is tagged on GitHub.
A: See the Working examples page!
A: See Testing the latest SNAPSHOTs.
A: See Running a specific integration test.
A: See Debugging integration tests in an IDE.
A:
The nar-package goal generates the nar.properties file which needs to be included in the general jar artifact.
Q: Why does the NAR plugin produce both a jar artifact and an attached -noarch.nar artifact. Could these two not be combined?
A:
The jar artifact contains only java classes and gets added to the classpath.
It needs no further processing. The -noarch.nar artifact contains include
files and needs to be unpacked to be useful for the native compilers.
It does not need to be added to the classpath. Combining the two artifacts
would complicate matters.
A:
The JNI library is strictly connected to the corresponding java code in the
main artifact (jar file). Since the main artifact has a version number, we decided
that the JNI library should have the same version number. If you add the subtag
<narSystemPackage> to the <library> tag, the NAR plugin will generate a NarSystem
class for you which will load the library. Assuming you specified com.mycompany.mypackage
as narSystemPackage, then you need to add the following code to the class with the native
methods:
import com.mycompany.mypackage.NarSystem
public class ... {
...
static {
NarSystem.loadLibrary();
}
...
}Q: How do I use the NAR plugin to create a JNI type library for multiple platforms (Windows, MacOSX and Linux)?
A:
First of all, you have to generate the platform-dependent attached artifacts from each platform, which will be called .nar files for convenience from here. Jenkins is highly recommended in this case. Secondly, native-lib-loader should be specified as a <dependency> in your pom.xml file. Additionally, you need to specify
which will be used to load the native libraries. In this case, NAR plugin going to use native-lib-loader instead of System.load() function. Because the native-lib-loader will be used to unpack and load the native libraries from the given .nar files. This requires the .nar files to be in the class path so that native-lib-loader can find the appropriate native library.