native-maven-plugin jni osx pom - maven

I'm trying add a JNI library written in c/cpp to a java project. The java project is called Subsonic, it's a media server. I want to add support for .spc files so I wrote some JNI to make that happen. I just don't understand maven very well.
This is the directory structure:
subsonic/
gme/
*.cpp
snes.c -->contains C jni code
subsonic-main/
...
src/main/java/net/sourceforge/subsonic/service/metadata/
GMEMetaDataParser.java -->contains the JNI calls
My problem is that I can't figure out how to make maven work with me. This is my current pom file:
<project>
<modelVersion>4.0.0</modelVersion>
<artifactId>gme</artifactId>
<name>JNI Libraries for Subsonic</name>
<packaging>dylib</packaging>
<parent>
<groupId>net.sourceforge.subsonic</groupId>
<artifactId>subsonic</artifactId>
<version>5.0.beta1</version>
</parent>
<build>
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>native-maven-plugin</artifactId>
<extensions>true</extensions>
<configuration>
<!-- trigger javah -->
<javahOS>macosx</javahOS>
<compilerProvider>generic-classic</compilerProvider>
<compilerExecutable>gcc</compilerExecutable>
<linkerExecutable>gcc</linkerExecutable>
<sources>
<source>
<directory>./</directory>
<fileNames>
<fileName>snes.c</fileName>
<fileName>Ay_Apu.cpp</fileName>
<fileName>Ay_Cpu.cpp</fileName>
<fileName>Ay_Emu.cpp</fileName>
<fileName>Blip_Buffer.cpp</fileName>
<fileName>Classic_Emu.cpp</fileName>
<fileName>Data_Reader.cpp</fileName>
<fileName>Dual_Resampler.cpp</fileName>
<fileName>Effects_Buffer.cpp</fileName>
<fileName>Fir_Resampler.cpp</fileName>
<fileName>Gb_Apu.cpp</fileName>
<fileName>Gb_Cpu.cpp</fileName>
<fileName>Gb_Oscs.cpp</fileName>
<fileName>Gbs_Emu.cpp</fileName>
<fileName>Gme_File.cpp</fileName>
<fileName>Gym_Emu.cpp</fileName>
<fileName>Hes_Apu.cpp</fileName>
<fileName>Hes_Cpu.cpp</fileName>
<fileName>Hes_Emu.cpp</fileName>
<fileName>Kss_Cpu.cpp</fileName>
<fileName>Kss_Emu.cpp</fileName>
<fileName>Kss_Scc_Apu.cpp</fileName>
<fileName>M3u_Playlist.cpp</fileName>
<fileName>Multi_Buffer.cpp</fileName>
<fileName>Music_Emu.cpp</fileName>
<fileName>Nes_Apu.cpp</fileName>
<fileName>Nes_Cpu.cpp</fileName>
<fileName>Nes_Fme7_Apu.cpp</fileName>
<fileName>Nes_Namco_Apu.cpp</fileName>
<fileName>Nes_Oscs.cpp</fileName>
<fileName>Nes_Vrc6_Apu.cpp</fileName>
<fileName>Nsf_Emu.cpp</fileName>
<fileName>Nsfe_Emu.cpp</fileName>
<fileName>Sap_Apu.cpp</fileName>
<fileName>Sap_Cpu.cpp</fileName>
<fileName>Sap_Emu.cpp</fileName>
<fileName>Sms_Apu.cpp</fileName>
<fileName>Snes_Spc.cpp</fileName>
<fileName>Spc_Cpu.cpp</fileName>
<fileName>Spc_Dsp.cpp</fileName>
<fileName>Spc_Emu.cpp</fileName>
<fileName>Spc_Filter.cpp</fileName>
<fileName>Vgm_Emu.cpp</fileName>
<fileName>Vgm_Emu_Impl.cpp</fileName>
<fileName>Ym2413_Emu.cpp</fileName>
<fileName>Ym2612_Emu.cpp</fileName>
<fileName>gme.cpp</fileName>
</fileNames>
</source>
<!-- additional include path -->
<source>
<directory>/Library/Java/JavaVirtualMachines/jdk1.7.0_45.jdk/Contents/Home/include/darwin</directory>
<includes>
<include>*.h</include>
</includes>
<deployable>true</deployable>
</source>
</sources>
</configuration>
</plugin>
</plugins>
</build>
</project>
Can anyone with an enormous heart please give me some pointers. I think I hate maven :(

There is a Maven plugin for eclipse. You could use that to build your server files and launch it on localhost:8080. This tutorial should help you.

Related

Error running JavaFX Jar file built from NetBeans using Maven

I'm using the current NetBeans, and have just created a simple JavaFX project with the Maven compiler.
It runs, cleans, builds etc. perfectly fine, no errors, when in NetBeans.
However, when I navigate to the folder "...Documents\NetBeansProjects\Simple Banking Application\target" and run the executable Jar file, nothing happens. So I tried to run it manually via command line (Java -jar file.jar) it shows me the reason is because of an error:
No main manifest attribute
After searching, I found a supposed solution, involving adding these few lines to the POM.xml:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<version>2.3.2</version>
<configuration>
<archive>
<manifest>
<addClasspath>true</addClasspath>
<mainClass>com.mycompany.mavenproject2.App</mainClass>
</manifest>
</archive>
</configuration>
</plugin>
Unfortunately, that just causes a new error:
Error: Could not find or load main class com.mycompany.mavenproject2.App
Caused by: java.lang.NoClassDefFoundError: javafx/application/Application
I'm at a loss, and I'm wondering if I'm just missing something obvious. A couple of preliminary notes:
-I made sure to set this as my main project in NB
-I'm using default configuration
-I've tried cleaning and building, and just building as well, everything runs without any errors in NB
-I've not modified anything settings-wises
-I did refactor the project from mavenproject2 to Simple Banking Application, but I did so using NB's renaming options so that it does so 'safely'. (For the artifactID I had to remove the whitespaces)
-I've made sure all the .class files and .java files are in the project folder (.java are found in src, .class are found in target>classes)
Just in case, here is my entire POM.xml document:
<project xmlns="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/maven-v4_0_0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>com.mycompany</groupId>
<artifactId>SimpleBankingApplication</artifactId>
<version>1.0-SNAPSHOT</version>
<properties>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
<maven.compiler.source>11</maven.compiler.source>
<maven.compiler.target>11</maven.compiler.target>
</properties>
<dependencies>
<dependency>
<groupId>org.openjfx</groupId>
<artifactId>javafx-controls</artifactId>
<version>13</version>
</dependency>
</dependencies>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.8.0</version>
<configuration>
<release>11</release>
</configuration>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<version>2.3.2</version>
<configuration>
<archive>
<manifest>
<addClasspath>true</addClasspath>
<mainClass>com.mycompany.mavenproject2.App</mainClass>
</manifest>
</archive>
</configuration>
</plugin>
<plugin>
<groupId>org.openjfx</groupId>
<artifactId>javafx-maven-plugin</artifactId>
<version>0.0.4</version>
<configuration>
<mainClass>com.mycompany.mavenproject2.App</mainClass>
</configuration>
<executions>
<execution>
<!-- Default configuration for running -->
<!-- Usage: mvn clean javafx:run -->
<id>default-cli</id>
</execution>
<execution>
<!-- Configuration for manual attach debugging -->
<!-- Usage: mvn clean javafx:run#debug -->
<id>debug</id>
<configuration>
<options>
<option>-agentlib:jdwp=transport=dt_socket,server=y,suspend=y,address=localhost:8000</option>
</options>
</configuration>
</execution>
<execution>
<!-- Configuration for automatic IDE debugging -->
<id>ide-debug</id>
<configuration>
<options>
<option>-agentlib:jdwp=transport=dt_socket,server=n,address=${jpda.address}</option>
</options>
</configuration>
</execution>
<execution>
<!-- Configuration for automatic IDE profiling -->
<id>ide-profile</id>
<configuration>
<options>
<option>${profiler.jvmargs.arg1}</option>
<option>${profiler.jvmargs.arg2}</option>
<option>${profiler.jvmargs.arg3}</option>
<option>${profiler.jvmargs.arg4}</option>
<option>${profiler.jvmargs.arg5}</option>
</options>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
<name>Simple Banking Application</name>
</project>
You don't have the JavaFX components on your module path.
You can use a JDK which includes JavaFX (e.g. Azul JDK FX or Liberica Full JDK).
OR, you can follow the instructions below.
See the section on setting the VM arguments for running a JavaFX application as a jar file.
java --module-path /path/to/javafx-sdk-14/lib --add-modules javafx.controls,javafx.fxml -jar myJar.jar
You are using netbeans + maven, so refer to the official documentation openjfx.io JavaFX and NetBeans: modular with maven for more information. It discusses VM arguments for the Java module system to support JavaFX as well as creating runtime images using jlink.
If you don't know or understand the basics of the Java module system, then you should take some time to study and learn it from an appropriate tutorial. That will help you better understand the command line arguments required for the module system as well as the module-info.java alternative.
See the packaging instructions in the JavaFX tag which provide information on packaging alternatives (e.g. jlink and jpackage).
Use up-to-date software (e.g. JDK/JavaFX 18 and the maven-jar-plugin 0.0.8).
Don't use the maven-jar-plugin addClasspath option to build your jar when you have JavaFX component dependencies. The JavaFX components are not designed to be run from the classpath.

NetBeans 12.6, Spring Boot / Maven, Cisco AXL Schema - Background scanning of projects

Often related to Background scanning of projects people complain that this happens when NetBeans is started.
I have a Spring Boot 2.6.x with Maven 3.8.2 project, using Cisco AXL Schema 12.5.
With Apache CXF from this AXL Schema a lot of Java source code files are generated.
When I do a Clean and Build on my project afterwards immediatly the Background scanning of projects starts.
And it takes most of the times recently quite long.
I see for example that it scans also
netbeans-12.6/webcommon/jsstubs/corestubs.zip
Why should it scan this too when building my project?
But most of the time, although it shows 100% scanning done, it spends in the folder where the generated Java source code files are
<project folder>/target/generated/cxf
There are 2282 generated Java source code files.
I'm not sure if NetBeans hangs or really scans these files, it shows 100% scanning so it should be done.
Often it takes too long so I have to terminate NetBeans from the console. After a restart of NetBeans the Background scanning for projects starts and takes much shorter time, but this is annoying.
What can I do about it?
When I start NetBeans from console I do only ./netbeans. Is there a difference if starting NetBeans with sudo ./netbeans?
Here is how my project folder/file structure looks like, maybe I don't use correctly:
First of all I extracted the AXL Schema next to my src folder
<project folder>
-> schema
-> 12.5
AXLAPI.wsdl
AXLEnums.xsd
AXLSoap.xsd
-> src
-> main/...
-> test/...
In pom.xml I use
...
<build>
...
<plugin>
<groupId>org.apache.cxf</groupId>
<artifactId>cxf-codegen-plugin</artifactId>
<version>3.4.5</version>
<executions>
<execution>
<id>generate-sources</id>
<phase>generate-sources</phase>
<configuration>
<sourceRoot>${project.build.directory}/generated/cxf</sourceRoot>
<wsdlOptions>
<wsdlOption>
<wsdl>${basedir}/schema/12.5/AXLAPI.wsdl</wsdl>
<wsdlLocation>classpath:schema/12.5/AXLAPI.wsdl</wsdlLocation>
<extraargs></extraargs>
</wsdlOption>
</wsdlOptions>
</configuration>
<goals>
<goal>wsdl2java</goal>
</goals>
</execution>
</executions>
</plugin>
...
<resources>
...
<resource>
<directory>./</directory>
<includes>
<include>schema/**</include>
</includes>
</resource>
<resource>
<directory>target/generated/cxf</directory>
<includes>
<include>**/*.java</include>
</includes>
</resource>
...
</resources>
</build>
...
Maybe this pom.xml setup is not correct, and that's why the Background scanning for projects works wrongly.
When I look into the resulting war file after build, I see
WEB-INF
-> classes
-> com/cisco/axl/api/_12
-> schema/12.5
and there are artifacts which might not belong there.
For example in com/cisco/axl/api/_12 there are not only the class files but all related generated Java source code files (all 2282).
And perhap schema/12.5 shouldn't be in the war file too.
I tried this pom:
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="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 https://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>com.example</groupId>
<artifactId>cxf</artifactId>
<version>1.0-SNAPSHOT</version>
<properties>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
<maven.compiler.source>17</maven.compiler.source>
<maven.compiler.target>17</maven.compiler.target>
</properties>
<build>
<plugins>
<plugin>
<groupId>org.apache.cxf</groupId>
<artifactId>cxf-codegen-plugin</artifactId>
<version>3.4.5</version>
<executions>
<execution>
<id>generate-sources</id>
<phase>generate-sources</phase>
<configuration>
<wsdlOptions>
<wsdlOption>
<wsdl>src/main/resources/wsdl/CustomerService.wsdl</wsdl>
</wsdlOption>
</wsdlOptions>
</configuration>
<goals>
<goal>wsdl2java</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
<dependencies>
<dependency>
<groupId>javax</groupId>
<artifactId>javaee-api</artifactId>
<version>7.0</version>
</dependency>
</dependencies>
</project>
(Latest cxf-codegen-plugin, no additional config, wsdl file from here, java ee dependencies)
Running mvn clean install ("Clean and Build Project"...takes less than 5 seconds with this wsdl), and gets us:
..this nice picture (resolution of generated sources! grouped by provider (cxf)...we could have more).
Conclusion
Netbeans is mature regarding "generated sources". (As long as they are in target/generated-sources/<provider>;).
With "generated projects" (maven/gradle e.g. openapi-plugin) on the other hand, I experienced (netbeans) issues...and had to externalize/"source control" the "generated stuff" (/project!).
Don'ts
build>resources>resource>directory>. This will(try to) package your project root (additionally) to target/classes!! (This may confuse any IDE.)
...>resource>directory>target, for similar reasons esp. in Netbeans.
Hints
When we want the schemas & definitons to reside in (packaged) class path, we place them within src/main/resources. Otherwise: outside.
We add <resources/> to our <build/>, only when we decided so/know what we do/don't create "circles" (with existing maven-defaults), notto "trick netbeans"! (this is out-dated;)
Update:
I updated same project with this wsdl (axl-demo/schema).
It generated 1647 classes.
Netbeans took a while to scan:
I increased memory:
{nb_home}/etc/netbeans.conf:
netbeans_default_options="-J-Xmx4g ..."
(thx to: How to assign more memory to Netbeans? , ...)
(Restarted netbeans,) drank coffee
But then (once scan was completed): Still "nice picture", we can import/declare/use the generated classes:
Some Tweaks
..Yoda added to the build:
moved cxf-execution to profile:
<profiles>
<profile>
<id>gen</id>
<build>
<plugins>
<plugin>
<groupId>org.apache.cxf</groupId>
<artifactId>cxf-codegen-plugin</artifactId>
...
to activate it (only) with mvn install -Pgen (or in netbeans (Project>Properties>Run>) Configuration(drop-down)).
applied this: How to protect auto-generated sources during clean package in maven? like:
<build>
<plugins>
<plugin>
<artifactId>maven-clean-plugin</artifactId>
<version>3.1.0</version>
<configuration>
<excludeDefaultDirectories>true</excludeDefaultDirectories>
<filesets>
<fileset>
<directory>${project.build.directory}</directory>
<excludes>
<exclude>generated-sources/**</exclude>
<exclude>classes/com/cisco/**</exclude>
</excludes>
</fileset>
</filesets>
</configuration>
</plugin>
</plugins>
</build>
I don't agree with "recommended solution"! For "thousands of" classes that b/rarely change, who wants to clean & re-generate them "hundreds" times/day?
Which accelerates us from (mvn -Pgen clean install):
------------------------------------------------------------------------
BUILD SUCCESS
------------------------------------------------------------------------
Total time: 44.515 s
To "Project>Clean and Build" (mvn clean install):
------------------------------------------------------------------------
BUILD SUCCESS
------------------------------------------------------------------------
Total time: 4.494 s

Groovy and Maven: Stuck in compiling and testing a very simple

I am stuck trying to compile and test a extremely simple project. It's a beginner project in order to understand how all of this works, and I am currently stucked.
My main objective is to understand how to handle resources files that are located outside of the standard folder structure.
I have a main class, with two methods. One load a resource file which is on the standard folder structure (src\main\resources). Another one load a resource which is in a custom folder, outside of the standard structure (resources).
There is one junit file that simply verify that the resource is correctly loaded.
It works fine with IntelliJ. I simply declared the resources folder as resources folders and that's it.
Now with maven ..... actually I can't even compile with gmaven-plus. Nor run the test. So I did not even bother to declare the custom folder as a resource in the pom.xml file.
I based my pom.xml file based on an existing pom we have at work and from stuff I read on the web. There's no way I can make it work.
Here is a link to a 7zip file with my project, if one could put me on the right track, I would be grateful.
https://www.dropbox.com/s/jvn32ll5xfvjfwd/GroovyExample.7z?dl=0
Here is the pom:
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="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">
<modelVersion>4.0.0</modelVersion>
<groupId>groupId</groupId>
<artifactId>Example</artifactId>
<version>1.0-SNAPSHOT</version>
<dependencies>
<dependency>
<groupId>org.codehaus.groovy</groupId>
<artifactId>groovy-all</artifactId>
<version>2.4.13</version>
<type>pom</type>
</dependency>
<dependency>
<groupId>org.junit.jupiter</groupId>
<artifactId>junit-jupiter</artifactId>
<version>5.4.0</version>
<scope>test</scope>
</dependency>
</dependencies>
<build>
<plugins>
<plugin>
<groupId>org.codehaus.gmavenplus</groupId>
<artifactId>gmavenplus-plugin</artifactId>
<version>1.8.1</version>
<executions>
<execution>
<goals>
<goal>compile</goal>
<goal>compileTests</goal>
</goals>
<configuration>
<sources>
<source>
<directory>src/main/groovy</directory>
<includes>
<include>**/*.groovy</include>
</includes>
</source>
</sources>
<testSources>
<testSource>
<directory>src/test/groovy</directory>
<includes>
<include>**/*.groovy</include>
</includes>
</testSource>
</testSources>
</configuration>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>3.0.0-M1</version>
<configuration>
<failIfNoTests>true</failIfNoTests>
<testSourceDirectory>str/test/</testSourceDirectory>
<includes>
<include>**/*Test*.*</include>
</includes>
</configuration>
</plugin>
</plugins>
</build>
</project>
Here is the output:
Unable to get Groovy version from InvokerHelper or GroovySystem,
trying jar name.
Failed to execute goal
org.codehaus.gmavenplus:gmavenplus-plugin:1.8.1:compile (default) on
project Example: Execution default of goal
org.codehaus.gmavenplus:gmavenplus-plugin:1.8.1:compile failed.
The 2.4 groovy-all POMs do not include Groovy as a dependency, because they are a POM for an uber-jar, rather than a POM that describes all the Groovy module jars. Because of this, GMavenPlus is unable to find the Groovy jar to use for compilation. The <type>pom</type> works for Groovy 2.5, and 3.0, but not 2.4. So for your use case, simply delete the <type>pom</type> (or replace it with the default of <type>jar</type>). This was the way Groovy was often included back before 2.5, so the groovy-all POMs of 2.5 and 3.0 were added to ease the transition. See https://groovy-lang.org/releasenotes/groovy-2.5.html#Groovy2.5releasenotes-Packaging.

Which dependencies do I have to include in a Maven Apache Storm Project?

I am pretty new to Apache Storm and Maven projects, so I tried to follow this "tutorial" (which from my point of view is not a tutorial at all):
http://storm.apache.org/releases/current/Creating-a-new-Storm-project.html
There is a huge pom.xml referenced (https://github.com/apache/storm/blob/v1.1.1/examples/storm-starter/pom.xml) which shall be used as basis for a new project. I tried to figure out what to copy into my project pom.xml. So I decided to start with the apache core dependency first. My pom.xml looks like this:
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="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">
<modelVersion>4.0.0</modelVersion>
<groupId>groupId</groupId>
<artifactId>StormTest</artifactId>
<version>1.0-SNAPSHOT</version>
<packaging>jar</packaging>
<properties>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
</properties>
<dependencies>
<dependency>
<groupId>org.apache.storm</groupId>
<artifactId>storm-core</artifactId>
<version>1.1.1</version>
</dependency>
</dependencies>
<build>
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>exec-maven-plugin</artifactId>
<version>1.5.0</version>
<executions>
<execution>
<goals>
<goal>exec</goal>
</goals>
</execution>
</executions>
<configuration>
<executable>java</executable>
<includeProjectDependencies>true</includeProjectDependencies>
<includePluginDependencies>false</includePluginDependencies>
<classpathScope>compile</classpathScope>
<mainClass>${storm.topology}</mainClass>
<cleanupDaemonThreads>false</cleanupDaemonThreads>
</configuration>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.3</version>
<configuration>
<source>1.8</source>
<target>1.8</target>
</configuration>
</plugin>
<plugin>
<artifactId>maven-assembly-plugin</artifactId>
<version>3.1.0</version>
<configuration>
<descriptorRefs>
<descriptorRef>jar-with-dependencies</descriptorRef>
</descriptorRefs>
<appendAssemblyId>false</appendAssemblyId>
<finalName>StormTest-1.0-SNAPSHOT_dep</finalName>
<archive>
<manifest>
<mainClass>de.arphi.bi.WordCountTopology</mainClass>
</manifest>
</archive>
</configuration>
<executions>
<execution>
<phase>package</phase>
<goals>
<goal>single</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
<resources>
<resource>
<directory>${basedir}/resources</directory>
<filtering>false</filtering>
<includes>
<include>log4j2.xml</include>
</includes>
</resource>
</resources>
</build>
</project>
This even works when it is about runing maven and building / packaging a jar. The outcome are two jar files (a small one without dependencies and a bigger one with dependencies). I cannot run the smaller one because it says "main manifest not found". But I can run the bigger one by executing the following command:
storm -jar StormTest-1.0-SNAPSHOT_dep.jar
Actually the runs on my locally installed apache storm 1.1.1 (I have some System.out.printlns ...) but I get an exception:
2018-01-02 21:38:31,864 main ERROR Unable to create file C:\Users\Artur\Desktop\Bi\apache-storm-1.1.1\logs/access-web-${sys:daemon.name}.log java.io.IOException: Die Syntax für den Dateinamen, Verzeichnisnamen oder die Datenträgerbezeichnung ist falsch
at java.io.WinNTFileSystem.canonicalizeWithPrefix0(Native Method)
at java.io.WinNTFileSystem.canonicalizeWithPrefix(WinNTFileSystem.java:451)
at java.io.WinNTFileSystem.canonicalize(WinNTFileSystem.java:422)
at java.io.File.getCanonicalPath(File.java:618)
at java.io.File.getCanonicalFile(File.java:643)
at org.apache.logging.log4j.core.util.FileUtils.makeParentDirs(FileUtils.java:134)
at org.apache.logging.log4j.core.appender.rolling.RollingFileManager$RollingFileManagerFactory.createManager(RollingFileManager.java:573)
at org.apache.logging.log4j.core.appender.rolling.RollingFileManager$RollingFileManagerFactory.createManager(RollingFileManager.java:554)
at org.apache.logging.log4j.core.appender.AbstractManager.getManager(AbstractManager.java:112)
at org.apache.logging.log4j.core.appender.OutputStreamManager.getManager(OutputStreamManager.java:114)
at org.apache.logging.log4j.core.appender.rolling.RollingFileManager.getFileManager(RollingFileManager.java:155)
at org.apache.logging.log4j.core.appender.RollingFileAppender$Builder.build(RollingFileAppender.java:131) at org.apache.logging.log4j.core.appender.RollingFileAppender$Builder.build(RollingFileAppender.java:60)
at org.apache.logging.log4j.core.config.plugins.util.PluginBuilder.build(PluginBuilder.java:122)
at org.apache.logging.log4j.core.config.AbstractConfiguration.createPluginObject(AbstractConfiguration.java:952)
at org.apache.logging.log4j.core.config.AbstractConfiguration.createConfiguration(AbstractConfiguration.java:892)
at org.apache.logging.log4j.core.config.AbstractConfiguration.createConfiguration(AbstractConfiguration.java:884)
at org.apache.logging.log4j.core.config.AbstractConfiguration.doConfigure(AbstractConfiguration.java:508) at org.apache.logging.log4j.core.config.AbstractConfiguration.initialize(AbstractConfiguration.java:232)
at org.apache.logging.log4j.core.config.AbstractConfiguration.start(AbstractConfiguration.java:244)
at org.apache.logging.log4j.core.LoggerContext.setConfiguration(LoggerContext.java:545)
at org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:617)
at org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:634)
at org.apache.logging.log4j.core.LoggerContext.start(LoggerContext.java:229)
at org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:152)
at org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:45)
at org.apache.logging.log4j.LogManager.getContext(LogManager.java:194)
at org.apache.logging.log4j.spi.AbstractLoggerAdapter.getContext(AbstractLoggerAdapter.java:122)
at org.apache.logging.slf4j.Log4jLoggerFactory.getContext(Log4jLoggerFactory.java:43)
at org.apache.logging.log4j.spi.AbstractLoggerAdapter.getLogger(AbstractLoggerAdapter.java:46)
at org.apache.logging.slf4j.Log4jLoggerFactory.getLogger(Log4jLoggerFactory.java:29)
at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:358)
at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:383)
at org.apache.storm.topology.BasicBoltExecutor.<clinit>(BasicBoltExecutor.java:28)
at org.apache.storm.topology.TopologyBuilder.setBolt(TopologyBuilder.java:215)
at de.arphi.bi.WordCountTopology.main(WordCountTopology.java:22)
It says something about the syntax for creating a directory is wrong. And I know that it is about logging. I played arroung with different other dependencies (log4j, slf4j) and tried ecen to exclude dependecies without any success. I cannot get rid of this error.
Any ideas? I think that I am missing a dependency or that I have to exclude some parts of my pom.xml. But since I am not an Maven expert it is really hard for me to figure out what I have to adapt here.
I agree that storm-starter has gotten pretty big, and we should maybe have more of a minimal example.
First you should set the storm-core dependency to "provided" scope. When you deploy the topology to Storm, your jar will use the storm-core jar present in the Storm installation, so you shouldn't also put it in your fat jar.
<dependency>
<groupId>org.apache.storm</groupId>
<artifactId>storm-core</artifactId>
<version>1.1.1</version>
<scope>provided</scope>
</dependency>
When your topology runs on Storm, it will use the Log4j2 configuration in the log4j2/worker.xml file in your Storm installation. You shouldn't include your own log4j2.xml. If you need to set specific log levels, you can either modify worker.xml or use the CLI as described at http://storm.apache.org/releases/1.1.1/dynamic-log-level-settings.html.
Other than that your pom looks fine. I don't know why you have exec-maven-plugin in there (Edit: I see it's also in storm-starter, I think it's a leftover from when it was possible to run storm-starter in local mode. You shouldn't need it), and I might replace maven-assembly-plugin with the shade plugin, but I'd expect your topology to work regardless.
Thank Stig Rohde Døssing. Finally I found the origin for my exception base on your hint regarding the log4j2/worker.xml. The issue was not in the worker.xml, but in the cluster.xml which is located in the same directory.
When reading my Exception shown here, you can see that Java complains about creating a system path ("access-web-${sys:daemon.name}.log"). I found the placeholder sys:daemon.name in the cluster.xml and replaced it with something static like "access-web-mysysdaemonname.log". That fixed the issue. I have no idea why this placeholder could not be resolved by the system while there was no trouble with other placeholders.
Thanks for the hints. Topic can be closed.

