I'm using LibGDX to make a videogame and I updated Android Studio to version 3 and Gradle to version 4 without noticing that some of the plugins that LibGDX uses on the Gradle files are now deprecated.
I have no experience using Gradle and I know a little bit about how the tasks work and the plugins but not in much depth.
My question is about the Jetty plugin that is now deprecated and Gradle recommends me to use the Gretty plugin instead.
I already put it in my code but, of course, now I need to change the Jetty tasks for the Gretty ones and that is now my problem.
This is my build.gradle file right now:
apply plugin: "java"
//apply plugin: "jetty"
apply plugin: 'war'
apply from: 'https://raw.github.com/akhikhl/gretty/master/pluginScripts/gretty.plugin'
//TODO: Arreglar jetty por gretty
gwt {
gwtVersion='2.6.0' // Should match the gwt version used for building the gwt backend
maxHeapSize="1G" // Default 256m is not enough for gwt compiler. GWT is HUNGRY
minHeapSize="1G"
src = files(file("src/")) // Needs to be in front of "modules" below.
modules 'com.projectcastle.game.GdxDefinition'
devModules 'com.projectcastle.game.GdxDefinitionSuperdev'
project.webAppDirName = 'webapp'
compiler {
strict = true;
enableClosureCompiler = true;
disableCastChecking = true;
}
}
task draftRun(type: JettyRunWar) {
dependsOn draftWar
dependsOn.remove('war')
webApp=draftWar.archivePath
daemon=true
}
task superDev(type: de.richsource.gradle.plugins.gwt.GwtSuperDev) {
dependsOn draftRun
doFirst {
gwt.modules = gwt.devModules
}
}
task dist(dependsOn: [clean, compileGwt]) {
doLast {
file("build/dist").mkdirs()
copy {
from "build/gwt/out"
into "build/dist"
}
copy {
from "webapp"
into "build/dist"
}
copy {
from "war"
into "build/dist"
}
}
}
draftWar {
from "war"
}
task addSource << {
sourceSets.main.compileClasspath += files(project(':core').sourceSets.main.allJava.srcDirs)
}
tasks.compileGwt.dependsOn(addSource)
tasks.draftCompileGwt.dependsOn(addSource)
sourceCompatibility = 1.6
sourceSets.main.java.srcDirs = [ "src/" ]
eclipse.project {
name = appName + "-html"
}
And this is the error is giving me:
* What went wrong:
A problem occurred evaluating project ':html'.
> Could not get unknown property 'JettyRunWar' for project ':html' of type org.gradle.api.Project.
So the JettyRunWar type and the draftRun task are the ones that I don't know how to change to make them compatible for Gretty.
Thanks in advance!!
For some reason (maybe you deleted it when updating Gradle from 2.X version) you deleted import of Jetty but in
html/build.gradle
you should delete its starter too:
task draftRun(type: JettyRunWar) {
dependsOn draftWar
dependsOn.remove('war')
webApp=draftWar.archivePath
daemon=true }
and probably you should delete starter in the same file:
task superDev(type: de.richsource.gradle.plugins.gwt.GwtSuperDev) {
dependsOn draftRun
doFirst {
gwt.modules = gwt.devModules
} }
cheers!
Using this build file gets rid of jetty completely (you just have to edit some lines so it fits your project):
https://github.com/libgdx/libgdx/blob/master/tests/gdx-tests-gwt/build.gradle
But there is another huge problem with gradle 4.+ as seen in this issue:
https://github.com/libgdx/libgdx/issues/4698
They say they will fix it and as long as they are working on it, we have to use old gradle and had to wait.
Related
I'm adding Checker Framework to an existing Java Gradle build. I have Checker integrated and raising issues and that's all working great. But now that I've added it, my build is no longer producing a .jar file as it once did.
Previously, I'd get a .jar at build/libs/myproject.jar. Now instead I see build/checkerframework and build/main but no build/libs and no .jar.
My build.gradle is below. Anyone attempted this before? Any success?
I guess I'd also accept an answer that shows how run Checker outside of the build, e.g. gradle check to run a build with Checker, and gradle build to produce a .jar. But I'd really prefer to have just a single build step if at all possible.
Thanks!
plugins {
id "org.checkerframework" version "0.5.18"
id 'application'
}
apply plugin: 'org.checkerframework'
checkerFramework {
checkers = [
'org.checkerframework.checker.nullness.NullnessChecker',
'org.checkerframework.checker.units.UnitsChecker'
]
}
repositories {
jcenter()
}
java {
sourceCompatibility = JavaVersion.VERSION_11
targetCompatibility = JavaVersion.VERSION_11
}
jar {
duplicatesStrategy = DuplicatesStrategy.EXCLUDE
// Embed all dependencies to create a "fat jar" as required for AWS deployment.
// Exclude 3rd-party signing files to prevent security errors at runtime
from {
configurations.runtimeClasspath.collect { it.isDirectory() ? it : zipTree(it) }
} {
exclude 'META-INF/*.RSA', 'META-INF/*.SF', 'META-INF/*.DSA'
}
manifest {
attributes('Main-Class': 'client.CliMain')
}
}
If the build is passing, then adding -processor should not affect whether a .jar file is produced. (Unless you pass -proc:only or the like.)
If the build is failing, then Gradle won't build the jar files.
You said the Checker Framework is "raising issues", so maybe the build is failing.
We have a few .proto files from which java classes are generated.
Because we have to keep the generated files in the repository, we would like to generate them only when we want (and not during every single build ). We are using this plugin. Also we would like to stick with this plugin, since we have quite a few things configured and we found it pretty useful.
Is there a way to exclude code generation during build task in gradle?
You can enable/disable protobuf tasks based on the property passed via command line:
buildscript {
repositories {
mavenCentral()
}
dependencies {
classpath 'com.google.protobuf:protobuf-gradle-plugin:0.8.3'
}
}
apply plugin: 'java'
apply plugin: 'com.google.protobuf'
protobuf {
generateProtoTasks {
all().each { task ->
task.enabled = project.hasProperty('runProtobuf')
}
}
}
afterEvaluate {
println "generateProto enabled ${tasks.generateProto.enabled}"
println "generateTestProto enabled ${tasks.generateTestProto.enabled}"
}
I'm evaluating gradle for replacing an ant build script and I can't manage to find a solution for creating a standard build script that correctly manages dev/prod environment.
Than ant script (it's for a java project, not android) is structured in this way:
a common script with the standard tasks (compile, build-jar, build-war)
a specific project script that includes the first one and through some properties it defines where the war task should pick the correct files
Our project structure/taks allows to override entire directories in the final war. Let consider this example:
the dev configuration is the standard one and lays int the dir webcontent
there are multiple prod conf (one of each specific installation, we do not have more that 10 different prod configs) all under the prod dir (i.e. *prod/conf1*m prod/conf2, etc)
The ant build has the dev_build task as the prod_conf1_build one, the prod_conf2_build one ,etc
the XXX_build task do the same things:
specify the parent (it's a project property) dir that contains the env dir/files
call the same ant taks that build the war using the property specified in the calling task
I'm trying to do the same in gradle but it seems that even calling a taks from another one it creates some problem (i.e. the task is always up to date)
Here is the script (it's a working draft, I'm learning gradle) that tries to do the same but it's not working when I call war_prod the taks does nothing since it reports up-to-date
apply plugin: 'java'
apply plugin: 'war'
apply plugin: 'eclipse'
project.ext.envdir = ""
eclipse {
jdt {
sourceCompatibility = 1.8
targetCompatibility = 1.8
javaRuntimeName = "jdk-1.8.x"
}
}
// In this section you declare where to find the dependencies of your project
repositories {
maven {
url 'http://artifactory.zzzz.priv/artifactory/libs-release'
url 'http://artifactory.zzzz.priv/artifactory/libs-snapshot'
credentials {
username 'xxxx'
password 'yyyy'
}
}
}
// In this section you declare the dependencies for your production and test code
dependencies {
// The production code uses the SLF4J logging API at compile time
compile 'org.slf4j:slf4j-api:1.7.18'
// Declare the dependency for your favourite test framework you want to use in your tests.
// TestNG is also supported by the Gradle Test task. Just change the
// testCompile dependency to testCompile 'org.testng:testng:6.8.1' and add
// 'test.useTestNG()' to your build script.
testCompile 'junit:junit:4.12'
}
task war_prod {
project.ext.envdir='prod/conf1'
project.ext.envdir=project.ext.envdir.replaceAll('\\\\',File.pathSeparator)
project.ext.envdir=project.ext.envdir.replaceAll('/',File.pathSeparator)
tasks.war.execute()
}
war {
eachFile {
println 'endir' + project.ext.envdir
println 'evaluating' + it
FileTree tree = fileTree(dir: project.ext.envdir)
tree.visit { FileVisitDetails file->
if (!file.file.isDirectory()) {
println '\tFileVisitDetails relpath ' + file.relativePath
println '\tsourcepath ' + it.file.getAbsolutePath()
println '\tcontains ' + it.file.getAbsolutePath().contains(project.ext.envdir)
if (it.relativePath == file.relativePath && !it.file.getAbsolutePath().contains(project.ext.envdir)) {
it.exclude()
println '\texcluding ' + it
} else {
if (it!=null) {
//println '\tincluding ' + it
}
}
}
}
}
from 'prod/conf1'
}
Can anyone point me in the right direction for creating a correct gradle script?
Is there a specific gradle way to build war files with prod/dev configurations (where the configuration is represented by some dir and files)?
In such scenarios task rules might be very useful. Basic idea is to keep configurations in a structured way and use a general task to build a war file with a configuration defined. Please have a look at build.gradle below:
apply plugin: 'war'
repositories {
mavenCentral()
}
tasks.addRule("Pattern: buildWar<ENV>") { String taskName ->
if (taskName.startsWith('buildWar')) {
def env = (taskName - 'buildWar').toLowerCase()
if (env in ['dev', 'prod',]) {
task(taskName, type: War) {
println "Configuring env: $env"
from("src/main/conf/$env") {
into("conf")
}
}
} else {
println "Invalid env: $env, skipping."
}
}
}
The buildWarENV rule defined here is pretty self descriptive. It accepts two environments dev and prod and prepares war file by taking configuration from appropriate folder. You can find a demo here. In case of questions, just ask.
P.S. Gradle has a bit different working model than ant, start with the basics. And what's important, never run a task from within other task.
I'm using Gretty to run my web application via gradle appRun. I'm also using the Gradle Asset Pipeline plugin to compile my Less files to CSS.
I want to integrate with Gretty's Fast reload feature so that when I change a Less file, it automatically compiles it and copies the CSS to the in-place web-app.
I have implemented a solution using Gretty's onScanFilesChanged setting in my build.gradle file:
buildscript {
dependencies {
classpath 'org.akhikhl.gretty:gretty:1.2.4'
classpath 'com.bertramlabs.plugins:asset-pipeline-gradle:2.7.0'
classpath 'com.bertramlabs.plugins:less-asset-pipeline:2.7.0'
}
}
apply plugin: 'java'
apply plugin: 'eclipse'
apply plugin: 'war'
apply plugin: 'org.akhikhl.gretty'
apply plugin: 'com.bertramlabs.asset-pipeline'
dependencies {
// ...
}
assets {
excludes = ['bootstrap/**']
}
war.dependsOn assetCompile
gretty {
servletContainer = 'tomcat8'
enableNaming = true
contextPath = '/'
// This affects the war task as well
webappCopy {
from 'build/assets', { into 'stylesheet' }
}
afterEvaluate {
prepareInplaceWebAppFolder.dependsOn assetCompile
}
scanDir "src/assets"
fastReload "src/assets"
onScanFilesChanged { List<String> files ->
if (files.findAll { it.endsWith ".less" }.size() > 0) {
assetCompile.compile()
}
}
}
Is there a neater way to do this that doesn't involve so much code in the build.gradle file?
The behavior you are describing is what Gretty is doing by default. The documentation states:
fastReload: When set to true (the default), webAppDir folder (which is typically src/main/webapp) is set as being fast-reloaded. That means: whenever
some files within webAppDir are changed, these files are copied into
running web-app without web-app restart.
Means, any change in a subdirectory of src/main/webapp will trigger Gretty's fast reload, but any change which is made outside of this directory triggers a server restart.
A smarter approach to your problem would be overriding the output path of gradle assetsCompile to a subdirectory of src/main/webapp, or to hook a copy task to it like this in your build.gradle file:
task copyAssets(type: Copy) {
from buildDir + '/assets'
into webAppDir + '/stylesheet'
}
copyAssets.shouldRunAfter assetsCompile
I'm having a lot of trouble figuring out how to compile a GRPC Java server. I looked all over the grpc.io website and closest thing I found was this: http://www.grpc.io/docs/#quick-start , where I run
../gradlew -PskipCodegen=true installDist to build, and
./build/install/grpc-examples/bin/hello-world-client to run the client. This all works, but only for the hello-world tutorial. I have no idea how to do this for my own client/server. I'm able to generate the client/server protobufs using the .proto file. I looked in their readme and Java tutorial and couldn't find out how to compile the actual server (and client) after I write them
https://github.com/grpc/grpc-java/blob/master/examples/README.md
(can't link java tutorial because I dont have enough reputation). Unless there's documentation im missing, does anyone know how to compile a server and client that implements the GRPC classes generated from the .proto file? I did spend a fair amount of time searching. Any advice is much appreciated, thanks.
Also have a similar problem, ensure that:
You configured correctly the protoc, that will be downloading the executable and configure it as an environment variable of your OS.
The build.gradle file, make sure to include protobuf-gradle-plugin:
apply plugin: 'java'
apply plugin: 'idea'
apply plugin: 'com.google.protobuf'
ext.grpcVersion = '1.0.1'
ext.protobufVersion = '3.0.2'
buildscript {
repositories { mavenCentral() }
dependencies {
classpath 'com.google.protobuf:protobuf-gradle-plugin:0.8.0' }
}
repositories {
mavenCentral()
}
dependencies {
compile "com.google.protobuf:protobuf-java:${protobufVersion}"
compile "io.grpc:grpc-all:${grpcVersion}"
}
protobuf {
protoc { artifact = "com.google.protobuf:protoc:${protobufVersion}" }
plugins { grpc { artifact = "io.grpc:protoc-gen-grpc-java:${grpcVersion}" } }
generateProtoTasks { ofSourceSet('main')*.plugins { grpc { } } }
}
idea {
module {
sourceDirs += file("${protobuf.generatedFilesBaseDir}/main/java");
sourceDirs += file("${protobuf.generatedFilesBaseDir}/main/grpc");
}
}
Your proto file:
syntax = "proto3";
package com.company.project;
service CompanyService{
rpc call(RequestMessage) returns (ResponseMessage) {}
}
Run gradle clean build, and it should generate your service and client classes for CompanyService.
The idea plugin, is jut for telling IntelliJ to recognize the src/main/proto as a source set.
To actually execute the client and server, you will need to make the implementation, mentioned in the tutorial for gRpc, and then apply the application plugin, in order to generate correctly the executable jar
//build.grdle code...
apply plugin: 'application'
mainClassName = 'com.company.project.MainClass'
jar { manifest { attributes('Main-Class' : mainClassName) } }
I had a similar issue but solved it using it in Gradle by adding the 'application' plugin. Before I was using the 'java' plugin and I could only generated a jar file. After switching to the 'application' plugin there is a gradle task similar to the gRPC example.
./gradlew installDist
And now to start your server you can run something similar to this:
./build/install/your-project/bin/your-server
To actually generate the Java classes off my .proto files I needed to run './gradle build' and also include the source generated using the sourceDir element you can see in the build.gradle below.
This is the full build.gradle file.
apply plugin: 'application'
apply plugin: 'com.google.protobuf'
apply plugin: 'idea'
buildscript {
repositories {
mavenCentral()
}
dependencies {
classpath 'com.google.protobuf:protobuf-gradle-plugin:0.7.6'
}
}
repositories {
jcenter()
}
dependencies {
compile 'io.grpc:grpc-all:0.14.0'
}
mainClassName = "com.domain.service.YourMainClass"
protobuf {
protoc {
artifact = "com.google.protobuf:protoc:3.0.0-beta-2"
}
plugins {
grpc {
artifact = 'io.grpc:protoc-gen-grpc-java:0.14.0'
}
}
generateProtoTasks {
all()*.plugins {
grpc {}
}
}
}
idea {
module {
sourceDirs += file("${projectDir}/build/generated/source/proto/main/grpc");
sourceDirs += file("${projectDir}/build/generated/source/proto/main/java");
}
}
I am new to gRPC so any improvments to my Gradle file would be appericated.
This question has been answered on groups.google.com by 'Eric Anderson':
The JAR only has your code in it. It sounds like you want to make a "fat" jar which includes all your dependencies. You can do something like this:
jar {
from {
configurations.compile.collect {
it.isDirectory() ? it : zipTree(it)
}
}
}
Note that that isn't gRPC-specific; it's just working with Gradle. There may be alternatives, such as a quick Googling returned gradle-fatjar-plugin.