I'm a bit confused about the gradle build file versions configurations for the different components. I was reading the docs on http://docs.gluonhq.com/javafxports/ and have a few questions.
jfxmobile-plugin
buildscript {
dependencies {
classpath 'org.javafxports:jfxmobile-plugin:1.3.5'
}
}
The version number I check here: https://bitbucket.org/javafxports/javafxmobile-plugin. It's my understanding that Gluon mobile builds upon this plugin. So if I already specify dependencies on Gluon Mobile why do I need to specify this one individually?
javafxportsVersion
jfxmobile {
javafxportsVersion = '8.60.9'
}
The version number I check here: http://gluonhq.com/products/mobile/javafxports/get/. I don't specify this but I see it in chapter 4.2. When do I need to specify this?
downConfig
jfxmobile {
downConfig {
version = '3.2.4'
plugins 'display', 'lifecycle', 'statusbar', 'storage'
}
}
I don't know where to find the version number for this. It is chapter 4.2.2. I think that this one i specify only if I want to override the default for Charm Down. But if I remove these Gradle downloads version 3.2.0 which is older. Where do I find the latest version and when do I need to specify it?
gluonhq:charm
dependencies {
compile 'com.gluonhq:charm:4.3.5'
}
I check the version here: http://docs.gluonhq.com/charm/latest/. To my understanding this includes Charm Down, Charm Glisten and Connect. Does it specify the downConfig version implicitly? It it related to (in terms of versioning) to the JFXPorts/Mobile above?
If you use the Gluon plugin for your IDE, and select the Gluon Mobile templates, you should get the latest versions of all the plugins, dependencies and underlaying tools involved.
When you create a project, there is an online check done to verify which are those latest versions, so your new project is up to the date. Though it could happen that the backend hasn't been updated right after any of those change.
With a Single view template you get this build.gradle file:
buildscript {
repositories {
jcenter()
}
dependencies {
classpath 'org.javafxports:jfxmobile-plugin:1.3.5'
}
}
apply plugin: 'org.javafxports.jfxmobile'
repositories {
jcenter()
maven {
url 'http://nexus.gluonhq.com/nexus/content/repositories/releases'
}
}
mainClassName = 'com.gluonhq.testsingle.GluonTestSingle'
dependencies {
compile 'com.gluonhq:charm:4.3.2'
}
jfxmobile {
downConfig {
version = '3.2.4'
// Do not edit the line below. Use Gluon Mobile Settings in your project context menu instead
plugins 'display', 'lifecycle', 'statusbar', 'storage'
}
android {
manifest = 'src/android/AndroidManifest.xml'
}
ios {
infoPList = file('src/ios/Default-Info.plist')
forceLinkClasses = [
'com.gluonhq.**.*',
'javax.annotations.**.*',
'javax.inject.**.*',
'javax.json.**.*',
'org.glassfish.json.**.*'
]
}
}
That's the minimum required content for your script to make the app work on Desktop, Android and iOS.
As for the jfxmobile plugin, as you mentioned, the latest version (as of now 1.3.5) can be verified here.
By default it includes the latest version of JavaFXPorts: javafxportsVersion = '8.60.9', so you don't need to include it in your build. But you may want to use it in some cases, i.e. when you are using snapshots, daily or monthly builds (customers have access to them), in case new changes have been added and you don't want to wait until the next public release. The latest version can be found here.
This plugin has nothing to do with Gluon Mobile. While the former is a plugin to install the JavaFXPorts dependencies (like dalvik-sdk, jfxdvk.jar and ios-sdk) and required tools (gradle tasks,...), the latter is a library containing Views, controls, styling,... and other dependencies, that is placed on top of JavaFXPorts to create high performance, great looking, and cloud connected mobile apps from a single Java code base, for iOS and Android.
That's why you need the plugin in the first place, and you can add later on the Gluon Mobile dependency.
As of now, the latest version is 4.3.5, as you can check here. The online tool still shows 4.3.2, but at this point the differences are minimal.
Gluon Mobile (Charm dependency) makes use of other dependencies as well. Run ./gradlew dependencies, and you will see a tree like this:
runtime - Runtime dependencies for source set 'main'.
+--- com.gluonhq:charm:4.3.5
| +--- com.gluonhq:connect:1.4.3
| | \--- org.glassfish:javax.json:1.0.4
| +--- com.gluonhq:charm-cloudlink-client:4.3.5
| | +--- com.gluonhq:connect:1.4.3 (*)
| | +--- com.gluonhq:charm-down-plugin-storage:3.2.4
| | | \--- com.gluonhq:charm-down-core:3.2.4
| | +--- com.gluonhq:charm-down-plugin-device:3.2.4
| | | \--- com.gluonhq:charm-down-core:3.2.4
| | \--- com.gluonhq:charm-down-plugin-push-notifications:3.2.4
| | +--- com.gluonhq:charm-down-core:3.2.4
| | \--- com.gluonhq:charm-down-plugin-runtime-args:3.2.4
| | \--- com.gluonhq:charm-down-core:3.2.4
| +--- com.gluonhq:charm-glisten-connect-view:4.3.5
| | +--- com.gluonhq:charm-cloudlink-client:4.3.5 (*)
| | \--- com.gluonhq:charm-glisten:4.3.5
| | +--- com.gluonhq:charm-down-plugin-display:3.2.4
| | | \--- com.gluonhq:charm-down-core:3.2.4
| | +--- com.gluonhq:charm-down-plugin-lifecycle:3.2.4
| | | \--- com.gluonhq:charm-down-core:3.2.4
| | +--- com.gluonhq:charm-down-plugin-statusbar:3.2.4
| | | \--- com.gluonhq:charm-down-core:3.2.4
| | \--- com.gluonhq:charm-down-plugin-storage:3.2.4 (*)
| \--- com.gluonhq:charm-glisten:4.3.5 (*)
+--- com.gluonhq:charm-down-plugin-display:3.2.4 (*)
+--- com.gluonhq:charm-down-plugin-lifecycle:3.2.4 (*)
+--- com.gluonhq:charm-down-plugin-statusbar:3.2.4 (*)
\--- com.gluonhq:charm-down-plugin-storage:3.2.4 (*)
Basically it includes dependencies on Charm Glisten, Gluon Connect, Charm Cloudlink Client, Charm Glisten Connect View, and the different Charm Down plugins.
For Charm Down, you can find the latest version here. In fact, 3.3.0 has been released recently. In theory, you don't need to specify the version here as well, but it is advisable, in order to keep track of the version you used when creating the project.
Charm Down is not included in Gluon Mobile, so you have to use downConfig in your project, to explicitly at least add the required plugins that Gluon Mobile uses (the four added by default: 'display', 'lifecycle', 'statusbar', 'storage'). But you can add more plugins if you need them (select right click on the root project and click on Gluon Mobile Settings).
EDIT
Gluon Mobile includes the four services from Down as a dependency (jars like charm-down-plugin-storage only with the Service definition), but it is only resolved in your project when you include the platform implementations via downConfig (like charm-down-plugin-storage-desktop, charm-down-plugin-storage-android and charm-down-plugin-storage-ios).
As mentioned above, the versions should be up to the date when you create the project, but you can double check and update manually if you find newer ones.
As for the Gluon Mobile Settings menu, this is a picture of how to get it on NetBeans. Just right click on the project root:
Related
I have a spring-boot gradle project. It has a dependency of a dependency of a dependency that I cannot use for internal reasons. I've forked that module and published it to my repo with its own version number that I want to be used in my project.
Part of the dependency tree looks like:
compileClasspath - Compile classpath for source set 'main'.
+--- org.springframework.boot:spring-boot-starter-web:2.7.2
| +--- org.springframework.boot:spring-boot-starter-tomcat:2.7.2
| | +--- jakarta.annotation:jakarta.annotation-api:1.3.5
| | +--- org.apache.tomcat.embed:tomcat-embed-core:9.0.65
| | +--- org.apache.tomcat.embed:tomcat-embed-el:9.0.65
| | \--- org.apache.tomcat.embed:tomcat-embed-websocket:9.0.65
I need to force my project to use a custom version of those bottom two modules, let's call the new versions org.apache.tomcat.embed:tomcat-embed-el:9.0.65.CUSTOM and org.apache.tomcat.embed:tomcat-embed-websocket:9.0.65.CUSTOM.
I've never attempted this. I'm trying all different setups in my project's build.gradle file like
configurations { main }
configurations.main.resolutionStrategy.dependencySubstitution {
substitute module('org.apache.tomcat.embed:tomcat-embed-el:9.0.65') using module('org.apache.tomcat.embed:tomcat-embed-el:9.0.65.CUSTOM')
substitute module('org.apache.tomcat.embed:tomcat-embed-websocket:9.0.65') using module('org.apache.tomcat.embed:tomcat-embed-websocket:9.0.65.CUSTOM')
}
But the 9.0.65 versions keep getting injected. So my question(s) are:
Am I using dependencySubstitution incorrectly, and where in the build.gradle should it be?
Does dependencySubstitution work for dependencies of dependencies (ad nauseam), or only for direct dependencies?
Short of forking all these dependencies to declare their dependencies, is there any way I can force my Gradle to never use version 9.0.65 and only ever use 9.0.65.CUSTOM no matter its location in the dependency tree?
Assuming your configurations are setup properly and the coordinates for your custom modules are correct, you should be able to do
allprojects {
configurations.all {
resolutionStrategy {
dependencySubstitution {
substitute(module("org.apache.tomcat.embed:tomcat-embed-el")).with(module("org.apache.tomcat.embed:tomcat-embed-el:9.0.65.CUSTOM"))
substitute(module("org.apache.tomcat.embed:tomcat-embed-websocket")).with(module("org.apache.tomcat.embed:tomcat-embed-websocket:9.0.65.CUSTOM"))
}
}
}
}
I would double check you have your repositories, configurations and that you are doing this dependency substitution in the module that needs to substitute the given modules for custom ones. Otherwise you may run into errors.
I work on a large project with multiple services and libraries, mostly in grails, with gradle builder. I'm trying to update a library (say logback) for security reasons.
I already updated it in one of our libraries (say our-logger), like so:
#our-logger/build.gradle
...
dependencies {
...
compile 'ch.qos.logback:logback-classic:1.2.3'
...
}
when I update a service (say our-service) to use the new version of our-logger i get logback included from other libraries, and gradle chooses the lower version coming through cobertura and some other dependencies, instead of the higher version coming through our-logger.
#our-service/build.gradle
...
apply plugin: 'cobertura'
...
dependencies {
...
compile 'our-logger:9.99' # safe now with logback-1.2.3
...
}
~/our-service $ ./gradlew dependencies
...
cobertura
\--- net.sourceforge.cobertura:cobertura:2.1.1
+--- ch.qos.logback:logback-classic:1.0.13 -> 1.1.11
| \--- ch.qos.logback:logback-core:1.1.11
...
compile - Dependencies for source set 'main' (deprecated, use 'implementation ' instead).
+--- org.grails:grails-dependencies:3.3.8
| +--- org.springframework.boot:spring-boot-starter-logging:1.4.2.RELEASE -> 1.5.15.RELEASE
| | +--- ch.qos.logback:logback-classic:1.1.11
| | | +--- ch.qos.logback:logback-core:1.1.11
...
+--- our-logger:9.99
| +--- ch.qos.logback:logback-classic:1.2.3 -> 1.1.11 (*)
How do I enforce logback-1.2.3 without explicitly declaring it in all services?
The gradle docs file this under Advanced Dependency Management. You should be able to satisfy your goal using excludes. There are other ways too Gradle Docs
compile(“some:other:dependency”) {
exclude group: 'ch.qos.logback', module: 'logback-classic'
}
I have a project with two gradle modules: lib and app. I just changed lib's build.gradle to stop exposing a dependency (i.e. I moved from api -> implementation). The app module doesn't directly depend on OkHttp logging interceptor so I figure it's better to not expose it.
lib module's build.gradle:
dependencies {
// api 'com.squareup.okhttp3:logging-interceptor:3.10.0'
implementation 'com.squareup.okhttp3:logging-interceptor:3.10.0'
...
}
app module's build.gradle:
dependencies {
implementation project(':lib')
implementation group: 'com.zendesk', name: 'support-providers', version: '2.0.0'
...
}
However I'm now seeing a compile problem:
Conflict with dependency 'com.squareup.okhttp3:logging-interceptor' in
project ':app'. Resolved versions for runtime classpath (3.10.0) and
compile classpath (3.8.1) differ
If I look at project structure I see this:
+--- project :lib
...
+--- com.zendesk:support-providers:2.0.0
| +--- com.zendesk:core:1.0.0
| | +--- com.zendesk:java-common:1.13
| | +--- com.google.dagger:dagger:2.12 -> 2.15 (*)
| | +--- com.squareup.retrofit2:retrofit:2.3.0
| | | \--- com.squareup.okhttp3:okhttp:3.8.0 -> 3.8.1
| | | \--- com.squareup.okio:okio:1.13.0
| | +--- com.squareup.retrofit2:converter-gson:2.3.0
| | | +--- com.squareup.retrofit2:retrofit:2.3.0 (*)
| | | \--- com.google.code.gson:gson:2.7
| | +--- com.squareup.okhttp3:logging-interceptor:3.8.1 // <----- SEE HERE
| | | \--- com.squareup.okhttp3:okhttp:3.8.1 (*)
| | +--- com.squareup.okhttp3:okhttp:3.8.1 (*)
| | +--- com.android.support:support-annotations:27.0.2 -
lib isn't revealing any of it's dependencies (obviously) and app depends on Zendesk sdk which depends on different version of OkHttp logging interceptor.
I only see two ways to fix this:
revert api -> implementation in lib module, thus exposing logging interceptor to app module
declare a top level dependency on logging interceptor and set to 3.10 to force Zendesk to use latest:
app build.gradle:
dependencies {
implementation project(':lib')
implementation group: 'com.zendesk', name: 'support-providers', version: '2.0.0'
// used just to force zendesk to use 3.10
implementation 'com.squareup.okhttp3:logging-interceptor:3.10.0'
...
}
Neither of these seem very clean. IMO the app module shouldn't know anything about OkHttp logging interceptor. Is there another option?
If Zendesk updated their library to use implementation for their OkHttp dependency would this solve the problem? Will Gradle let two dependencies use different versions of the same transitive dependency as long as they don't expose to the project as a whole?
with Gradle this works a little different ...
one can either enforce the version 3.10.0:
dependencies {
implementation group: 'com.zendesk', name: 'support-providers', version: '2.0.0'
}
configurations.all() {
resolutionStrategy.force "com.squareup.okhttp3:logging-interceptor:3.10.0"
}
or just exclude version 3.8.1 (which is leaving nothing but the desired version 3.10.0):
dependencies {
implementation ('com.zendesk:support-providers:2.0.0") {
exclude "com.squareup.okhttp3:logging-interceptor:3.8.1"
}
}
I am seeing some weirdness in my Gradle build. I have a Spring Boot app (which uses Gradle for its build) and am trying to pull in both the Hibernate Validator as well as Hibernate Core. Here's the dependencies declaration in my build.gradle file:
dependencies {
compile('org.springframework.boot:spring-boot-starter-web') {
exclude module: 'spring-boot-starter-tomcat'
}
compile(
'org.codehaus.groovy:groovy-all:2.4.12'
,'com.google.inject:guice:4.1.0'
,'ch.qos.logback:logback-classic:1.2.3'
,'org.slf4j:jul-to-slf4j:1.7.25'
,'org.apache.logging.log4j:log4j-to-slf4j:2.9.1'
,'commons-cli:commons-cli:1.4'
,'org.apache.commons:commons-lang3:3.7'
,'io.dropwizard.metrics:metrics-core:3.2.5'
,'io.dropwizard.metrics:metrics-json:3.2.5'
,'org.springframework.security:spring-security-jwt:1.0.9.RELEASE'
,'org.springframework.security.oauth:spring-security-oauth2:2.2.1.RELEASE'
,'io.jsonwebtoken:jjwt:0.9.0'
,'org.hibernate:hibernate-validator:6.0.7.Final'
,'mysql:mysql-connector-java:6.0.6'
,'org.hibernate:hibernate-core:5.2.12.Final'
,'com.h2database:h2:1.4.196'
,'org.springframework.boot:spring-boot-starter-jetty'
,'org.springframework.boot:spring-boot-starter-actuator'
,'org.springframework.boot:spring-boot-starter-security'
,'org.springframework.boot:spring-boot-starter-data-rest'
,'org.springframework.boot:spring-boot-starter-data-jpa'
)
dev('org.springframework.boot:spring-boot-devtools')
testCompile(
'org.spockframework:spock-core:1.0-groovy-2.4'
,'junit:junit:4.12'
)
}
When I run ./gradlew dependencies I get a huge output, but from the compile dependencies tree I see the following:
| +--- org.springframework.boot:spring-boot-starter:1.5.8.RELEASE
| +--- org.hibernate:hibernate-validator:5.3.5.Final -> 6.0.7.Final
| | \--- org.hibernate.validator:hibernate-validator:6.0.7.Final
| | +--- javax.validation:validation-api:2.0.1.Final -> 1.1.0.Final
| | +--- org.jboss.logging:jboss-logging:3.3.0.Final -> 3.3.1.Final
| | \--- com.fasterxml:classmate:1.3.1 -> 1.3.4
So to me it looks like spring-boot-starter:1.5.8.RELEASE is pulling in validation-api:2.0.1.Final but for some reason Gradle is selecting validation-api:1.1.0.Final for me...am I reading that correctly? In my IDE compile classpath I only see validation-api:1.1.0.Final, not 2.0.1.Final.
Why is Gradle selecting 1.1.0.Final instead of 2.0.1.Final? I ask because Hibernate Validator 5.x is not compatible with Validation API 1.x and when my app runs I get all sorts of Hibernate Validation-related errors.
Update
Some more output:
gradle -q dependencyInsight --configuration compile --dependency validation-api
javax.validation:validation-api:1.1.0.Final (selected by rule)
javax.validation:validation-api:2.0.1.Final -> 1.1.0.Final
\--- org.hibernate.validator:hibernate-validator:6.0.7.Final
\--- org.hibernate:hibernate-validator:6.0.7.Final
+--- compile
\--- org.springframework.boot:spring-boot-starter-web:1.5.8.RELEASE
+--- compile
\--- org.springframework.boot:spring-boot-starter-data-rest:1.5.8.RELEASE
\--- compile
The full compile configuration output can be found here.
The version is enforced by Spring Boot.
See the POM for the Spring Boot dependencies: http://search.maven.org/remotecontent?filepath=org/springframework/boot/spring-boot-dependencies/1.5.8.RELEASE/spring-boot-dependencies-1.5.8.RELEASE.pom and look for "javax-validation.version".
See https://docs.spring.io/platform/docs/Brussels-SR4/reference/html/getting-started-overriding-versions.html for more information on how to override Spring Boot versions.
I would recommend overriding directly "javax-validation.version" and "hibernate-validator.version" instead of redefining the dependencies.
There is some conflict with another dependency that is pulling the older 1.1.0 in the compile classpath.
This means that some other library which has higher priority in gradle build order is dependent the older 1.1.0 version.
You can see here more info on how to specify the gradle build order.
I met similar problems, then I found it caused by using the Dependency management in gradle:
plugins {
...
id 'io.spring.dependency-management' version '1.0.10.RELEASE'
}
dependencyManagement {
imports {
mavenBom "org.springframework.cloud:spring-cloud-dependencies:Hoxton.SR8"
}
}
this dependency management impact the transitive dependency version solution. after comment it out. all the version is correct.
I ran into a problem that puzzled me.
I use gradle build spring-boot project and i want package a runtime jar.
this is my dependencies :
buildscript {
dependencies {
classpath("org.springframework.boot:spring-boot-gradle-plugin:1.5.5.RELEASE")
}
}
plugins {
id 'org.springframework.boot' version '1.5.5.RELEASE'
}
dependencies {
....
compile 'org.elasticsearch:elasticsearch:5.0.0'
compile 'org.elasticsearch.client:transport:5.0.0'
....
}
i run the cmd gradle dependencies :
+--- org.elasticsearch:elasticsearch:5.0.0 -> 2.4.5
| | +--- org.apache.lucene:lucene-core:5.5.4
| | +--- org.apache.lucene:lucene-backward-codecs:5.5.4
| | | \--- org.apache.lucene:lucene-core:5.5.4
| | +--- org.apache.lucene:lucene-analyzers-common:5.5.4
when i remove spring-boot plugin, Everything is normal.
i change spring-boot plugin version. some time There are some dependencies Will change the version.
please help me check it question, thx !