Generating OSGi bundles distribution with maven-assembly-plugin

I have a multi-module project, where each module is packaged as an OSGi bundle using the Apache Felix maven-bundle-plugin. The whole project is built using a parent POM that lists the above-mentioned modules. Some modules contain configuration resources (e.g. .properties files) that should not be jarred inside the bundles for deployment but rather externalized in a dedicated config folder. My goal is to create a distribution folder (possibly, a zip file) that would look something like this:
my-app-distribution
/bundles
module1-bundle.jar
module2-bundle.jar
etc.
/conf
external1.properties
external2.properties
etc.
where the properties files under the /conf directory are hand-picked files from the individual modules' /target folders. The reason the .properties files need to be picked up from the target folders vs. the src folders is that I am using Maven resource filtering, and the source property files contain ${..} placeholders for environment-specific values. Those placeholders are properly resolved during the build process - per build profiles - and the target/ folders contain actual environment-specific values.
I've done such distribution file manipulations many times - for distributions with executable JARs, etc. In this case I wanted to use the "moduleSets" configuration of the assembly descriptor - it is easy to pull all binaries/jars into a single distribution folder using moduleSet/binary descriptor. It is also easy to exclude certain files from being packaged into an OSGi bundle - in the maven-bundle-plugin. The only issue I am stuck with is creating the /conf distribution folder and collecting the necessary properties files there. I have tried to use "fileSets" inside the "moduleSet/sources" descriptor to include only specific files from **/target of each module, but that didn't seem to work.
Anyone have a suggestion/advice? There's got to be an easy way. Or should I not use at all?
Thanks,
CV
#PetrKozelka I am not sure that extracting configuration files specific to different bundles into a separate module is a good idea. The whole point of OSGi is for bundles to be independent and potentially reusable - both in development and distributions. It only makes sense that - in the source code - the functionality implementation and related configuration files are grouped together. For a particular distribution though I might need to extract some of the files - if there is a requirement for admins to have control of certain parameters. That may be different for a different distribution/application. The assembly configuration may change, but the bundles/sources would stay the same. Also, each bundle may potentially be developed and used separately, not all bundles have to always be part of the same uber project - as you seem to assume. What you are suggesting seems to fall into the same old category of packaging enterprise applications by the type of artifacts (e.g. "model", "services", "dataaccess", "config" etc.), not by functional domain/features. Such approach works ok within a single application/project, but fails on the enterprise level where there is often a need to reuse subsets of vertical components (split by functional domains).
To your point of being dependent on the file layout in the modules, I agree that there should be no such dependency. Files could be hand-picked by their explicit name or naming convention - per very specific distro requirements. (Which is exactly the case I am facing.)
I have actually figured out how to do it more or less elegantly. Posting the solution below in case someone else is looking to solve a similar problem.
SUMMARY
I am using the maven-assembly-plugin to extract the binaries (bundle JARs) from the individual modules and package them in the <my-distribution-folder>/bundles directory. In each module where some resource files should be externalized, I consolidate such files under the /src/main/resources/external directory, and use maven-resources-plugin to copy those resources during the packaging phase to the auto-generated directory in my dedicated distribution module that contains the assembly.xml descriptor file and is also built as part of the top project. I use maven-clean-plugin in the parent POM to clear the contents of the distribution staging directory during the CLEAN phase of the top-level project build.
MAVEN CONFIGURATION
Inside each bundle's module POM that contains resources that need to be externalized I add the following resource management configuration:
<build>
<defaultGoal>install</defaultGoal>
<!--
enable resource filtering for resolving ${...} placeholders with environment-specific values
exclude any files that must be externalized
-->
<resources>
<resource>
<directory>src/main/resources</directory>
<filtering>true</filtering>
<excludes>
<exclude>external/*.*</exclude>
</excludes>
</resource>
</resources>
...
<plugins>
<!-- Copies contents of resources/external to dedicated folder defined by property in parent -->
<!-- externalized resources will be packaged according to assembly instructions -->
<plugin>
<artifactId>maven-resources-plugin</artifactId>
<version>2.6</version>
<executions>
<execution>
<id>copy-resources</id>
<phase>package</phase>
<goals>
<goal>copy-resources</goal>
</goals>
<configuration>
<outputDirectory>
${project.parent.basedir}/${externalizableResourcesStageDir}
</outputDirectory>
<resources>
<resource>
<directory>src/main/resources/external</directory>
<filtering>true</filtering>
</resource>
</resources>
</configuration>
</execution>
</executions>
</plugin>
<!-- builds a JAR file for this bundle -->
<plugin>
<groupId>org.apache.felix</groupId>
<artifactId>maven-bundle-plugin</artifactId>
<extensions>true</extensions>
<configuration>
<instructions>
<Bundle-SymbolicName>${project.groupId}.${project.artifactId}</Bundle-SymbolicName>
<Import-Package>*</Import-Package>
<Export-Package>
${project.groupId}.thismodulepackage*;version=${project.version}
</Export-Package>
</instructions>
</configuration>
</plugin>
</plugins>
</build>
where externalizableResourcesStageDir is a property defined in the top/parent POM. In the project, I include a special distribution module with the following structure:
distribution
/ext-resources (target auto-generated dir for external resources from modules)
/src
/assemble
assembly.xml (assembly descriptor)
The assembly.xml file looks like this:
<assembly xmlns="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.2"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.2
http://maven.apache.org/xsd/assembly-1.1.2.xsd">
<id>bin</id>
<!-- generate a ZIP distribution -->
<formats>
<format>zip</format>
</formats>
<includeBaseDirectory>false</includeBaseDirectory>
<baseDirectory>/</baseDirectory>
<moduleSets>
<moduleSet>
<!-- Enable access to all projects in the current multi-module build -->
<useAllReactorProjects>true</useAllReactorProjects>
<!-- select projects to include-->
<includes>
<include>myGroupId:myModuleArtifactId1</include>
<include>myGroupId:myModuleArtifactId2</include>
...
</includes>
<!-- place bundle jars under /bundles folder in dist directory -->
<binaries>
<outputDirectory>${artifactId}/bundles</outputDirectory>
<unpack>false</unpack>
</binaries>
</moduleSet>
</moduleSets>
<!-- now take files from ext-resources in this module and place them into dist /conf subfolder-->
<fileSets>
<fileSet>
<directory>ext-resources</directory>
<outputDirectory>${artifactId}/conf/</outputDirectory>
<includes>
<include>*</include>
</includes>
</fileSet>
</fileSets>
</assembly>
The distribution module's POM would look like this:
<project xmlns="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">
<modelVersion>4.0.0</modelVersion>
<parent>
<groupId>myGroupId</groupId>
<artifactId>parentArtifactId</artifactId>
<version>...</version>
</parent>
<groupId>myGroupId</groupId>
<artifactId>distribution</artifactId>
<version>...</version>
<packaging>pom</packaging>
<name>Distribution</name>
<description>This module creates the <MyProject> Distribution Assembly</description>
<url>http:...</url>
<!-- NOTE: These dependency declarations are only required to sort this project to the
end of the line in the multi-module build.
-->
<dependencies>
<dependency>
<groupId>myGroupId</groupId>
<artifactId>myModuleArtifactId1</artifactId>
<version>${project.version}</version>
</dependency>
...
</dependencies>
<build>
<plugins>
<plugin>
<artifactId>maven-assembly-plugin</artifactId>
<executions>
<execution>
<id>dist-assembly</id>
<phase>package</phase>
<goals>
<goal>single</goal>
</goals>
<configuration>
<descriptors>
<descriptor>src/assemble/assembly.xml</descriptor>
</descriptors>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
</project>
The parent POM would list all the bundle modules, plus the distribution module and also define the assembly plugin:
<project xmlns="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/maven-v4_0_0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>myGroupId</groupId>
<artifactId>myParentId</artifactId>
<version>...</version>
<packaging>pom</packaging>
<properties>
...
<!-- directory where build may place any sub-modules' resources that should be externalized -->
<!-- those resources may be picked up by maven-assembly-plugin and packaged properly for distribution -->
<externalizableResourcesStageDir>
esb-distribution/ext-resources
</externalizableResourcesStageDir>
</properties>
<!-- all project modules (OSGi bundles + distribution) -->
<modules>
<module>bundle-module1</module>
<module>bundle-module2</module>
...
<module>distribution</module>
</modules>
<dependencyManagement>
<dependencies>
...
</dependencies>
</dependencyManagement>
<build>
<pluginManagement>
<plugins>
<!--
Cleans contents of the folder where the externalized resources will be consolidated
Each module adds its own external files to the distribution directory during its own build
-->
<plugin>
<artifactId>maven-clean-plugin</artifactId>
<version>2.5</version>
<executions>
<execution>
<id>clean-ext-resources</id>
<phase>clean</phase>
</execution>
</executions>
<configuration>
<filesets>
<fileset>
<directory>${externalizableResourcesStageDir}</directory>
<includes>
<include>*.*</include>
</includes>
<followSymlinks>false</followSymlinks>
</fileset>
</filesets>
</configuration>
</plugin>
<plugin>
<artifactId>maven-assembly-plugin</artifactId>
<version>2.3</version>
<configuration>
<descriptors>
<descriptor>src/assemble/assembly.xml</descriptor>
</descriptors>
</configuration>
</plugin>
</plugins>
</pluginManagement>
</build>
</project>
NOTE: We've also made sure that the externalized resource files are excluded from being packaged inside the individual bundle JARs (see the resources section of the module POM.) The resulting unzipped distribution will look like this:
my-app-distribution
/bundles
module1-bundle.jar
module2-bundle.jar
etc.
/conf
external1.properties
external2.properties
etc.

Resources