We Keep Coding

MaVeN build takes, most of the times, wrong file

I use the org.apache.maven.plugins maven-assembly-plugin version 2.2-beta-5 to build a jar-with-dependencies. One of the jars I include contains a persistence.xml file. The project that I build also has a persistence.xml file. The build finishes well.
The problem however is that most of the times the wrong persistence.xml file ends up in the jar-with-dependencies. If I, without changing anything, rebuild (and sometimes a few more times) then the correct persistence.xml is present.
I searched for a solution but I could not find a working example. How can I define in my pom.xml that I want my project's persistence.xml file in the jar-with-dependencies and not the one from the included jar?
My MaVeN version is Apache Maven 3.6.3 and all builds are done with mvn clean package.

Use maven-shade-plugin instead of mavenassembly-plugin to exclude the persistence.xml file from your dependencies
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-shade-plugin</artifactId>
<version>2.3</version>
<executions>
<execution>
<phase>package</phase>
<goals>
<goal>shade</goal>
</goals>
<configuration>
<filters>
<filter>
<artifact>my:other:jar</artifact>
<excludes>
<exclude>persistence.xml</exclude>
</excludes>
</filter>
</filters>
</configuration>
</execution>
</executions>
</plugin>
More info on this approach in the Apache Maven Shade Plugin documentation

Cannot comment about time taken to build the executable without looking into your project.
By default Maven copies files from your ${project.basedir}/src/main/resources location to the executable jar file. So If persistence.xml is not being included in fat jar then check your folder structure and check the location of your xml file.

maven-javadoc-plugin: How to update the module path dynamically

I have a Java (11.0.7) Maven (3.0.6) multi-module project that contains the following module declarations:
<modules>
<module>jdrum-commons</module>
<module>jdrum-datastore-base</module>
<module>jdrum-datastore-simple</module>
<module>jdrum</module>
</modules>
Each of these Maven modules contains a module-info that defines the necessary requirements and exports to restrict access and visibility.
As such, jdrum-datastore-simple has some test utility classes that I reuse in jdrum's tests. By configuring the surefire plugin in jdrum's config via the code snippet below I am able to package the whole project without any issues.
<build>
<plugins>
<plugin>
<artifactId>maven-surefire-plugin</artifactId>
<configuration>
<argLine>
<!-- Allow the unnamed module access to the tests at test-time -->
--add-opens jdrum/at.rovo.drum.impl=ALL-UNNAMED
--illegal-access=deny
</argLine>
</configuration>
</plugin>
</plugins>
</build>
Within the parents POM I've also configured the generation of a report via the site argument, which also generates the Javadoc of the respective projects. The configuration for the JAR containing the javadoc as well as the configuration for the Javadoc generation as part of the report are both the same and look like this:
<!-- Generate Javadoc while reporting -->
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-javadoc-plugin</artifactId>
<version>3.2.0</version>
<inherited>true</inherited>
<configuration>
<verbose>true</verbose>
<source>${maven.compiler.source}</source>
<show>protected</show>
<failOnWarnings>false</failOnWarnings>
<release>${maven.compiler.release}</release>
<stylesheet>java</stylesheet>
</configuration>
<reportSets>
<reportSet>
<id>html</id>
<reports>
<report>javadoc</report>
</reports>
</reportSet>
</reportSets>
</plugin>
The Javadoc generation as part of the package step, which generates the project-version-javadoc.jar as output, succeeds as both, the jdrum-datastore-simple dependencies as well as its tests, are only included at test time:
<!-- Test data store to use for testing -->
<dependency>
<groupId>at.rovo</groupId>
<artifactId>jdrum-datastore-simple</artifactId>
<version>${project.parent.version}</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>at.rovo</groupId>
<artifactId>jdrum-datastore-simple</artifactId>
<version>${project.parent.version}</version>
<scope>test</scope>
<type>test-jar</type>
</dependency>
If I'd change the scope from test to compile or provided the Javadoc generation would also fail with an error such as
Exit code: 1 - javadoc: error - The code being documented uses packages in the unnamed module, but the packages defined in https://github.com/RovoMe/JDrum/jdrum-datastore-simple/apidocs/ are in named modules.
The issue here, as far as I understood the problem, is, that the jdrum-datastore-simple module is not added to the module path of Javadoc. The next logical step was therefore to add that module to the configuration as such:
<reporting>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-javadoc-plugin</artifactId>
<configuration>
<additionalOptions>
<option>--add-modules</option>
<option>jdrum.datastore.simple</option>
</additionalOptions>
</configuration>
</plugin>
</plugins>
</reporting>
This adds the jdrum-datastore-simple module to the Javadoc configuration string, which can be seen in the jdrum/target/site/apidocs/options file that now contains an
...
--add-modules
jdrum.datastore.simple
...
entry. On further analyzing the generated options file it is apparent that the module path is missing out a reference to the actual JAR file and hence the Javadoc generation and thus the Maven process fails due to Javadoc not being able to locate the defined module. If I update that options file and add the path to the missing JAR file and then only perform a mvn package site the whole process succeeds and all is fine (as the pure invocation of the javadoc.bat located in the target/site/apidocs folder would as well).
Now, in order to make the whole process more dynamic I wanted to add or update the module path. However, the maven-javadoc-plugin does not directly allow this. Therefore I came up with adding a further maven-javadoc-plugin option of --module-path and a further option entry that contains the whole path. By the whole path I mean the path to every single dependency, so not only the path to jdrum-datastore-simple. This also works but due to hardcoding the path to the respective JAR files, the project is now not usable by other users unless they have the same system and path structure I used. To fix this I quickly replaced the respective path structure with ${settings.localRepository} and ${project.parent.basedir} properties on the respective modules in the module path. Unfortunately Javadoc is rather nitpicking on the path structure it accepts and it turns out that on my Windows machine Maven does return a path structure starting with C:\Users\... which Javadoc can't handle. If the path structure looks like C:/Users/... however Javadoc is fine with the values.
On further research I stumbled upon this thread which suggests to use Maven's build-helper-maven-plugin to define new properties for i.e. the M2 repository and use the built-in reg-ex capability to replace \ characters with /. However, adding a configuration such as
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>build-helper-maven-plugin</artifactId>
<version>3.1.0</version>
<executions>
<execution>
<id>replace-local-repo-characters</id>
<goals>
<goal>regex-property</goal>
</goals>
<configuration>
<name>tag.m2repo</name>
<value>${settings.localRepository}</value>
<regex>\\</regex>
<replacement>/</replacement>
<failIfNoMatch>false</failIfNoMatch>
</configuration>
</execution>
<execution>
<id>replace-local-path-characters</id>
<goals>
<goal>regex-property</goal>
</goals>
<configuration>
<name>tag.basedir</name>
<value>${project.parent.basedir}</value>
<regex>\\</regex>
<replacement>/</replacement>
<failIfNoMatch>false</failIfNoMatch>
</configuration>
</execution>
</executions>
</plugin>
and using the introduced tags instead does not work at all as Maven is complaining about an invalid value provided. If I use $\{settings.localRepository} Maven is fine about the provided value, however in the final options file not the value of the actual settings.localRepository is updated but the provided string itself and I end up with something like $/{settings.localRepository}/org/slf4j/... which Javadoc can't resolve and therefore still misses out on the correct location to the jdrum-datastore-simple dependency.
So, how can I add the path to the missing dependency to maven-javadoc-plugin's module path defined in the generated options file so that the Maven is actually able to generate the whole report?

