Mark Donszelmann wrote:
Hi
System.load:
- for the user we still need to make some assembly goal that grabs all
the shared and jni like libs and puts them in a lib directory. A small setup script
can then set the appropriate ld_library_path or the like.
- for maven the nar plugin includes an
Hi
System.load:
- for the user we still need to make some assembly goal that grabs
all the shared
and jni like libs and puts them in a lib directory. A small setup
script can then set
the appropriate ld_library_path or the like.
- for maven the nar plugin includes an integration test goal
Mark Donszelmann wrote:
The NAR gets unpacked in the local repository under the directory where the
jar file is stored, so underneath a parent directory with that version
number.
Ah ha, I see. In that case, how does your System.load() call know where
to find the library? I guess it has knowle
The jar file and its attached nar files share one pom, so are
associated to one
version.
The NAR gets unpacked in the local repository under the directory
where the
jar file is stored, so underneath a parent directory with that
version number.
Nothing is currently done about locking the f
Mark Donszelmann wrote:
Hi
in the freehep-nar-plugin (for maven 1, being ported to maven 2)
we have such a solution.
>
Hrm, I wish I'd heard about this sooner! Sounds very interesting.
I have a couple of questions... Do you unpack all nar files into the
same directory? If so, how do you dea
Hi
in the freehep-nar-plugin (for maven 1, being ported to maven 2)
we have such a solution.
We build a generic jar file (with classes as needed and a special
properties file).
The properties file refers to native jar files (nar files), normally:
the noarch file which has the include directorie
On 5/9/06, Richard van der Hoff <[EMAIL PROTECTED]> wrote:
...
This brings me to my next thought, which is that the maven "artifact"
probably ought to be a zip file (or similar) containing the
correctly-named library. This is good because it means my artifacts have
the same extension no matter
Hi Dan,
dan tran wrote:
Hi Richard,
The native-maven-plugin JNI example shows that you can have your native
project depends on a java jar project that has
java jni interfaces. This way you can use native plugin to generate jni
native include files before building the native artifacts.
This is
Hi Richard,
The native-maven-plugin JNI example shows that you can have your native
project depends on a java jar project that has
java jni interfaces. This way you can use native plugin to generate jni
native include files before building the native artifacts.
This is the same behavior in mave
A while ago, I posted here asking for help with using Maven to handle
projects which make use of JNI code.
I was met by a stony wall of silence at that time... Anyway, a month
later, and after quite a lot of thinking, hacking and tweaking, I've
come up with a solution I'm reasonably happy with
You seem to be on the right track. We'd certainly welcome contributions
along these lines, and there are a few people working on this elsewhere
already as you've highlighted.
Have you seen
http://docs.codehaus.org/display/MAVEN/Support+for+other+languages?
- Brett
Richard van der Hoff wrote
Richard van der Hoff wrote:
On the other hand, it means I now need to set up my assembly such that
the zip files are unpacked. Ideally, I'd like for all such artifacts to
be unpacked automatically, but there doesn't seem to be any way of doing
so without configuring it in each assembly.xml. It'
Hi all,
Apologies in advance for the length of this mail. As you'll see, I've
been thinking about this for a while, but I want to get it right first
time rather than end up supporting legacy builds in the future. I'm
looking for suggestions on how best to handle native libraries. We have
quit
13 matches
Mail list logo
