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.
Related
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.
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
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.
In one of our projects, we use the properties-maven-plugin's read-project-properties goal to read property values from a file which are then used for filtering resources. See this post for a discussion on the general purpose of this procedure.
We would like to override some of the values found in the file using a suitable profile defined in the developer specific settings.xml (the same way we override properties set in the POM).
This, however, does not work for the properties set by the properties-maven-plugin.
How can we achieve our goal?
As a work around, we are currently registering an additional, developer specific file with the properties-maven-plugin to achieve this effect but it would be much more convenient to use the regular way (profiles).
In more general terms, the question is: How do properties set by properties-maven-plugin's read-project-properties goal tie into the property definition precedence hierarchy of maven, which is described in this very helpful blog post.
I extracted the relevant elements of our POM into a toy project that demonstrates my issue. Here is the POM of the toy project:
<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>xxx</groupId>
<artifactId>MavenTest</artifactId>
<version>0.0.1-SNAPSHOT</version>
<name>Maven Test</name>
<description>A maven project to test filtering and the maven-properties-plugin</description>
<build>
<resources>
<resource>
<directory>src/main/resources</directory>
<filtering>true</filtering>
</resource>
</resources>
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>properties-maven-plugin</artifactId>
<executions>
<!-- Read properties from a file -->
<execution>
<id>load-filter-properties</id>
<goals>
<goal>read-project-properties</goal>
</goals>
<phase>initialize</phase>
<configuration>
<files>
<file>filters/filterTest.properties</file>
</files>
<quiet>false</quiet>
</configuration>
</execution>
<!-- The following execution is for debug purposes only -->
<execution>
<id>write-project-properties</id>
<inherited>false</inherited>
<goals>
<goal>write-project-properties</goal>
</goals>
<phase>package</phase>
<configuration>
<outputFile>filters/project.properties</outputFile>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
<dependencies>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>4.12-beta-1</version>
</dependency>
</dependencies>
</project>
I think you will find the answer here:
Modifications of project properties that happen during project lifecycle have no effect on the effective pom – it is just too late. Examples of such modifications include groovy scripts (via gmaven-plugin) and properties loaded from external files via maven-properties-plugin. So, why do we need them at all? Since they can be used by other plugins in runtime, when they are read directly from properties collection during plugin invocation.
Since the properties are read after the usual resolution they just override whatever was set in profiles.
I have a project that uses some legacy script for processing the source code. I cannot get rid of it, so I want to call it from maven.
the problem is that I need to pass as an argument the location of a jar file. I have listed this jar file as a dependency in my pom.xml. is there a way that I can pass the absolute location of the jar file to this script?
This isn't by any means ideal, but you could call your script from maven, and pass this in as a parameter:
${settings.localRepository}/<path to artifact>
where path to artifact is a path made up of the group id and artifact id you want. Example, if you wanted a reference to the maven-jar-plugin version 2.2, you'd use this:
${settings.localRepository}/org/apache/maven/plugins/maven-jar-plugin/2.2/maven-jar-plugin-2.2.jar
I like Pascal Thivent's answer to a similar question better. You can refer to dependencies with the ${maven.dependency.junit.junit.jar.path} notation. Pascal includes a sample pom in his answer:
<?xml version="1.0" encoding="UTF-8"?>
<project>
<modelVersion>4.0.0</modelVersion>
<groupId>com.stackoverflow</groupId>
<artifactId>q2359872</artifactId>
<version>1.0-SNAPSHOT</version>
<name>q2359872</name>
<properties>
<my.lib>${maven.dependency.junit.junit.jar.path}</my.lib>
</properties>
<dependencies>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>3.8.1</version>
<scope>test</scope>
</dependency>
</dependencies>
<build>
<plugins>
<plugin>
<artifactId>maven-antrun-plugin</artifactId>
<executions>
<execution>
<phase>process-resources</phase>
<configuration>
<tasks>
<echo>${my.lib}</echo>
</tasks>
</configuration>
<goals>
<goal>run</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
</project>