Quarkus uber/fat jar name: does not respect project.build.finalName in version 1.13.3.Final as doc suggests - quarkus

I find that Quarkus uber/fat jar name is not controlled by project.build.finalName in version 1.13.3.Final, but by <quarkus.package.output-name> or property quarkus.package.output-name. Is this a bug?

The fast-jar indeed does not respect this proprerty because everything it generates is put into a dedicated directory with a fixed name.
If the uber-jar is not respecting the property,then yeah that's a bug and please report

Add the following properties
quarkus.package.type=uber-jar
quarkus.package.runner-suffix=runner
quarkus.package.output-name=custom_name_jar

Related

Unable to load Multimaps when added dependency with Apache Hive

I have added dependency guava for using Multimaps and also I have added Hive dependency in my project.
I am getting the following error while compiling application.
An attempt was made to call the method com.google.common.collect.Multimaps.asMap(Lcom/google/common/collect/ListMultimap;)Ljava/util/Map; but it does not exist. Its class, com.google.common.collect.Multimaps, is available from the following locations:
jar:file:/Users/sreenivas/.m2/repository/org/apache/hive/hive-exec/1.2.1/hive-exec-1.2.1.jar!/com/google/common/collect/Multimaps.class
jar:file:/Users/sreenivas/.m2/repository/com/google/guava/guava/25.1-jre/guava-25.1-jre.jar!/com/google/common/collect/Multimaps.class
It was loaded from the following location:
file:/Users/sreenivas/.m2/repository/org/apache/hive/hive-exec/1.2.1/hive-exec-1.2.1.jar
Action:
Correct the classpath of your application so that it contains a single, compatible version of com.google.common.collect.Multimaps.
Can anyone suggest me how to take the latest version dependency.
It is caused by the package hive-exec include /com/google/common/collect/Multimaps.class, as shown in picture:
If you have to include these two jar (hive-exec-1.2.1.jar and guava-25.1-jre.jar), you'd better fix hive-exec's source code and repackage it.

Checkstyle and Maven's Standard Directory Layout

I'm following Maven's Standard Directory Layout for my project.
Is there a preferred directory to put my checkstyle.xml file? I've seen it on at least 3 possible locations:
src/main/resources/checkstyle.xml
src/main/checkstyle/checkstyle.xml - Example: Joda-Time
src/checkstyle/checkstyle.xml - Example: Spring Boot
Since this is mostly a file for developers, the first option gives me doubts. Would it make sense to include checkstyle.xml into the JAR file?
Thanks,
Fede
Putting checkstyle.xml in src directory doesn't really make sense, as it is not part of source code.
The most common convention I've observed in my projects is putting it into config/checkstyle/checkstyle.xml. Thousands of projects use it (filename:checkstyle.xml path:config/checkstyle) and Gradle uses this location by default.

How to use Afterburner.fx with Gradle instaed of Maven 3, while leaving the original project structure of afterburner.fx

afterburner.fx for JavaFX 8 is a minimalistic (3 classes) JavaFX MVP framework based on Convention over Configuration and Dependency Injection created by Adam Bien.
afterburner.fx use Maven 3.
I would like to use it with Gradle.
How to use Afterburner.fx with Gradle instaed of Maven 3, while leaving the original project structure of afterburner.fx ?
In the build.gradle File add dependencies
dependencies {
compile group: 'com.airhacks', name:'afterburner.fx', version: afterburnerfxVersion
}
In the build.gradle File add the additional Resources (.fxml , .css , .properties)
sourceSets.main.resources.srcDirs("src/main/java").includes.addAll(["**/*.fxml", "**/*.css", "**/*.properties"])
and (re-)add all the standard Resources (in the resources folder)
sourceSets.main.resources.srcDirs("src/main/resources").includes.addAll(["**/*.*"])
Update for Gradle Version 6.8.1 : if you run gradlew with --warning-mode all there is a deprecated Message:
Copying or archiving duplicate paths with the default duplicates strategy has been deprecated. This is scheduled to be removed in Gradle 7.0.
Solution
add this line:
// from https://docs.gradle.org/6.8.1/userguide/upgrading_version_5.html#implicit_duplicate_strategy_for_copy_or_archive_tasks_has_been_deprecated
// and https://docs.gradle.org/current/userguide/java_plugin.html
// Java Plugin Task processResources(type: Copy)
processResources.duplicatesStrategy = DuplicatesStrategy.INCLUDE // allow duplicates
Thanks, this helped me a lot. I added the short form of it to dependencies:
compile 'com.airhacks:afterburner.fx:1.6.0'
Additionally I added a second line to include the files from the resources folder and not only from /java. I also added **/*.png to include png files because new Image("filename.png") wasn't working anymore.
sourceSets.main.resources.srcDirs("src/main/java").includes.addAll(["**/*.fxml", "**/*.css", "**/*.properties", "**/*.png"])
sourceSets.main.resources.srcDirs("src/main/resources").includes.addAll(["**/*.fxml", "**/*.css", "**/*.properties", "**/*.png"])
I don't know why the above two lines broke the default behavior - seems like I have to add every new file type to the above lines. :/ If anyone has a better solution please tell me.

OSGi bundle build issue in Gradle

I have a simple use case of building an OSGi bundle using Gradle build tool. The build is successful if there are java files present in the build path, but it fails otherwise.
I am using 'osgi' plugin inside the gradle script and trying to build without any java files. The build always fails with following error:
Could not copy MANIFEST.MF to
I am sure there must be some way to do it in Gradle but not able to fine. Any idea what can be done to resolve this depending on your experience.
I ran into this today as well, and #Peter's fix didn't work for me (I hadn't applied the java plugin in the first place...). However, after hours of Googling I did find this thread, which helped me find the problem.
Basically, it seems that the error occurs (as Peter stated) when no class files are found in the jar - my guess is because the plugin then cannot scan the classes for package names on which to base all the Import and Export information.
My solution was to add the following to the manifest specification:
classesDir = theSourceSet.output.classesDir
classpath = theSourceSet.runtimeClasspath
In my actual build code, I loop over all source sets to create jar tasks for them, so then it looks like this:
sourceSets.each { ss ->
assemble.dependsOn task("jar${ss.name.capitalize()}", type: Jar, dependsOn: ss.getCompileTaskName('Java')) {
from ss.output
into 'classes'
manifest = osgiManifest {
classesDir = ss.output.classesDir
classpath = ss.runtimeClasspath
// Other properties, like name and symbolicName, also set based on
// the name of the source set
}
baseName = ss.name
}
}
Running with --stacktrace indicates that the osgi plugin doesn't deal correctly with the case where both the osgi and the java plugins are applied, but no Java code is present. Removing the java plugin should solve the problem.
I had the same issue also when java code was present.
Adding these two lines to the osgiManifest closure fixed the problem:
classesDir = sourceSets.main.output.classesDir
classpath = sourceSets.main.runtimeClasspath
-- erik

export all defined maven project properties to file?

I have a maven 3 project. In the POM, I define numerous <properties> - some under <project>, others under specific <profile>. is the a way in maven to export all declared properties to a .properties file?
My current way of doing so is to:
create env.properties file in src/main/resources
for each property 'myProp' add this line to env.properties: myProp=${myProp}
enable resource filtering during builds
Seems like there ought to be a way to eliminate step 2 above...
thanks,
-nikita
Use properties-maven-plugin and its write-project-properties goal.
If I understand your requirements correctly, you can do this using the antrun-plugin coupled with Ant's echoproperties task. An example of this configuration is in the StOf question here.

Resources