We Keep Coding

Plugin was not found with building gradle

Having a gradle project.
When i'm trying to build project.
buildscript {
ext {
springBootVersion = '2.2.4.RELEASE'
}
repositories {
mavenCentral()
maven {
url "https://plugins.gradle.org/m2/"
}
}
dependencies {
classpath("org.springframework.boot:spring-boot-gradle-plugin:${springBootVersion}")
classpath "gradle.plugin.org.hidetake:gradle-swagger-generator-plugin:2.9.0"
classpath "net.ltgt.gradle:gradle-apt-plugin:0.21"
}
}
plugins {
id "net.ltgt.apt-eclipse" version "0.21"
id "net.ltgt.apt-idea" version "0.15"
id "net.ltgt.apt" version "0.15"
}
I have error which is connected with plugins
Plugin [id: 'net.ltgt.apt-eclipse', version: '0.15'] was not found in any of the following sources:
How to fix it?

I was facing the same issue. In build.gradle, the paths provided for the dependencies weren't matching the folders specified. Placing the folders in the mentioned path shown in the build.gradle solved it. After that I was able to build the project without errors.

TL;DR: If you are using a current gradle version, it's fine to just drop all of the net.ltgt.apt dependencies. You will not need it anymore because, it's features are now available natively in Gradle.
More details:
From the plugin README.md (https://github.com/tbroyer/gradle-apt-plugin#readme)
The goal of this plugin was to eventually no longer be needed, being superseded by built-in features. This has become a reality with Gradle 5.2 and IntelliJ IDEA 2019.1. tl;dr: this plugin is obsolete, don't use it. If you're using Eclipse though, continue reading.
It originally did a few things to make it easier/safer to use Java annotation processors in a Gradle build. Those things are now available natively in Gradle, so what's this plugin about?
If you use older versions of Gradle (pre-4.6), you can still benefit from those features:
it ensures the presence of configurations for your compile-time only dependencies (annotations, generally) and annotation processors, consistently across all supported Gradle versions;
automatically configures the corresponding JavaCompile and GroovyCompile tasks to make use of these configurations, when the java or groovy plugin is applied.
With recent versions of Gradle (between 4.6 and 5.1), this plugin will actually only:
add some DSL to configure annotation processors; it is however recommended to directly configure the tasks' options.compilerArgs;
backport the sourceSet.output.generatedSourcesDirs Gradle 5.2 API;
configure JavaCompile and GroovyCompile tasks' options.annotationProcessorGeneratedSourcesDirectory with a sane default value so you can see the generated sources in your IDE and for debugging, and avoid shipping them in your JARs.

How to put local dependencies first when calling gradle idea?

When calling gradle idea, external dependencies are ordered first in the class path relatively to local Jar inclusions. As such :
dependencies {
compile fileTree(dir: 'libs', include:['*.jar'])
compile group: 'foo', name:'bar', version:'1.0.0'
}
will include my local jars last. This is a problem in my project as these jars' purpose is to partially overwrite the external library.
The same behavior is observed when specifying the repository as a source of dependencies using flatDir and loading the jar without fileTree. It is put last in the classpath.
I have found several mentions of the problem when researching, such as https://discuss.gradle.org/t/gradle-messes-up-the-classpath-order-in-generated-projects-when-there-are-mixed-dependency-types/13130, but no workarounds.
I suppose these exist, gradle being very customisable, but being very new to it my attempts to make one fail. How to proceed?

I'm not using IntelliJ on a regular basis but tried it in the context of this question and my impression is that gradle's idea plugin and IntelliJ's gradle plugin don't go well together. That is you should either use the idea gradle plugin and import as plain Java project or import as gradle project using IntelliJ's gradle plugin. Main reason is that the idea plugin and the IntelliJ plugin are generating slightly different iml-files (those files are holding the project dependencies - amongst others) which leads to lot of confusion when using both plugins together. As you specifically asked for the gradle idea plugin, I used this plugin and imported into IntelliJ as plain java project.
But to answer your question I found no evidence that the order of libraries on the classpath differs from the order as declared in the dependencies section of the gradle file, when using a flatDir repo. When using compile fileTree(dir: 'libs', include:['*.jar']) the order was actually broken as described in your question. That is, you should stick to using a flatDir repo.
I'm using gradle 4.9 and IntelliJ 2018.2.
This is my gradle file
apply plugin: 'java'
apply plugin: 'idea'
repositories {
jcenter()
flatDir {
dirs 'libs'
}
}
dependencies {
compile 'zzz:zzz-0.0.0'
compile 'aaa:aaa-0.0.0'
compile 'com.google.guava:guava:24.0-jre'
compile group: 'javax.websocket', name: 'javax.websocket-api', version: '1.1'
}
task wrapper(type: Wrapper) {
gradleVersion = '4.9'
distributionUrl = "http://services.gradle.org/distributions/gradle-${gradleVersion}-bin.zip"
}
In my libs folder there are two jars aaa-0.0.0.jar and zzz-0.0.0.jar both are copies of guava-24.0-jre.jar. That is all guava classes are present in both jars as well. As zzz:zzz-0.0.0 is the first dependency in the gradle file, the expectation would be that guava classes are being loaded from zzz-0.0.0.jar instead of guava-24.0-jre.jar or aaa-0.0.0.jar. I used the following main class to test this:
package test;
import com.google.common.math.LongMath;
public class Test {
public static void main(String[] args) throws Exception {
System.out.println(LongMath.class.getProtectionDomain().getCodeSource().getLocation().toURI());
}
}
And the output when running it from IntelliJ is
file:/C:/ws/gradle-idea-test/libs/zzz-0.0.0.jar
That is the com.google.common.math.LongMath class is indeed being loaded from the local libs/zzz-0.0.0.jar instead of the guava-24.0-jre.jar.
I noticed that the list of external dependencies in IntelliJ doesn't show the local libraries. And even more confusing the libraries are ordered alphabetically and don't reflect the actual order on the classpath which might be quite confusing:
To get the actual order of elements on the classpath you will have to look in the module dependencies section in the module settings ("Open Module Settings" > "Project" > "Modules" > "Dependencies Tab") which looks like this:
As you can see the dependencies are listed in correct order and include the local libraries as well. The order of libs in this dialog is basically the same as in the generated iml-file.
When using the IntelliJ gradle plugin instead of gradle's idea plugin, IntelliJ basically behaved the same way but the generated iml-file looked different and the external libraries were displayed in a different format. But there was no difference regarding the classpath order.

JacocoTestReport doesn't work after update gradle version 3.0 [duplicate]

Version 2.3.3 of the Android Gradle Plugin was able to provide merged unit test and connected test code coverage data. In version 3.0.0, this capability is broken because each of the test types use a different and incompatible version of JaCoCo. Rafael Toledo provided a Medium blog post showing how to make this work with 2.3.3. I have provided a Github repo that illustrates the working code and the broken code in a few branches. The repo documentation provides a Readers Digest description of the problem. At this point I am convinced the Gradle Plugin team owns the issue and will file a bug shortly. My questions are:
1) Can anyone suggest a viable workaround? (there is a suggested fix by Carmen Alvarez posted to the Medium blog post but I get no joy from it.)
2) Can someone point me to instructions on how to hack and build the Gradle Android Plugin to test out a potential fix? (I found the answer to this one at http://tools.android.com/build/gradleplugin )

According to Android Plugin DSL Reference that contributes Android specific things:
To specify the version of JaCoCo you want to use, you now need to include it as a buildscript dependency in your project-level build.gradle file, as follows:
buildscript {
dependencies {
classpath "org.jacoco:org.jacoco.core:<jacoco-version>"
...
}
}
Previously Android Plugin had
android {
jacoco {
version = "<jacoco-version>"
}
}
According to Gradle JaCoCo Plugin documentation that contributes task of type JacocoReport:
The JaCoCo plugin adds a project extension named jacoco of type JacocoPluginExtension, which allows configuring defaults for JaCoCo usage in your build.
jacoco {
toolVersion = "<jacoco-version>"
}
And so here is modification for your https://github.com/pajato/acc that allows to align versions so that execution of ./gradlew clean jacocoTestReport succeeds:
buildscript {
dependencies {
classpath "org.jacoco:org.jacoco.core:0.7.9"
}
}
allprojects {
apply plugin: "jacoco"
jacoco {
toolVersion = "0.7.9"
}
}

Switching dependencies in Gradle depending on platform

I am trying to get Gradle to select different dependencies in my multiproject build based on whether I am building for desktop or for Android. I have a common subproject (a library) I am trying to reuse. However, I cannot get Gradle to correctly switch dependency configurations.
My main settings.gradle simply includes all the dependencies:
// /settings.gradle
rootProject.name = 'myProject'
include 'androidUI'
include 'reusableLibrary'
include 'desktopUI'
Now both androidUI and desktopUI specify reusableLibrary as a dependency:
// /androidUI/build.gradle and /desktopUI/build.gradle
apply plugin: 'java'
dependencies {
compile project(path: ':reusableLibrary', configuration: 'desktop')
}
reusableLibrary itself specifies two configurations, because its dependencies are different whether it's building on desktop or Android:
// /reusableLibrary/build.gradle
apply plugin: 'java'
configurations {
desktop {
extendsFrom compile
}
android {
extendsFrom compile
}
}
dependencies {
// Just examples, the real list is longer.
// The point is that h2database is only included on desktop,
// and ormlite is only included on Android.
android 'com.j256.ormlite:ormlite-jdbc:5.0'
desktop 'com.h2database:h2:1.4.192'
}
This looks fine to me. But when I compile either desktopUI or androidUI, I can see that although the dependencies of reusableLibrary are being included on the classpath in the manner I desire, the actual JAR provided by reusableLibrary itself is not included. This of course causes the build to fail. I suspect I'm not setting up reusableLibrary correctly; I'm not clear on what the configurations {} blocks do.
Why aren't the compiled items in reusableLibrary being included on the classpaths of the UI projects? And what is the canonical way to include platform-specific dependencies in this manner?

The original configuration is pretty close to right. The key is to understand this dependency graph from the Gradle Java plugin's documentation:
This is a visualization of the Java plugin's various dependency configurations, which is Gradle-ese for "list of dependencies." When you add compile lines to a dependencies {...} block, you're adding Dependency elements to the compile dependency list.
The default dependency configuration is special; it is the one included by a compile project("path") line unless a different one is chosen with the configuration: argument. This means that when you build the library, the runtime dependency list (which includes the compiled jar from the library itself) is added to the classpath of the client project.
The original configuration creates two new nodes, desktop and android in this graph, and couples them both to compile by using extendsFrom. They are not otherwise connected to the graph! Now the problem with the original configuration is apparent: by switching the upstream project to either of these, it is missing the compiled code from runtime. This explains the classpath omission.
The solution is a bit more subtle than just aiming desktop and android at runtime. In order to ensure that everything is correctly decoupled when we add tests, we need one extra layer of dependency configurations to keep testCompile from indirectly depending on runtime. Additionally, the library's source code itself may need things on its classpath just to typecheck; we can use compileOnly for this. The end solution looks like this:
configurations {
desktopCompile
androidCompile
compileOnly.extendsFrom desktopCompile
testCompile.extendsFrom desktopCompile // Assuming tests run on the desktop
desktop {
extendsFrom desktopCompile
extendsFrom runtime
}
android {
extendsFrom androidCompile
extendsFrom runtime
}
}
dependencies {
androidCompile "some.android:dependency"
desktopCompile "other.desktop:dependency"
}

Dagger 2 Annotation Processor Not Running for Java Gradle IntelliJ Project

I'm playing around with a Gradle java project, and I'm having a difficult time getting annotation processor's to run. For some reason when I run an intellij configuration (pictured below), the annotation processors aren't running. I'm assuming this is because the configuration has the Make command configured to run before launch. The annotation processors seem to run when assemble or build is called.
The issue is reproducible when calling ./gradlew clean make. I don't have that issue when calling ./gradlew clean assemble, or ./gradlew clean build. What's the best practice for getting around this?

IntelliJ needs Annotation Processing enabled for the project. Here is an image that details where you can enable Annotation Processing for IntelliJ:
Preferences > Build, Exection, Deployment > Compiler > Annotation Processors > Check "Enable annotation processing"

make sure that Annotation Processing is enabled for your project (as described by #spierce7)
also make sure that apply plugin: 'idea' is in your build.gradle
sample build.gradle snippet:
plugins {
id "net.ltgt.apt" version "0.5"
}
apply plugin: 'java'
apply plugin: 'idea'
...
dependencies {
compile 'com.google.dagger:dagger:2.10'
apt 'com.google.dagger:dagger-compiler:2.10'
}
from: https://github.com/tbroyer/gradle-apt-plugin (github for net.ltgt.apt plugin)
IntelliJ IDEA
When the idea plugin is applied, the idea task will auto-configure the
generated files to enable annotation processing in intelliJ IDEA.
When using the Gradle integration in IntelliJ IDEA however, rather
than the idea task, you'll have to manually enable annotation
processing: in Settings… → Build, Execution, Deployment → Compiler →
Annotation Processors, check Enable annotation processing and Obtain
processors from project classpath. To mimic the Gradle behavior and
generated files behavior, you can configure the production and test
sources directories to build/generated/source/apt/main and
build/generated/source/apt/test respectively and choose to Store
generated sources relative to: Module content root.
Note that starting with IntelliJ IDEA 2016.1, you'll have to uncheck
Create separate module per source set when importing the project.
In any case, the idea plugin has to be applied to the project.
An alternative, starting with IntelliJ IDEA 2016.3, is to delegate the
IDE build actions to Gradle itself:
https://www.jetbrains.com/idea/whatsnew/#v2016-3-gradle

You are not applying the APT plugin
buildscript {
repositories {
jcenter()
}
dependencies {
classpath 'com.android.tools.build:gradle:1.3.0'
classpath 'com.neenbedankt.gradle.plugins:android-apt:1.4'
// NOTE: Do not place your application dependencies here; they belong
// in the individual module build.gradle files
}
}
And
apply plugin: 'com.neenbedankt.android-apt'
Or for the core, its pure-Java alternative:
https://plugins.gradle.org/plugin/net.ltgt.apt
Also try using apt instead of providedCompile