It seems that with java11 Update 9 (maybe also with update 8; not tested) maven-javadoc-plugin is able to correctly generate the Javadoc for multi-module projects without the need to alter the module-path.
For those interested how the actual Maven POM looks like:
Parent POM
POM for a shared module
POM for a sharing and consuming module
POM for the consuming module

Load external properties file in a Gradle project which could be used in build files as well as the multi project application

I am currently migrating a Maven project to Gradle and we use the below maven plugin to read an external properties files in Maven project
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>properties-maven-plugin</artifactId>
<version>1.0-alpha-2</version>
<executions>
<execution>
<phase>initialize</phase>
<goals>
<goal>read-project-properties</goal>
</goals>
<configuration>
<files>
<file>${user.home}/my_global.properties</file>
</files>
</configuration>
</execution>
</executions>
</plugin>
This plugin reads the external property file and the properties are accessible in pom.xml as well as other Java files.
I am trying to find a similar plugin for Gradle and tried various ways to include the properties file in my project, but I could only find a way to get the details in build.gradle file. Below is an excerpt of what I tried
ext.extProgram = new Properties()
extProgram.load(new FileInputStream("${System.properties['user.home']}/my_global.properties"))
project.ext['any.plugin.property']=extProgram['property.in.external.file']
I want a way in Gradle such that only reference to my external properties files can allow me to fetch it's key value pairs in build scripts and any Java file.

If you're transitioning from Maven to Gradle, then put similar properties into "~/.gradle/gradle.properties". Read the User Guide in the distro for more information.

Defining System Properties in Spring Boot Plugin

I would like to specify some system properties in my applicatio (deterined at compile time).
I am using the spring boot maven plugin to compile
Currently, according to this questions: Specify system property to Maven project
I tried the following setup (however this does not work as it is for a different plugin)
<plugins>
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
<configuration>
<mainClass>application.boot.AppStarter</mainClass>
<systemProperties>
<systemProperty>
<name>application.version</name>
<value>${application.version}</value>
</systemProperty>
<systemProperty>
<name>release.date</name>
<value>${timestamp}</value>
</systemProperty>
</systemProperties>
</configuration>
<executions>
<execution>
<goals>
<goal>repackage</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
How can i specify the properties in this plugin?

Java system properties which you add are only accessible by the process they are added to.So even if you manage to add some system properties during the Maven build, it will no longer be there when the build is done.
What will happen if you distribute your jar to someone else. How do you expect these properties to be available?
Solution
Refer this post to see how to access the artifactId and version at runtime
In a similar fashion you can add the timestamp entry as well to the src/main/resources/project.properties
buildTimestamp=${timestamp}
timestamp is not a pre-defined property like project.version or project.artifactId.So you will have to set extract the timestamp from the Maven property ${maven.build.timestamp} and set it as value to your timestamp property. This is already answered in this question.

Include the external jar files in my project

I'm developing a Java SE application with Netbeans IDE.
I added external jar files to the project.
After my project is compiled, these external jar files will be in the lib folder, next to the jar file.
I want to use jar in jar solution. So the external jar files are included in my project's runnable jar file.
Is any standard method to solve this problem? Or this is not a good solution?
Thank you!

I'm pretty sure that Java doesn't support embedded Jars. I'd recommend moving the lib out to the file system (so that it creates a sub folder ./lib within the same drctory as your executable Jar & see if that makes a difference.
If you really want to use embedded Jars, you could take a read of One-Jar
You should have a directory structure of
Example below
.\JarTest2.jar
.\lib\log4j-1.2.17.jar

You might wanna try One-JAR™; and if your project is Maven-based:
<build>
<plugins>
<!-- other plugins omitted for brevity -->
<plugin>
<groupId>org.dstovall</groupId>
<artifactId>onejar-maven-plugin</artifactId>
<version>1.4.4</version>
<executions>
<execution>
<configuration>
<attachToBuild>true</attachToBuild>
</configuration>
<goals>
<goal>one-jar</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>