We will be migrating our services from thorntail to quarkus.
With thorntail, we define the scope of io.thorntail dependencies as provided in our dependency modules. In the module where the uber jar is built (war packaging), we set the default compile scope. We apply this rule because we were facing thorntail crashes during startup. We started to apply this rule from thorntail version 2018.06.
Do we need to apply the same rule with quarkus? Is this a good practice?
No. Just add the dependencies as normal compile dependencies.
Related
While I worked on a Micronaut project und tried to solve some problems, like dynamic versioning of dependencies and creating a multi module micronaut project with Gradle. I found in some code examples of the build.gradle this dependency:
annotationProcessor platform("io.micronaut:micronaut-bom:2.0.0")
But I could not find any official documentation referring to it. What does it do? Can it help me with versioning my dependencies?
The Micronaut BOM (Bill Of Material, further reading) declares all the framework dependencies of a specific Micronaut release. In your example it is the BOM of Micronaut release 2.0.0.
By declaring the as a platform dependency you don't have to worry about Micronaut about the versions of supported JARs, since they already are defined in the BOM.
For example if you decide to use the Caffeine Cache with Micronaut you simply declare it as a dependency but omit the version number.
dependencies {
implementation("io.micronaut.cache:micronaut-cache-caffeine")
}
That way you make sure that you are using well tested dependencies with your Micronaut release.
why is it an `annotationProcessor?
An update since the following question came up.
Uuh. Nice. So its a collection of dependencies with the best working versions for my specific micronaut version? Cool. And why is it a annotationProcessor?
annotationProcessor is Gradle related and is called a dependency configuration. When using the java Gradle plugin you have out of the box dependency configurations such as implementation or api.
With a dependency configuration you configure the dependencies for e.g. an annotation processor by using the configuration annotationProcessor. implementation is used for your compile time dependencies. And if you want to expose the dependencies to other modules that use your module you might want to use api instead of implementation.
I'm trying to convert a multi-module Maven project from vanilla Java EE 8 to Quarkus, and it seems that ArcAnnotationProcessor throws exceptions about unsatisfied dependencies for all injection points referencing dependencies located in a different module.
Is there any workaround, short of merging the modules?
Answering my own question:
According to the Quarkus CDI guide,
The bean archive is synthesized from:
the application,
application dependencies that contain a beans.xml descriptor or a generated Jandex index (META-INF/jandex.idx),
and Quarkus integration code.
After adding a beans.xml to each of my reactor modules, ArC no longer complains about missing dependencies.
I am making war packaging of my spring boot. made spring boot starter tomcat as provided, removed spring boot maven plugin.
But I still see tomcat jdbc and tomcat juli, to name a few (even junit, but it could be from other custom dependencies, so discounting this for this question). I am using logback, but I see log4j over slf4j from starter web.
Can I ask, how to skip unwanted jars and keep my package nice and tidy
Maven has the concept of "scope" for dependencies. You probably know the scope test which is used for unit test dependencies which should not go into the final product. Use this scope for junit.
What you need is the scope provided for the Tomcat dependencies. This tells Maven: "Don't include it; when the code is run, someone else will make sure this dependency is on the classpath".
The dependency log4j-over-slf4j is necessary when one of your dependencies still uses log4j to log. log4j-over-slf4j contains the code to redirect those calls to logback.
Now you will face the case where you can't change the scope because it's in a POM of someone else.
The correct solution here is to define the dependency with the correct scope (and version) in a dependencyManagement element in your POM. This definition will be used when any POM asks for this group+artifactId. So even when some deep dependency of Spring Boot pulls that in, your WAR will be build with the version and scope from the dependencyManagement element.
See also:
Dependency Scopes
Dependency Management
I am using Spring Boot 1.4.1 with Gradle 3.1. The module which has the Spring Boot plugin applied creates its own jar with the jar task, and also has the 'fat' jar created with bootRepackage. However, the classes from that module are in BOOT-INF/classes, but I would like them to be in a separate jar in BOOT-INF/lib. How to do this?
EDIT: I know I can move the code to a separate module, but for various reasons I can't make such a split (unless there is no other way). I am looking for a single-module solution, if one exists.
You'll need to set up a multi-project build and move all of your Jersey-related classes into a separate project. You can then depend upon this new project in your Spring Boot project using a project dependency. For example:
dependencies {
compile project(':jersey-endpoints')
}
I have a project where I use Spring Boot 1.1.2.RELEASE which uses Spring 4.1.5, and Spring HATEOAS 0.10.0.RELEASE which uses Spring 4.0.9. This causes some dependency problems like the infamous java.lang.ClassNotFoundException: org.springframework.beans.factory.SmartInitializingSingleton.
I dug into the POM of spring-hateoas and found that there are different profiles defined, one of them being spring41 which depends on Spring 4.1.5. Is it possible to select this profile in my <dependency> section, or do I have to exclude the Spring dependencies?
Automatically selecting a profile for a build isn't easy. You can enable it by default in your personal settings.xml but that breaks the build for everyone who doesn't have the same file.
You can't enable a profile in the POM of the project.
With Maven 3.3, you can add the profile to ${maven.projectBasedir}/.mvn/maven.config. Since this file is part of the project, it's easy to share. You can use the Maven Enforcer plugin to make sure everyone uses a Maven version with actually uses the file.
If you can't use 3.3, then your best bet is to exclude the dependencies. If you have a parent POM, then you can use a dependencyManagement element to do it for all POMs in the reactor build.