I'm currently working on implementing HTTP3 server using the Gradle version 7.3 on a Ubuntu 20.04 VM. But QUIC codec (0.0.20.Final) and HTTP/3 codec (0.0.11.Final) dependencies produce the following error.
Could not find netty-incubator-codec-native-quic-0.0.25.Final-${os.detected.name}-${os.detected.arch}.jar (io.netty.incubator:netty-incubator-codec-native-quic:0.0.25.Final).
Possible solution:
- Declare repository providing the artifact, see the documentation at https://docs.gradle.org/current/userguide/declaring_repositories.html
Following are the dependencies I used
implementation 'io.netty.incubator:netty-incubator-codec-quic:0.0.20.Final:linux-x86_64'
implementation 'io.netty.incubator:netty-incubator-codec-http3:0.0.11.Final'
As a temporary solution I downloaded the jar of the dependency from here and referenced it in the build.gradle file.
implementation ("io.netty.incubator:netty-incubator-codec-quic:0.0.20.Final:linux-x86_64")
implementation (files("libs/netty-incubator-codec-http3-0.0.11.Final.jar"))
Gradle is struggling to parse the classifier for the quic dependency, which is a property defined in terms of other properties, which are meant to be detected at build-time.
To work around that, exclude the quic dependency from your http3 dependency, and instead pull in quic directly:
implementation ( "io.netty.incubator:netty-incubator-codec-http3:0.0.11.Final" ) {
exclude group: "io.netty.incubator"
}
implementation "io.netty.incubator:netty-incubator-codec-native-quic:0.0.27.Final"
runtimeOnly ( group: "io.netty.incubator", name: "netty-incubator-codec-native-quic", classifier: "osx-x86_64" )
runtimeOnly ( group: "io.netty.incubator", name: "netty-incubator-codec-native-quic", classifier: "linux-x86_64" )
Related
My annotation processing has suddenly stopped working. I've made no known changes to my configuration and haven't been able to find any references to the error I'm getting.
Gradle Version: 7.5.1
QueryDSL Version: 5.0.0
build.gradle:
implementation "com.querydsl:querydsl-core:${querydslVersion}"
implementation "com.querydsl:querydsl-jpa:${querydslVersion}"
implementation "com.querydsl:querydsl-apt:${querydslVersion}"
...
annotationProcessor ("javax.annotation:javax.annotation-api:1.3.2")
annotationProcessor ("org.hibernate.javax.persistence:hibernate-jpa-2.1-api:1.0.2.Final")
annotationProcessor ("com.querydsl:querydsl-apt:${querydslVersion}")
annotationProcessor ("com.querydsl:querydsl-apt:${querydslVersion}:jpa")
Error:
* What went wrong:
Execution failed for task ':compileJava'.
> Could not resolve all files for configuration ':annotationProcessor'.
> Could not find querydsl-apt-5.0.0-jpa.jar (com.querydsl:querydsl-apt:5.0.0).
Searched in the following locations:
file:/Users/devuser/.m2/repository/com/querydsl/querydsl-apt/5.0.0/querydsl-apt-5.0.0-jpa.jar
Found a work around (9/24):
The version of querydsl-jpa is controlled by my JHipster BOM, which pulls in 5.0.0. But if I specify the 4.4.0 version in my annotation processor it works. So it seems like the behavior changed in 5.0.0, or the classifier needs to be specified in some other way. But this is how I got it to work again.
implementation group: 'com.querydsl', name:'querydsl-jpa', version:'+'
annotationProcessor group: 'com.querydsl', name: 'querydsl-apt', classifier: 'jpa', version: '4.4.0'
I have already seen in some project, that in some of them is using libs and libs group: instead of implementation or deprecated compile. After local switch to implementation everything looks fine and works correctly.
Example:
libs group: 'com.google.code.gson', name: 'gson', version: '2.8.6'
instead of
implementation group: 'com.google.code.gson', name: 'gson', version: '2.8.6'
Is there any difference between them?
libs, implementation, compile are known as dependency configurations (configurations for short) in Gradle: https://docs.gradle.org/current/userguide/declaring_dependencies.html#sec:what-are-dependency-configurations
They are essentially a "bucket" to place dependency in. The Java plugin defines quite a few configurations: https://docs.gradle.org/current/userguide/java_plugin.html#sec:java_plugin_and_dependency_management
The libs configuration you mentioned is not part of any standard/provided Gradle plugin. So, it is provided/created by some other plugin you have applied to your project. Or you have defined the configuration yourself in your project somewhere.
The implementation configuration, provided by the Java plugin, are for implementation details of your application or library. In other words, these are "private" to your application/library and will not be available to consumers' classpath.
We have been using gradle spring boot plugin version 1.5.14 and gradle 4.10.3 for our builds. After an upgrade of gradle to 6.2.2, we've also changed dependency-definition from compile group to implementation group i.e.:
compile group: 'org.springframework.boot', name: 'spring-boot-starter-integration'
to
implementation group: 'org.springframework.boot', name: 'spring-boot-starter-integration'.
The fat jar created via gradle assemble does to my surprise not contain the required libs under BOOT-INF/lib anymore? If I replace "implementation" with "compile" it works again as expected.
Is there something which needs to be configured so that spring-boot-plugin adds them? Or do I need to upgrade the project to spring boot 2 beforehand?
Implementation will bring in the dependency only for that module it is declared in.
Compile will allow a module that depends on the module to use the dependency as well.
Say you have Module A depending on Module B.
Module A and B both need the dependency:
com.font:font1:1.1.1
If B uses:
implementation 'com.font:font1:1.1.1'
A will not see font1, and will need to bring it into its own build.gradle file as well.
compile 'com.font:font1:1.1.1'
will make it available to the entire classpath (which should be avoided anyway, and the new equivalent is for libraries which uses 'api' instead of 'compile').
Without seeing your project directory, I'm assuming that some dependency is not being pulled into a place where it used to be grabbed from a lower dependency in the hierarchy. You should be able to find the missing dependencies easily by changing compile to implementation one at a time, unless you have a huge multi-module project.
I want to use Elasticsearch's Client Java class within a Liferay 7 SP4 FP30 module, so I wrote this build.gradle:
dependencies {
compileOnly group: "com.liferay", name: "com.liferay.portal.search.elasticsearch", version: "2.1.14"
compileOnly group: "com.liferay", name: "org.elasticsearch", version: "2.2.0.LIFERAY-PATCHED-1"
compileOnly group: "biz.aQute.bnd", name: "biz.aQute.bndlib", version: "3.1.0"
compileOnly group: "com.liferay", name: "com.liferay.osgi.util", version: "3.0.0"
compileOnly group: "com.liferay", name: "com.liferay.portal.spring.extender", version: "2.0.0"
compileOnly group: "com.liferay.portal", name: "com.liferay.portal.kernel", version: "2.0.0"
compileOnly group: "com.liferay", name: "com.liferay.portal.security.audit.api", version: "2.0.0"
compileOnly group: "com.liferay", name: "com.liferay.portal.configuration.metatype", version: "2.0.0"
compileOnly group: "org.osgi", name: "org.osgi.compendium", version: "5.0.0"
}
... and a Java class containing code such as import com.liferay.portal.search.elasticsearch.connection.ElasticsearchConnectionManager; and Client client = elasticsearchConnectionManager.getClient();
It builds fine.
But when I try to start the module, this error happens:
org.osgi.framework.BundleException: Could not resolve module: mymodule [548]
Unresolved requirement: Import-Package: com.liferay.portal.search.elasticsearch.connection
Why is this happening? My build.gradle does not mention this module ending in .connection, and Maven does not seem to have any such module.
#gjoranv is correct, just because you in is on your gradle.build it does not mean it will be in your environment.
First things first, the error is due to the lack of a used package, in Java's conventional sense. So you will need a module, as represented by a jar file, that makes this package public.
As liferay is pretty version dependent when it comes to Elastic Search, and relies on accident versions, you might get away with using not exposed packages, and forcing the exposure, normally through a Uber module.
If you are feeling lucky, you can also use compileInclude, instead of compileOnly. Including the library this way will possibly make a mess, as it will embed the jar inside your jar and expose all packages.
Another possibility, which normally is way less aggressive is to embed the jar, and set the classpath inside your bundle. To do this you just need to declare your dependency as compile, and add the classpath in your bnd.bnd file. (it sounds harder than it is, it should be a trivial process)
Another issue to have in mind is the alignment with your ElasticSearch and you liferay deployment:2.2-2.4.x but this is just because you might fall into class conversion exceptions and API mismatch if your objects are used by other bundles or when interfacing with an old ES.
Embedding example:
gradle.build
compile "org.apache.httpcomponents:httpclient"
compile "org.apache.httpcomponents:httpcore"
bnd.bnd
-includeresource: lib/httpclient.jar=httpclient-4.5.3.jar,\
lib/httpcore.jar=httpcore-4.4.6.jar
Bundle-ClassPath: ., lib/httpclient.jar, lib/httpcore.jar
I'm not familiar with Liferay and gradle, but I've been working with OSGi (apache felix) and maven for a long time. The error message indicates that your bundle uses the package com.liferay.portal.search.elasticsearch.connection, but the runtime environment does not have a bundle that exports that package. The package in question is contained in the first dependency mentioned in your build.gradle, but it's not exported. If you like, you can open the bundle jar and peek into its manifest.mf by downloading it from the maven central repo.
Since the package is not exported (only com.liferay.portal.search.elasticsearch.settings is), I assume it's a signal that it's not intended for external use. So maybe you should check if there's another way of doing what you want.
From looking at the Liferay docs for using 3rd party libraries, it seems you are trying to expand the library into your module. Maybe you could try the embedding strategy instead, if you still need to use the .connection package.
Im trying to download and build spring-data-hadoop 2.4.0.RELEASE using the following decleration in my dependencies.gradle:
dependencies {
...
// compile('org.springframework.data:spring-data_hadoop:2.4.0.RELEASE')
compile group: 'org.springframework.data', name: 'spring-data-hadoop', version: '2.4.0.RELEASE'
...
}
Refreshing gradle now results in downloading the newly added dependency BUT the data is not consistend. I got the following external dependencies after the download:
I thought everything is fine now... but I am wrong. Lets open up one of those and look depper into the packages:
If you compare the content of org.springframework.data.hadoop.config with the official API you will notice, that in this package, there should be much more content. The annotations package for example.
How can it be that gradle is not downloading the complete source?
There is a separate spring-data-hadoop-config with the description "Spring for Apache Hadoop Annotation Configuration", so that's probably where annotations would be.
You are pulling the main jar that should pull the transitive artifacts as well.
the org.springframework.data.hadoop.config.annotation is included inside
compile group: 'org.springframework.data', name: 'spring-data-hadoop-config', version: '2.4.0.RELEASE'