Re: Automating the build of a JNI based application
Hi, Thanks for your suggestions. I tried the nar-maven-plugin as described on the usage page ( http://maven-nar.github.io/usage.html). I have the following pom: http://maven.apache.org/POM/4.0.0"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd";> 4.0.0 cz ... 1.0-SNAPSHOT nar maven-compiler-plugin 3.1 1.7 1.7 com.github.maven-nar nar-maven-plugin 3.2.3 true jni cz And the following maven version: *Apache Maven 2.2.1 (rdebian-4)* And when I run *mvn clean package* I get the following error *Internal error in the plugin manager executing goal 'com.github.maven-nar:nar-maven-plugin:3.2.3:nar-validate': Unable to load the mojo 'com.github.maven-nar:nar-maven-plugin:3.2.3:nar-validate' in the plugin 'com.github.maven-nar:nar-maven-plugin'. A required class is missing: org/sonatype/aether/resolution /ArtifactResolutionException org.sonatype.aether.resolution.ArtifactResolutionException* What's wrong? Thanks, Dusan 2015-08-01 21:05 GMT+02:00 Benson Margulies : > Look for the modern nar plugin on github. > > On Fri, Jul 31, 2015 at 12:59 PM, Karl Heinz Marbaise > wrote: > > Hi, > > > > On 7/31/15 6:51 PM, Dušan Rychnovský wrote: > >> > >> Hi, > >> > >> I'm creating a JNI wrapper on top of a C++ library. I'd like to have a > >> "one-click" Maven build for the whole application. When building it > >> manually, I need to do the following: > >> > >> javac ... (compile the Java source files) > >> javah ... (generate JNI header files from Java class files) > >> g++ ... (compile the JNI source files + link them with the static > >> library) > >> > >> I'm looking for a way to have these commands executed by Maven. > >> > >> I looked at the native-maven-plugin ( > >> http://maven.apache.org/archives/maven-1.x/plugins/native/index.html) > and > >> I'm afraid it will not work for me. > > > > > > Nor should it cause Maven 1 is simply dead.. > > > > > >> > >> * The documentation is extremely insufficient (there is literally no > >> official documentation on the plugin site and nor is there any > information > >> elsewhere on the Internet). > > > > > > which is not really astonishing... > > > > > >> > >> * I cannot even look at the source-code as it isn't there in the SVN > >> repository linked from the plugin site. > >> > >> * I tried to make it work based on the two SO posts I discovered but I > >> couldn't. > >> > >> I'm thinking about the following project layout: > >> > >> /src > >> /src/main > >> /src/main/java... the Java interfaces with native methods > >> /src/main/native ... the C++ implementation of the generated header > files > >> > >> The static library itself is a product of a different project and will > be > >> installed on my system in a standard location (i.e. outside of this > >> project). > >> > >> What I need is essentially to call the javah and g++ commands after the > >> Java .class files have been generated. The g++ command is non-trivial, > >> there are quite a few compiler and linker options that need to be > applied. > >> The generated library file should not be a part of the generated JAR > file, > >> it should be a separate artifact. > >> > >> I was thinking maybe I'll need to use the exec-maven-plugin ( > >> http://www.mojohaus.org/exec-maven-plugin/index.html) and run the > commands > >> manually? Or is there a better way to do this? > >> > >> Also, once the library is generated, I'd like to have Maven run some > test > >> cases using the generated JNI wrapper to make sure it works correctly. > >> > >> Thanks very much for your help. > >> > >> Kind regards, > >> Dusan > >> > > > > I woudl suggest to take a look into the nar-maven-plugin: > > > > http://maven-nar.github.io/ > > > > which might be better fit your needs.. > > > > Kind Regards > > Karl Heinz Marbaise > > > > - > > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > > For additional commands, e-mail: users-h...@maven.apache.org > > > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
Automating the build of a JNI based application
Hi, I'm creating a JNI wrapper on top of a C++ library. I'd like to have a "one-click" Maven build for the whole application. When building it manually, I need to do the following: javac ... (compile the Java source files) javah ... (generate JNI header files from Java class files) g++ ... (compile the JNI source files + link them with the static library) I'm looking for a way to have these commands executed by Maven. I looked at the native-maven-plugin ( http://maven.apache.org/archives/maven-1.x/plugins/native/index.html) and I'm afraid it will not work for me. * The documentation is extremely insufficient (there is literally no official documentation on the plugin site and nor is there any information elsewhere on the Internet). * I cannot even look at the source-code as it isn't there in the SVN repository linked from the plugin site. * I tried to make it work based on the two SO posts I discovered but I couldn't. I'm thinking about the following project layout: /src /src/main /src/main/java... the Java interfaces with native methods /src/main/native ... the C++ implementation of the generated header files The static library itself is a product of a different project and will be installed on my system in a standard location (i.e. outside of this project). What I need is essentially to call the javah and g++ commands after the Java .class files have been generated. The g++ command is non-trivial, there are quite a few compiler and linker options that need to be applied. The generated library file should not be a part of the generated JAR file, it should be a separate artifact. I was thinking maybe I'll need to use the exec-maven-plugin ( http://www.mojohaus.org/exec-maven-plugin/index.html) and run the commands manually? Or is there a better way to do this? Also, once the library is generated, I'd like to have Maven run some test cases using the generated JNI wrapper to make sure it works correctly. Thanks very much for your help. Kind regards, Dusan
Re: Log4J - "cannot find symbol - method trace(String)"
Thank you all, I have finally managed to find the root of the problem.
Nick's warning about the possibility of a different Log4J version as a
transitive dependency got me thinking and I tried disabling the
dependencies, one at a time, to see what would happen. The errors
disappeared after disabling a custom 3rd party library that I have
installed to my local repository manually and after inspecting its contents
it turned out that there is an older Log4J version packed inside the JAR
along with the rest of the library.
Thank you once more for all your quick responses,
Dušan
2014-04-30 14:44 GMT+02:00 Nick Stolwijk :
> And for another thought: maybe of your other dependencies include the
> org.apache.log4j.Logger class but with a different version.
>
> Check with maven copy dependencies and a grep over the contents of all
> the jar files.
>
> Here is how I do it:
>
> 02:40:48 {master} ~/sandbox/bowling-nickstolwijk$ mvn
> dependency:copy-dependencies
> [INFO] Scanning for projects...
> [INFO]
> [INFO] Using the builder
>
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder
> with a thread count of 1
> [INFO]
> [INFO]
>
> [INFO] Building bowling-nickstolwijk 1.0-SNAPSHOT
> [INFO]
>
> [INFO]
> [INFO] --- maven-dependency-plugin:2.8:copy-dependencies (default-cli)
> @ bowling-nickstolwijk ---
> [INFO] hamcrest-core-1.3.jar already exists in destination.
> [INFO] junit-4.11.jar already exists in destination.
> [INFO] hamcrest-library-1.3.jar already exists in destination.
> [INFO] mockito-core-1.9.5.jar already exists in destination.
> [INFO] objenesis-1.0.jar already exists in destination.
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> [INFO] Total time: 1.143 s
> [INFO] Finished at: 2014-04-30T14:41:08+01:00
> [INFO] Final Memory: 9M/153M
> [INFO]
>
> 02:41:08 {master} ~/sandbox/bowling-nickstolwijk$ cd target/dependency/
> 02:41:16 {master} ~/sandbox/bowling-nickstolwijk/target/dependency$
> findjar.sh . Logger
> Starting search for JAR files from directory .
> Looking for the class Logger
>
> This might take a while...
>
> org/mockito/internal/debugging/VerboseMockInvocationLogger.class
> org/mockito/internal/debugging/VerboseMockInvocationLogger.java
> org/mockito/internal/util/ConsoleMockitoLogger.class
> org/mockito/internal/util/ConsoleMockitoLogger.java
> org/mockito/internal/util/MockitoLogger.class
> org/mockito/internal/util/MockitoLogger.java
> org/mockito/internal/util/SimpleMockitoLogger.class
> org/mockito/internal/util/SimpleMockitoLogger.java
> ./mockito-core-1.9.5.jar
> 02:41:20 {master} ~/sandbox/bowling-nickstolwijk/target/dependency$
> cat ~/bin/findjar.sh
> #!/bin/sh
> #
> # findjar.sh by Samuli Kaski
> #
>
> VERBOSE=no
>
> if [ $# -ne 2 ]; then
> echo "Usage: findjar.sh ";
> exit;
> fi
>
> STARTPATH=$1
> CLASS=$2
>
> echo "Starting search for JAR files from directory $STARTPATH"
> echo "Looking for the class $CLASS"
> echo ""
> echo "This might take a while..."
> echo ""
>
> for jar in `find $STARTPATH -name '*.jar'`;
> do
> BASENAME=`basename $jar`
>
> jar -tf $jar | grep $CLASS
>
> if [ $? -eq 0 ]; then
>
>echo "$jar"
> fi
> done
>
> Hth,
> Nick Stolwijk
>
> ~~~ Try to leave this world a little better than you found it and,
> when your turn comes to die, you can die happy in feeling that at any
> rate you have not wasted your time but have done your best ~~~
>
> Lord Baden-Powell
>
>
> On Wed, Apr 30, 2014 at 2:29 PM, Nick Stolwijk
> wrote:
> > Could you check your checksum on the log4j jar file? Maybe there is
> > some corruption in your repository.
> >
> > 02:28:40 ~/.m2/repository/log4j/log4j/1.2.17$ ls -altr log4j-1.2.17.jar
> > -rw-r--r-- 1 nick nick 489884 Jan 8 13:31 log4j-1.2.17.jar
> > 02:28:45 ~/.m2/repository/log4j/log4j/1.2.17$ sha1sum log4j-1.2.17.jar
> > 5af35056b4d257e4b64b9e8069c0746e8b08629f log4j-1.2.17.jar
> > 02:28:47 ~/.m2/repository/log4j/log4j/1.2.17$ cat log4j-1.2.17.jar.sha1
> > 5af35056b4d257e4b64b9e8069c0746e8b08629f
> >
> > Hth,
> >
> > Nick Stolwijk
> >
> > ~~~ Try to leave this world a little better than you found it and,
> > when your turn
Re: Log4J - "cannot find symbol - method trace(String)"
Thank you both for your help. Unfortunatelly, neither seems to be the case. * dependency:tree confirmed that version 1.2.17 is beeing used indeed (log4j:log4j:jar:1.2.17:compile), * I have verified that the import statement is correct (import org.apache.log4j.Logger;). Dušan 2014-04-30 13:55 GMT+02:00 Stuart McCulloch : > Also check your java imports, just in case you’ve imported a different > Logger by mistake (such as java.util.logging.Logger) > > On 30 Apr 2014, at 12:48, Nick Stolwijk wrote: > > > You can use the dependency:tree[1] goal to view a tree of your > > dependencies to see if the correct version of Log4J is being included > > in the compiler classpath. > > > > [1] > https://maven.apache.org/plugins/maven-dependency-plugin/tree-mojo.html > > > > Hth, > > > > Nick Stolwijk > > > > ~~~ Try to leave this world a little better than you found it and, > > when your turn comes to die, you can die happy in feeling that at any > > rate you have not wasted your time but have done your best ~~~ > > > > Lord Baden-Powell > > > > > > On Wed, Apr 30, 2014 at 1:41 PM, Dušan Rychnovský > > wrote: > >> Hi everyone, > >> > >> I have the following dependency in my project's POM: > >> > >> ... > >> > >>log4j > >>log4j > >>1.2.17 > >> > >> ... > >> > >> The artifact is downloaded to my local repository, but, during the > compile > >> phase, the following error is emitted and the build process is aborted: > >> > >> [ERROR] Failed to execute goal > >> org.apache.maven.plugins:maven-compiler-plugin:2.5.1:compile > >> (default-compile) on project dbtoixattrdt: Compilation failure: > Compilation > >> failure: > >> [ERROR] > >> > d:\prace\dbtoixattrdt\DBToIXATTRDT-TRUNK\src\main\java\dbtoixattrdt\TraceLogAspect.java:[19,8] > >> error: cannot find symbol > >> [ERROR] symbol: method trace(String) > >> [ERROR] location: variable logger of type Logger > >> > >> This error message does not make much sense, as the trace method should > be > >> available on the Logger class in Log4J version 1.2.17. > >> > >> What can be wrong? > >> > >> Thanks in advance, > >> Dušan > > > > - > > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > > For additional commands, e-mail: users-h...@maven.apache.org > > > > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
Log4J - "cannot find symbol - method trace(String)"
Hi everyone, I have the following dependency in my project's POM: ... log4j log4j 1.2.17 ... The artifact is downloaded to my local repository, but, during the compile phase, the following error is emitted and the build process is aborted: [ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:2.5.1:compile (default-compile) on project dbtoixattrdt: Compilation failure: Compilation failure: [ERROR] d:\prace\dbtoixattrdt\DBToIXATTRDT-TRUNK\src\main\java\dbtoixattrdt\TraceLogAspect.java:[19,8] error: cannot find symbol [ERROR] symbol: method trace(String) [ERROR] location: variable logger of type Logger This error message does not make much sense, as the trace method should be available on the Logger class in Log4J version 1.2.17. What can be wrong? Thanks in advance, Dušan
Artifact with external configuration - the Maven way
Hi! I'm using Maven at work to organize my software projects. I will first of all describe you my current build process. - The typical deployment assembly contains at least: - the application JAR file, - a JAR file for every dependency, - an application configuration file (an XML file with an XSD schema file), - Log4J configuration file (a single XML file). It is important that the application configuration file is not packaged inside the application JAR file - I could not change configuration in production otherwise. The Maven assembly plugin is used to package all those files into a single ZIP to allow convenient deploy at the target machine. - For every environment (e.g. development, test, acceptance, production) there is a single Maven profile. The configuration files contain property placeholders. When building the assembly, the values of properties used in the configuration files (e.g. the default configuration values) are resolved according to the active profile. - The question I have is how to store the builds to be available for deployment - so that I don't have to build the project every time I need to deploy the application to a new machine. To my understanding, a Nexus repository is typically used for that. I have found out though that a Maven repository is only capable of storing simple artifacts, not ZIP assemblies. I am convinced that there are plenty of projects that need external configuration files in addition to the application JARs. What is the commonly used way to handle my issue? Thank you in advance for all replies. Dusan R.
Resolving the SNAPSHOT placeholder in the package phase
Hi! Is there a way to make Maven susbtitute the counter for the SNAPSHOT placeholder in the package phase? I use the assembly plugin to bundle the jar from the target directory together with some configuration files into a zip archive and I would need both the jar and zip files to bear the SNAPSHOT version in their names. I need this so that archives produced by two or more consecutive builds get different names (plus so that I can identify the newest of them). Thanks! Dusan Rychnovsky
Preventing Maven from escaping filtered properties
Hi,
I found out that Maven would not filter properties inside resource files if
preceeded (escaped) by a backslash.
In my case however, the backslash preceeding a property is a part of a
Windows FS Path. I need "C:\build\${artifactId}" to be substituted like
"C:\build\appartifact", not like "C:\build\${artifactId}". I tried to
double the affected backlash like "C:\build\\${artifactId}", but that would
yield a "C:\build\\appartifact" (e.g. the doubled backslash would remain).
What is the correct way of preventing a backslash to escape the following
property?
I'm using Maven version 3.0.4.
Thanks in advance,
Dusan R.
maven-resources-plugin - copying custom nonpackaged resources - rewrite existing files
Hi all, I use the maven-resources-plugin to copy some configuration files to the same directory as the resulting jar goes to (which is different from the standard target directory - I changed that using the maven-jar-plugin's outputDirectory configuration selection). It works fine, there's just one issue. If a file with the same name (but different content) already exists in the directory, maven won't copy the new version of the file (and thus rewrite the old one). I don't want to delete the whole directory before the copying phase, because there might be other files, which I don't won't to lose. I have searched google and it seems to me that it is not possible to configure the plugin the way I need. Please prove me wrong or advise me what is the best way to get the behaviour I need. I'm using maven version 2.2.1. Please excuse my improper english. Thanks a lot! Dusan
