I have a project where I'm trying to get protobuf to work with infinispan, quarkus and gradle. The problem is that although I'm following the instructions given in the Quarkus homepage: https://quarkus.io/guides/infinispan-client, it seems that when I'm using gradle, the marshallers are not generated and registered as they should be. To me it seems like this comes down to the org.infinispan.protostream:protostream-processor not executing when gradle is the build tool. Is this a conscious decision that only Maven is supported, or am I missing something obvious in my gradle setup?
Replications of the most simple cases can be found here: https://github.com/radiosphere/gradle-java-protobuf for gradle and here for maven: https://github.com/radiosphere/mvn-java-protobuf. These projects are extremely basic, basically trying to run a simple code on startup:
public void onStartup(#Observes StartupEvent startupEvent) {
RemoteCache<String, CounterState> cache = cacheManager.administration().getOrCreateCache("default", DefaultTemplate.DIST_SYNC);
cache.put("a", new CounterState(2L));
CounterState state = cache.get("a");
logger.infof("State: %s", state);
}
In the maven project this works, in the gradle project an exception is thrown saying that no marshaller can be found. Apart from build tool choice the projects should be identical.
The annotation processor runs in the Maven build because io.quarkus:quarkus-infinispan-client has a compile dependency on org.infinispan.protostream:protostream-processor.
Looks like Gradle made a decision to not use annotation processors found in the compile classpath:
Since implementation details matter for annotation processors, they must be declared separately on the annotation processor path. Gradle ignores annotation processors on the compile classpath.
That means you have to add an explicit annotationProcessor dependency:
annotationProcessor 'org.infinispan.protostream:protostream-processor:4.4.0.Final'
Related
I have a multi module gradle project. The project contains two subproject, i.e. a spring-boot application server and an npm front-end ui (which is just static javascript).
I can build both sub-projects. I can define:
implementation(project(':ui'))
in the dependencies section of the spring application and I get a running jar in the server projects build folder successfully serving the frontend.
However, I want to be able not to combine the two not within the server sub-project, but rather in the enclosing project.
I thought of something like:
build.gradle:
allprojects {
group = 'com.example.webapp'
version = '0.0.1-SNAPSHOT'
}
dependencies {
implementation(project(':server'))
implementation(project(':ui'))
}
settings.gradle:
rootProject.name = 'webapp'
include 'server', 'ui'
I think, I am completely wrong. Everything I find about gradle is either completely basic, or assumes way more than what I understood about it so far.
EDIT:
With my solution approach I am getting the following error:
A problem occurred evaluating root project 'webapp'.
Could not find method implementation() for arguments [project ':server'] on object of type org.gradle.api.internal.artifacts.dsl.dependencies.DefaultDependencyHandler.
EDIT 2:
The basic idea is from https://ordina-jworks.github.io/architecture/2018/10/12/spring-boot-angular-gradle.html
The implementation not found is caused by the lack of plugins applied to your root project. The implementation configuration is created by the java plugins in Gradle.
What you are trying to achieve requires a good understanding of Gradle and all the magic provided by the Spring Boot plugin.
You are effectively trying to reproduce some of that integration in your root project, without the help of the plugins.
An approach that might be easier would be to migrate your application project to be the root project and then have the ui as a subproject.
I have created a custom Gradle plugin which creates a new configuration for some dependencies that I want to treat separately. Since these used to be in the compile configuration I have added the new configuration to the classpath (from the Java plugin) like so:
project.sourceSets.all { sourceSet ->
sourceSet.compileClasspath += myConfiguration
}
My configuration extends the compile configuration. My reasoning for this was that if there were any other 3rd party plugins that did "something" to the compile configuration then it would also affect my new configuration, since it is also an instance of compile.
It seems that later on another plugin, the Spring PropDeps Plugin, also modifies the classpath and the build fails with:
Failed to apply plugin [class 'org.springframework.build.gradle.propdep.PropDepsPlugin']
Cannot change dependencies of configuration ':my-project:compile' after it has been resolved.
Looking at the source code for that plugin they are doing the same steps that I am in my custom plugin to create a configuration, namely create the configuration and add it to the classpath as soon as the plugin is applied, see here.
It would seem crazy if only one plugin could add a new configuration to the classpath. What am I doing wrong here?
Note that my custom plugin is applied in the allprojects block whereas the Spring plugin is applied in the subprojects block - not sure if this matters.
Hmmm ... as I was writing the question something struck me about both extending the compile configuration and adding to the compile classpath. This seemed like I was adding a circular dependency. Low and behold, when I did not extend the configuration the build worked!
Following the documentation I decided to use optional scope for Devtools using special propdeps plugin for Gradle:
Flagging the dependency as optional is a best practice that prevents devtools from being transitively applied to other modules using your project. Gradle does not support optional dependencies out-of-the-box so you may want to have a look to the propdeps-plugin in the meantime.
What I add to my build.gradle is:
buildscript {
repositories {
maven { url 'http://repo.spring.io/plugins-release' }
}
dependencies {
classpath 'io.spring.gradle:propdeps-plugin:0.0.9.RELEASE'
}
}
apply plugin: 'propdeps'
apply plugin: 'propdeps-idea'
dependencies {
optional('org.springframework.boot:spring-boot-devtools')
}
and it does not seem to work at all.
At first, it breaks the ability to run #SpringBootApplication main method from Intellij (the problem was already described here: IntelliJ fails to start Spring Boot/Gradle application when using Spring Boot developer tools). But I can still start the app with bootRun goal so it is not a big problem if I still want to follow best practice declaring devtools as optinal.
The main problem is that it does not work for me at all. I run the app with bootRun and then execute compileJava --rerun-tasks expecting the app to be reloaded but it will not. Nothing happens. If I try to do the same with Devtools declared as runtime, then it performs quick reload without complete jvm restart.
I tried both: latest stable 1.5.7.RELEASE and the last available 2.0.0.M4.
Let me know if Devtools works for you when declared as optional in Gradle or if you know how to fix java.lang.NoClassDefFoundError when running main method from IntelliJ and optional Devtools?
While reading this gradle document, I came across this wordings saying that dependencies for each configuration. Here what does this configuration meant to be. Because I usually used to specify the dependencies in such a vague way like
dependencies {
compile 'org.springframework:spring-core:4.0.5.RELEASE',
'org.hibernate:hibernate-core:3.6.7.Final'
}
Is there any other possible way to specify the dependencies(based on configuration)?. I am little curious to know about that.
If yes, what is advantage of specifying dependencies like that. Can someone able to throw some light here?
Also how the below command will be useful?
gradle -q dependencies api:dependencies webapp:dependencies
In Gradle dependencies are grouped into configurations. Configurations have a name, a number of other properties, and they can extend each other. Many Gradle plugins add pre-defined configurations to your project.
These are the configurations added by Java plugin. As you can see, compile is a configuration, it is extended by many other configurations. You can create your own configuration:
configurations {
myConfig {
description = 'my config'
transitive = true
extendsFrom compile
}
}
Also how the below command will be useful?
This command prints the dependencies of main project and api and webapp subprojects.
I have a Maven NetBeans platform application. One of its modules is a wrapper to a java project (jar) that exposes some services to the Lookup. In the wrapped project I use the maven-processor-plugin to process the annotations so everything gets registered in the Lookup. I’m unable to see the exposed classes on the wrapped module. I tried running the maven-processor-plugin but it is skipped since there are no source files in the wrapped module. Even if there were it wouldn’t fix the problem.
You can get the code here, in the Marauroa Server Manager project, Module: jWrestling Wrapper.
The code for the wrapped module can be found here. Annotated classes within the modules work fine.
Is there a way to execute the annotation processors on the dependencies of a project? Am I missing something obvious?
the wrapped jar project cannot contain nb.org annotations. these generate META_INF/generated-layer.xml file that is only read from a MODULE jar, not the wrapped non-module jar
the binary dependency contains some netbeans-originating annotations? and you want to process it through the maven plugin? that won't work. Most if not all netbeans annotations are compile-time only, meaning that they are processed at compile time and not retained in the bytecode. so only su
Besides for Netbeans annotations (which are based on jdk 1.6 annotation processors, you don't need the processor plugin, compile plugin should be sufficient.