For a project, I would like to use the PJBDD library that can be found here:
https://gitlab.com/sosy-lab/software/paralleljbdd (I have no affiliations)
The library is contained in an Ivy repository (https://www.sosy-lab.org/ivy/), which I'd like to use from gradle, as described in the following build.gradle
plugins {
id 'java'
}
group 'de.my.group'
version '1.0'
repositories {
ivy {
url = "https://www.sosy-lab.org/ivy/"
ivyPattern("https://www.sosy-lab.org/ivy/[organisation]/[module]/ivy-[revision].xml")
artifactPattern("https://www.sosy-lab.org/ivy/[organisation]/[module]/[artifact]-[revision](-[classifier]).[ext]")
}
}
dependencies {
implementation 'org.sosy_lab:pjbdd:v1.0.10'
testImplementation 'org.junit.jupiter:junit-jupiter-api:5.8.1'
testRuntimeOnly 'org.junit.jupiter:junit-jupiter-engine:5.8.1'
}
test {
useJUnitPlatform()
}
Yet, it fails. I think, those lines should contain the relevant information:
2022-11-22T18:46:04.063+0100 [DEBUG] [org.gradle.plugins.ide.internal.resolver.UnresolvedIdeDependencyHandler] Could not resolve: org.sosy_lab:pjbdd:v1.0.10
org.gradle.internal.resolve.ModuleVersionResolveException: Could not resolve org.sosy_lab:pjbdd:v1.0.10.
Caused by: org.gradle.internal.component.NoMatchingConfigurationSelectionException: No matching configuration of org.sosy_lab:pjbdd:v1.0.10 was found. The consumer was configured to find a runtime of a library compatible with Java 16, packaged as a jar, preferably optimized for standard JVMs, and its dependencies declared externally but:
- Configuration 'contrib':
- Other compatible attributes:
- Doesn't say anything about its component category (required a library)
- Doesn't say anything about how its dependencies are found (required its dependencies declared externally)
- Doesn't say anything about its target Java environment (preferred optimized for standard JVMs)
- Doesn't say anything about its target Java version (required compatibility with Java 16)
- Doesn't say anything about its elements (required them packaged as a jar)
- Doesn't say anything about its usage (required a runtime)
- Configuration 'runtime':
- Other compatible attributes:
- Doesn't say anything about its component category (required a library)
- Doesn't say anything about how its dependencies are found (required its dependencies declared externally)
- Doesn't say anything about its target Java environment (preferred optimized for standard JVMs)
- Doesn't say anything about its target Java version (required compatibility with Java 16)
- Doesn't say anything about its elements (required them packaged as a jar)
- Doesn't say anything about its usage (required a runtime)
- Configuration 'sources':
- Other compatible attributes:
- Doesn't say anything about its component category (required a library)
- Doesn't say anything about how its dependencies are found (required its dependencies declared externally)
- Doesn't say anything about its target Java environment (preferred optimized for standard JVMs)
- Doesn't say anything about its target Java version (required compatibility with Java 16)
- Doesn't say anything about its elements (required them packaged as a jar)
- Doesn't say anything about its usage (required a runtime)
So, to me it seems like, it successfully retrieves the org.sosy_lab/pjbdd/ivy-v1.0.10.xml, yet it expects more/different content.
Is there a way to handle this, i.e., having gradle to still download and provide the pjbdd-v1.0.10.jar to my implementation configuration?
Related
I am trying to import base to a project, but I get an error.
settings.gradle
enableFeaturePreview('VERSION_CATALOGS')
dependencyResolutionManagement {
versionCatalogs {
libs {
// https://mvnrepository.com/artifact/org.springframework/spring-core
version('spring', '5.3.14')
// https://mvnrepository.com/artifact/org.springframework.boot/spring-boot-starter
version('spring-boot', '2.6.2')
alias('spring-core').to('org.springframework', 'spring-core').versionRef('spring')
alias('spring-context').to('org.springframework', 'spring-context').versionRef('spring')
alias('spring-boot').to('org.springframework.boot', 'spring-boot-starter').versionRef('spring-boot')
bundle('base', ['spring-core', 'spring-context'])
}
}
}
module's build.gradle
dependencies {
implementation(libs.base)
testImplementation 'org.junit.jupiter:junit-jupiter-api:5.7.0'
testRuntimeOnly 'org.junit.jupiter:junit-jupiter-engine:5.7.0'
}
refreshing gradle will produce the following error
Could not get unknown property 'base' for extension 'libs' of type org.gradle.accessors.dm.LibrariesForLibs.
How to import libs.base correctly?
The correct way of referencing a bundle from a version catalog is
libs.bundles.base
Similarly for plugins use:
libs.plugins.yourplugin
It is also possible to reference versions, but this works slightly different. For example:
implementation group: "org.springframework.boot", name: "spring-boot-starter-web-services", version: libs.versions.spring.boot.get()
This assumes a version definition in your catalog which looks like:
version('spring-boot', '2.6.7')
Note that bundles, versions and plugins are all spelled as plural.
Also note that as of Gradle 7 version catalogs are no longer a feature preview. They are available by default. Also, the notation for libraries has changed slightly. You have to use library instead of alias.
See Gradle's support site for more information.
This follows on from this excellent solution to the question of how to get Gradle to bundle up JavaFX with your distributions.
NB specs: Linux Mint 18.3, Java 11, JavaFX 13.
That stuff, involving jlink and a module-info.java, is beyond my pay grade (although I'm trying to read up on these things).
I want to move to using Groovy in my app and test code (i.e. Spock) rather than Java. The trouble is, the minute I include the "normal" dependency in my build.gradle i.e.
implementation 'org.codehaus.groovy:groovy-all:2.5.9'
and try to build, I get multiple errors:
mike#M17A ~/IdeaProjects/TestProj $ ./gradlew build
> Configure project :
Found module name 'javafx.jlink.example.main'
> Task :compileTestJava FAILED
error: the unnamed module reads package org.codehaus.groovy.tools.shell.util from both org.codehaus.groovy.groovysh and org.codehaus.groovy
[...]
error: the unnamed module reads package groovy.xml from both org.codehaus.groovy and org.codehaus.groovy.xml
[...]
error: module org.codehaus.groovy.ant reads package groovy.lang from both org.codehaus.groovy and org.codehaus.groovy.test
error: module org.codehaus.groovy.ant reads package groovy.util from both org.codehaus.groovy.xml and org.codehaus.groovy.ant
100 errors
FAILURE: Build failed with an exception.
* What went wrong:
Execution failed for task ':compileTestJava'.
Yes, 100 errors... probably more! By commenting out various things I think I've come to the conclusion that some Groovy dependency is being injected by the jlink stuff. Fine, I can live with that (although it'd be nice to know what version of Groovy it is).
The trouble is, even if I omit the Groovy dependency line, the same errors occur when I try to introduce the Spock dependency:
testImplementation 'org.spockframework:spock-core:1.2-groovy-2.5'
Has anyone got any idea what's going on here and what to do about it?
I searched for an answer. I didn't find a good solution.
According to this, it seems that Groovy is currently not really compatible with Java modules. It is due to the fact that some packages are contained by multiple jars of the library (not compatible with modules). You will have to wait for Groovy 4 for a compatible version.
I discovered that the JavaFX plugin use this plugin internally. This plugin seems to consider that all dependencies are modules (it is not the default Gradle behaviour).
To make your application works, it seems that you have to:
force Gradle to put Groovy in the classpath instead of the modulepath (it will not be considerered as a module, but seems impossible if you use the javafx plugin)
use the "patch-module" system: it allows Gradle to make a fusion of the library jars into a single module, to prevent the problem of packages that are in different jars
I searched the Groovy jars with IDEA (Project structure/Libraries), and I tried to use the syntax offered by the plugin to use "patch-module":
patchModules.config = [
"org.codehaus.groovy=groovy-ant-3.0.1.jar",
"org.codehaus.groovy=groovy-cli-picocli-3.0.1.jar",
"org.codehaus.groovy=groovy-console-3.0.1.jar",
"org.codehaus.groovy=groovy-datetime-3.0.1.jar",
"org.codehaus.groovy=groovy-docgenerator-3.0.1.jar",
"org.codehaus.groovy=groovy-groovydoc-3.0.1.jar",
"org.codehaus.groovy=groovy-groovysh-3.0.1.jar",
"org.codehaus.groovy=groovy-jmx-3.0.1.jar",
"org.codehaus.groovy=groovy-json-3.0.1.jar",
"org.codehaus.groovy=groovy-jsr-3.0.1.jar",
"org.codehaus.groovy=groovy-macro-3.0.1.jar",
"org.codehaus.groovy=groovy-nio-3.0.1.jar",
"org.codehaus.groovy=groovy-servlet-3.0.1.jar",
"org.codehaus.groovy=groovy-sql-3.0.1.jar",
"org.codehaus.groovy=groovy-swing-3.0.1.jar",
"org.codehaus.groovy=groovy-templates-3.0.1.jar",
"org.codehaus.groovy=groovy-test-junit-3.0.1.jar",
"org.codehaus.groovy=groovy-test-3.0.1.jar",
"org.codehaus.groovy=groovy-testng-3.0.1.jar",
"org.codehaus.groovy=groovy-xml-3.0.1.jar"
]
It only works with a single line "org.codehaus.groovy=X.jar", but a bug prevents it to work with all of the library jars (Look at this issue on Github).
So you have multiple choices:
Use Java instead of Groovy
Wait for a new Groovy release, or new releases of plugins (modules-plugin, and a version of javafx-plugin that use this one internally)
Use old javafx configuration: dependencies are not module by default, and you have to specify manually in build.gradle that JavaFX dependencies should be considered as a module (check my "obsolete" answer to this question)
I have a multi-module gradle project where in a module I add dependencies in compile configuration on runtime.
Those dependencies fetch a transitive dependency with a version prefix that does not exist.
So case is like this
compile 'group:moduleA:version.+'
This moduleA downloads moduleB with same version.+ prefix notation and that downloads another moduleC with same prefix notation, moduleC is present in artifactory with version 10 and above and 8 and below, so there are no versions which are number 9, and gradle insist on finding moduleC with version 9, it doesn't fetch versions above or below it.
How can I make gradle fetch another version if the version its trying to find is not there?
Please comment for any clarification and thanks for helping.
EDIT: Want to clarify that + in version part is not resolving to a number which is correct and present on artifactory, like 9.1 or 9.12.
gradle determines this version, which is incorrect like 9.1 is present but it resolves to 9.2 or some other number which is not there.
EDIT2: Task which is used to fetch dependencies and then add them in compile configuration.
task addAdditionalDependencies {
doLast {
Object slurper = new JsonSlurper().parseText(api.jsonResponse())
Set<String> dependencyNames = configurations.compile.dependencies.collect { it.name }
List<Map<String, String>> artifactPaths = slurper.results.collect {
String[] pathSegments = it.path.split('/')
if (!dependencyNames.contains(pathSegments[1]) && project.name != pathSegments[1]) {
[group: pathSegments[0],
name: pathSegments[1],
version: "version.+",
configuration: 'compile']
} else [:]
}
artifactPaths.each {
if (!it.isEmpty()) {
project.dependencies.add('compile', it)
}
}
// we have to call this because app does not have any source files and so compileJava does not download
// dependencies
configurations.compile.files
}
}
When using a version like 9.+, Gradle will looks for all version that matches the prefix, that is the part before the +.
There is however no way to make Gradle ignore that part in case no such version exist.
If the version of moduleC can be anything, then you could simply use + without any prefix.
Note that doing something like that could expose you to breakage in a build even though nothing changed, aside from a new version of moduleC being published.
You could also combine this dynamic version resolution with dependency locking to have a finer grained control on when to upgrade moduleC.
I want to include the Java Bindings for V8 ("J2V8") in a Java project. The reasons are that (i) the V8 JavaScript engine is much faster then the JavaScript engine shipped with the JRE and (ii) the library I am using is available in JavaScript only and a port to Java is much effort.
The issue is that J2V8 is compiled for different platforms: linux 64bit, macos 64bit, windows 64 bit, windows 32 bit.
I now want to generate different JARs, containing all the dependencies (fat jars):
jabref-linux_x86_64.jar
jabref-macosx_x86_64.jar
jabref-windows_x86_32.jar
jabref-windows_x86_64.jar
jabref-all.jar - the platform indipendent JAR without v8 engine
I am currently creating fat jars using the shadow plugin.
Note that the project is not an Android project. There, with the Android plugin, it seems to be straight-forward to do that.
The first idea is to introduce configurations and configuration-specific dependencies:
configurations {
linux_x86_64Compile.extendsFrom compile
macosx_x86_64Compile.extendsFrom compile
windows_x86_32Compile.extendsFrom compile
windows_x86_64Compile.extendsFrom compile
}
dependencies {
compile configuration: 'linux_x86_64', group: 'com.eclipsesource.j2v8', name: 'j2v8_linux_x86_x64', version: '4.6.0'
compile configuration: 'macosx_x86_64', group: 'com.eclipsesource.j2v8', name: 'j2v8_macosx_x86_x64', version: '4.6.0'
compile configuration: 'windows_x86_32', group: 'com.eclipsesource.j2v8', name: 'j2v8_win32_x86', version: '4.6.0'
compile configuration: 'windows_x86_64', group: 'com.eclipsesource.j2v8', name: 'j2v8_win32_x86_x64', version: '4.6.0'
...
}
But now I'm stuck. In pseudocode, I'd like to do:
task releaseSingleJar(dependsOn: "shadowJar", name) {
doLast {
copy {
from("$buildDir/libs/JabRef-${project.version}-fat.jar")
into("$buildDir/releases/")
rename { String fileName ->
fileName.replace('-fat', '-$name')
}
}
}
}
task releaseJars() {
forEach name in "linux_x86_64", "macosx_x86_64", "windows_x86_32", "windows_x86_64", "all":
if (name != "all") activate configuration $name
releaseSingleJar($name)
shadowJar is from the shadow plugin.
Background information
Video showing the difference of speed in our setting: https://github.com/JabRef/jabref/pull/2250#issuecomment-264824598
Current state of the integration in JabRef: https://github.com/JabRef/jabref/pull/3180
Related questions
The question Using Gradle to manage Java web app with flavors like Android has a similar title, but asks for source directories, whereas I ask for dependencies. Further, I want to generate a fat JAR and there a plain JAR seems to be enough. However, it might be that the solution is similar. A hint was to use the gradle-java-flavours plugin with the main source being JavaFlavoursExtension.groovy.
Following questions are similar to this one. However, the setting is related to Android apps and not to plain Java apps.
How to define different dependencies for different product flavors
Gradle: add dependency for a specific flavour of the library
Change dependency through a task in gradle
Use different resources for different application flavors using gradle
You might be interested in my gradle-java-flavours plugin which creates source sets, configurations and compile, jar and test tasks for each flavour in a java only project.
eg:
import com.github.jengelman.gradle.plugins.shadow.tasks.*
plugins {
id 'com.lazan.javaflavours' version '1.2'
id 'com.github.johnrengelman.shadow' version '1.2.4'
}
def flavours = ['linux_x86_64', 'macosx_x86_64', ...]
javaFlavours {
flavours.each {
flavour it
}
}
dependencies {
linux_x86_64Compile 'aaa:aaa:1.0'
linux_x86_64Runtime 'bbb:bbb:1.0'
macosx_x86_64TestCompile 'ccc:ccc:3.0'
}
flavours.each { String flavour ->
SourceSet flavourSourceSet = sourceSets.getByName(flavour)
Configuration flavourRuntime = configurations.getByName("${flavour}Runtime")
JavaCompile flavourCompileTask = tasks.getByName("compile${flavour.capitalize()}Java")
Task shadowJarTask = tasks.create(name: "${flavour}ShadowJar", type: ShadowJar) {
classifier = "${flavour}-all"
dependsOn flavourCompileTask
// todo configure (likely based on Configuration and SourceSet)
}
artifacts {
archives shadowJarTask
}
// wire the task into the DAG
assemble.dependsOn shadowJarTask
}
I'm running Gluon/charm version 3.0.0. I added a Java8-compiled library into my JavaFX project (created via the IntelliJ plugin) and on iOS it works and builds as expected, but when executing the gradle tasks android or androidInstall I get this error back:
[ant:java] Java Result: 1
:createMainDexList FAILED
FAILURE: Build failed with an exception.
* What went wrong:
Execution failed for task ':createMainDexList'.
> Exception in thread "main" com.android.dx.cf.iface.ParseException: InvokeDynamic not supported
at com.android.dx.cf.cst.ConstantPoolParser.determineOffsets(ConstantPoolParser.java:226)
at com.android.dx.cf.cst.ConstantPoolParser.parse(ConstantPoolParser.java:132)
at com.android.dx.cf.cst.ConstantPoolParser.parseIfNecessary(ConstantPoolParser.java:124)
at com.android.dx.cf.cst.ConstantPoolParser.getPool(ConstantPoolParser.java:115)
at com.android.dx.cf.direct.DirectClassFile.parse0(DirectClassFile.java:491)
at com.android.dx.cf.direct.DirectClassFile.parse(DirectClassFile.java:406)
at com.android.dx.cf.direct.DirectClassFile.parseToEndIfNecessary(DirectClassFile.java:397)
at com.android.dx.cf.direct.DirectClassFile.getAttributes(DirectClassFile.java:311)
at com.android.multidex.MainDexListBuilder.hasRuntimeVisibleAnnotation(MainDexListBuilder.java:191)
at com.android.multidex.MainDexListBuilder.keepAnnotated(MainDexListBuilder.java:167)
at com.android.multidex.MainDexListBuilder.<init>(MainDexListBuilder.java:121)
at com.android.multidex.MainDexListBuilder.main(MainDexListBuilder.java:91)
at com.android.multidex.ClassReferenceListBuilder.main(ClassReferenceListBuilder.java:58)
...while preparsing cst 0002 at offset 0000000f
...while parsing de/<removed>/traffic_light/library/Test.class
What I find a bit weird is that I don't even have a Test class for traffic_light, not even in the library. Searching for the error I found that it probably needs Java 8 to invokeDynamic/Support Lambdas, but for example Gluon's Presenter itself uses Lambdas.
Also, googling I find this hit about the same issue but sadly Gluon removed their forum and the page isn't cached anywhere.
Typically this error happens when you add some third party dependencies to the project that use lambda expressions, since currently the retrolambda plugin is applied to the source code of your project only.
You can try:
Remove that dependency and add its source code instead.
Apply retrolambda to the original dependency, and then add it to your project.
Or use the most recent jfxmobile plugin: the 1.0.10-SNAPSHOT will apply retrolambda to both the source code and the third party dependencies (even if no source code is provided).
For the last option, just change the jfxmobile plugin version on top of your build.gradle file:
buildscript {
repositories {
jcenter()
maven {
url "https://oss.sonatype.org/content/repositories/snapshots/"
}
}
dependencies {
classpath 'org.javafxports:jfxmobile-plugin:1.0.10-SNAPSHOT'
}
}