I have an android project where we just upgraded to gradle wrapper 4.9-all and using gradle tools plugin com.android.tools.build:gradle:3.3.0-alpha04. I have different build variants. The build types using proguard and minifyEnabled=true are failing because they can't find the /libs folder:
Caused by: com.android.tools.r8.utils.AbortException: Error: /Users/username/projects/projectA/path-to-project/libs, java.io.FileNotFoundException:/Users/username/projects/projectA/path-to-project/libs (Is a directory)
at com.android.tools.r8.utils.Reporter.failIfPendingErrors(Reporter.java:116)
at com.android.tools.r8.utils.Reporter.fatalError(Reporter.java:74)
at com.android.tools.r8.dex.ApplicationReader.read(ApplicationReader.java:119)
at com.android.tools.r8.dex.ApplicationReader.read(ApplicationReader.java:86)
at com.android.tools.r8.R8.run(R8.java:251)
at com.android.tools.r8.R8.run(R8.java:229)
at com.android.tools.r8.R8.lambda$run$0(R8.java:134)
at com.android.tools.r8.utils.ExceptionUtils.withCompilationHandler(ExceptionUtils.java:55)
If i set minifyEnabled=false, then the build completes successfully.
I have googled and haven't found anything specific to this issue. Is anyone else running into this?
[SOLVED] It was a proguard issue. In my proguard-rules.pro file, there was a setting of
-injars libs
The intent was to apply to all jars in the libs folder.
Well...somewhere between upgrading to gradle-wrapper 4.9
the behavior with proguard changed. Now I have to explicitly specify the
jar files.
-injars libs/a.jar
-injars libs/b.jar
-injars libs/c.jar
etc...
Related
I migrated my Gradle project config for Kotlin-script usage: now I have both build.gradle and build.gradle.kts and can switch between them configuring settings.gradle:
project(':myProject').buildFileName='build.gradle.kts'
The issue is kts build.gradle.kts is not properly highlited: it does not resolve dependencies, says version = 123 is not a valid word and so on.
I use Idea Ultimate 2017.1.3 and kotlin-plugin 1.1.2. What's the issue? Deleting build.gradle doesn't help either.
gradle-script-kotlin project files are highlited correctly.
The issue probably was I used incorrect gradle version. I recreated the project specifying gradle version 3.5 and now it works fine. Probably I should use gradle wrapper to prevent the same issue occurence on other developers' machines.
tl;dr: I cannot configure IntelliJ to generate the java files in the same directory as gradle
I have a small project which uses the immutables annotation processor.
It works as expected in the gradle command line build, but I cannot get IntelliJ to output the generated files to the same directory.
The full project is available on GitLab
Gradle config:
I use the folowing gradle plugins:
gradle-idea plugin which handles the idea configuration
gradle-apt-plugin which provides the apt configuration and handles the compile-class path and idea config related to annotation processing (if also the idea plugin is applied)
relevant parts of the build-script (link to the full listing):
apply plugin: 'java'
apply plugin: "net.ltgt.apt"
apply plugin: 'idea'
dependencies {
def immutablesVersion = '2.3.9'
compileOnly "org.immutables:value:$immutablesVersion:annotations"
compileOnly "org.immutables:encode:$immutablesVersion"
apt "org.immutables:value:$immutablesVersion"
}
when I start ./gradlew build everything is as expected:
The source file DataEncoding.java is processed an the generated java-file DataEncodingEnabled.java ends up in
/build/generated/source/apt/main under the expected package com.tmtron.immutables.data
and the generated file is also compiled to a .class file
In IntelliJ I activate the annotation processing as suggested by the gradle-apt-plugin docs:
Then I execute ./gradlew clean to make sure, that the previous files are gone and then I click Build - Build Project in IntelliJ.
The annotation processor is executed, but the problem is that the generated java file ends up in the wrong location:
It is in: /build/generated/source/apt/main/build/generated/source/apt/main/com.tmtron.immutables.data
the bold part is redundant.
What am I doing wrong and how can I set it up correctly, so that IntelliJ and gradle generate the files in the same directory?
Notes:
I have of course already tried to just leave the "Production sources dir" in the IntelliJ annotation configuration empty, but his does not work: then it automatically uses "generated" and I also end up with a wrong path.
IntelliJ version 2016.3.4
Now https://github.com/tbroyer/gradle-apt-plugin states:
The goal of this plugin was to eventually no longer be needed, being superseded by built-in features. This is becoming a reality with Gradle 5.2 and IntelliJ IDEA 2019.1.
So:
dependencies {
compile("com.google.dagger:dagger:2.18")
annotationProcessor("com.google.dagger:dagger-compiler:2.18")
compileOnly("com.google.auto.factory:auto-factory:1.0-beta6")
annotationProcessor("com.google.auto.factory:auto-factory:1.0-beta6")
compileOnly("org.immutables:value-annotations:2.7.1")
annotationProcessor("org.immutables:value:2.7.1")
}
compileOnly is necessary if you use annotations, compile if you use classes, annotationProcessor introduced in Gradle 4.6.
To enable processing specific compile task:
compileJava {
options.annotationProcessorPath = configurations.annotationProcessor
}
To disable:
compileTestJava {
options.compilerArgs += '-proc:none'
}
UPDATE 2.2019
since Gradle 5.2 there is an easy way to do it - see gavenkoas answer
UPDATE 5.2018
The easiest way, I know of is to use the apt-idea plugin
Just activate the plugin in the build.gradle file:
plugins {
id 'java'
id 'net.ltgt.apt-idea' version "0.15"
}
and then add the annotation processors to the annotationProcessor configuration:
final DAGGER_VER = '2.16'
dependencies {
implementation "com.google.dagger:dagger:${DAGGER_VER}"
annotationProcessor"com.google.dagger:dagger-compiler:${DAGGER_VER}"
}
Test-project on GitHub: ex.dagger
(using IntelliJ 2018.1.4, Gradle 4.7)
ORIG ANSWER
There's a simple workaround using the parent-dir which works fine in IntelliJ 2016.3.4
Production sources directory: ../main
Test sources directory: ../test
Now gradle and IntelliJ will generate the code to the same directories.
Fixed in GitLab project V0.0.2
see also: apt-gradle-plugin issue#35
Hey there everyone I had the same issue and found a clean way of solving this issue.
I am using two libraries that require annotation processing (Lombok and MapStruct).
Also my IntelliJ is 2019.1 (update yours in case it's older) and Gradle 5.2.1.
First let's configure IntelliJ:
Disable Annotaion Processing in Settings, since we're going to delegate everything to Gradle:
Delegeate IDE actions to Gradle:
Last step is to configure your dependencies correctly in Gradle.
Dependencies section in Gradle:
Now you can execute the Build and Run from both command line and IDE.
Cheers!
2019.2.x
Disable annotation processor of intellij
add, build directory in your gradle build.gradle file
then run your gradle task to generate build file classes, example gradle compileJava
File -> project structure -> Modules -> Main Folder || remove exclude and add as source
And project should find all annotation and generated source file. Hope it helps.
I have the following project structure
datatypes/
build.gradle
src/main/thrift/service.thrift
service/
build.gradle
/src/main/java/ServiceImpl.java
build.gradle
settings.gradle
I am using yodle/gradle as a gradle plugin to generate java sources from thrift and compiling those. The sources and jar files are being generated in datatypes as expected.
in service/build.gradle, I have a dependency defined as:
dependencies {
compile project(':datatypes')
}
Running gradle build works perfectly fine; my only issue is while working in idea. After importing this as gradle module, I can't get the types defined in thrift to be recognized in ServiceImpl.java.
How do I get idea to include the jar in datatypes/build/libs/ as dependency for service?
Thanks!
The issue really is that the default thrift generated java source path set by yodle/griddle plugin is inside the build/ folder. I just added the following in my datatypes/build.gradle
thriftGenDir = 'src/main'
and now the java code is generated in src/main/gen-java which is picked up as source for dataypes by idea, and uses it to define types for anyone who depends on datatypes.
I have a apache_mod.c which is supposed to be updated for continuous integration
I would like to use Maven to compile this module for generating apache_mod.so
Then packaging it in .jar
I can't find how to compile the apache_mod.c with Maven to get apache_mod.so because it seems that an Apache2 module needs to be compiled with apxs2 command which already put the *.so file in /usr/lib/apache2/modules.
So, do you have any idea how to compile apache_mod.c with Maven in order to get apache_mod.so to package it?
I don't think that putting *.so (shared object) into jar archive is correct solution, but to answer your question how to compile native c or c++ files using maven, you can use the native plugin http://mojo.codehaus.org/maven-native/native-maven-plugin/. Also, the apxs2 is just wrapper around gcc, so you don't have to use apxs2 to build apache module. You can just use gcc.
Seems I tried to do two things in one.
Generating *.so and packaging it are two different things.
So here is the process :
Having a Maven project compiling and generating *.so
Having a Maven Assembly to package *.so and others files and *.war
Seems Boris has been definitly right. Using Maven native plugin allow to compile *.c in *.so then Maven assembly plugin is used to package it.
Thanks for all.
Using Grails 1.2.0 and the latest Spock 0.4-SNAPSHOT (as of 01/28/2010 10:18 EST) I'm getting compilation errors that the Groovy compiler is unable to find:
org.apache.commons.httpclient.Cookie
and
org.apache.commons.httpclient.NameValuePair
No matter what I've tried (adding it as a dep in the plugin, adding it as a dep in the app) it returns the exact same error. This happens in the console using, specifically, grails test-app.
I've also tried deleting the .grails directory, the .ivy2 directory and even my .m2 directory to clean out the dependencies in case that is the problem.
The jars are actually HTML files in my repository because of this Maven bug: http://jira.codehaus.org/browse/MNG-4428