We Keep Coding

using gradle plugin from flatDir source

How to amend Gradle plugins {} management repository for custom plugins? is not duplicated in this post, because it does not cover use of flatDir.
Question
How do I use a Gradle plugin defined in a local JAR, using the new plugin {} semantics, instead of the deprecated apply() semantics?
Current Status
Not having any resolution, after posting the question and searching at considerable length, I filed an issue, wondering whether this use, which ought to be common and straightforward, is unsupported, either by design or oversight, within Gradle's revised plugin semantics.
Unfortunately, my report was closed, with no useful information provided.
I requested clarification in a new issue, but am still waiting.
I am frustrated, having expected that the community would be interested in at least discussing this problem.
If you can contribute information, please do so.
First Update
Following the clarification about the new style for configuring plugin sources, I updated my settings.gradle file to open with the following block. However, I regret that I see no improvement by this change alone. (For the plugin id field referenced in the build.gradle file, I have tried both the global ID published in the JAR metadata, and the basename of the JAR fie. Both fail equally.)
pluginManagement {
repositories {
gradlePluginPortal()
jcenter()
flatDir {
dirs 'lib`'
}
}
}
The documentation explains how to use custom repositories, but appears to overlook the case of a trivial flat directory.
Second Update
I get some improvement if I add a version number to the JAR file and to the corresponding statement in the plugins {} block. In this case, the message becomes:
Plugin [id: 'plugin-id', version: '1.0.0'] was not found in any of the following sources:
- Gradle Core Plugins (plugin is not in 'org.gradle' namespace)
- Plugin Repositories (could not resolve plugin artifact 'plugin-id:plugin-id.gradle.plugin:1.0.0')
Searched in the following repositories:
Gradle Central Plugin Repository
BintrayJCenter
flatDir(/absolute/path/to/lib)
In this case, the directory is added to the list of sources searched.
It is strange that the .gradle.plugin suffix is being appended to my ID in the printed artifact. It is also strange that adding the version number to what is being searched for affects the list of places being searched.
So my project still cannot build. I appreciate any further help.
Original Background
I placed a JAR file containing a custom plugin definition in the lib directory of a project. With the build.gradle build file as below, the build runs successfully.
buildscript {
repositories {
flatDir {
dirs 'lib'
}
}
}
apply plugin: 'plugin-id'
However, the apply() semantics are deprecated, favoring a plugins {} block, so I tried updating the build file as below.
plugins {
id 'plugin-id'
}
repositories {
flatDir {
dirs 'lib'
}
}
I understand that the plugins {} contents can draw from the repositories {} definitions.
However, the change creates a failure:
* What went wrong:
Plugin [id: 'plugin-id'] was not found in any of the following sources:
- Gradle Core Plugins (plugin is not in 'org.gradle' namespace)
- Plugin Repositories (plugin dependency must include a version number for this source)
Keeping the plugin {} block but moving the repositories {} block back into a leading buildscript {} block does not resolve the error. That is, the error persists even if I revert to the earlier version only replacing the apply() statement with the plugin {} block.
Finally, it has no effect to add to the repositories {} block a dependencies { classpath: ':jarname' } block, which some sources suggest is necessary, though I don't know why it would be.

This works. Tested with gradle 6.3.
build.gradle:
plugins {
id 'plugin-id'
}
settings.gradle:
pluginManagement {
buildscript {
repositories {
flatDir {
dirs '/plugin-folder/build/libs'
}
}
dependencies {
classpath ':plugin-jar:0.0.1'
}
}
}
Update: I just found out today that it is possible to have your plugin jar resolved without using the dependencies block above. In that case you should name your plugin jar as [plugin-id].gradle.plugin[-version].jar. Note that the [-version] part is optional and plugin-id.gradle.plugin.jar will also work.
NB: Flat dir repositories are discouraged and local maven repo folder should be used instead. Especially in the case when you want to override locally an artifact which exists on a remote repo. See https://docs.gradle.org/current/userguide/declaring_repositories.html#sub:flat_dir_resolver. It seems impossible to fully move away from maven in favour of gradle, considering that installing local artifacts in a maven repo folder is not supported by gradle itself.

How can I create Gradle tasks correctly?

I'm trying to build tasks to allow me to specify my profile for my spring app using Gradle.
buildscript {
ext {
springBootVersion = '2.0.1.RELEASE'
}
repositories {
mavenCentral()
jcenter()
}
dependencies {
classpath "org.springframework.boot:spring-boot-gradle-plugin:${springBootVersion}"
}
}
plugins {
id "com.diffplug.gradle.spotless" version "3.10.0"
}
apply plugin: 'java'
apply plugin: 'org.springframework.boot'
apply plugin: 'io.spring.dependency-management'
apply plugin: 'maven'
spotless {
java {
googleJavaFormat()
licenseHeaderFile 'habicus.license.java'
}
}
group = 'com.remindful'
version = '1.0.0-SNAPSHOT'
sourceCompatibility = 1.8
repositories {
mavenCentral()
jcenter()
}
dependencies {
compile('org.springframework.boot:spring-boot-starter-jersey')
compile('org.springframework.boot:spring-boot-starter-web')
compile('org.springframework.boot:spring-boot-starter-web-services')
compile('org.springframework.boot:spring-boot-starter-websocket')
compile('org.springframework.session:spring-session-core')
compile("com.h2database:h2")
compile 'org.springframework.boot:spring-boot-starter-data-jpa'
compile group: 'com.google.guava', name: 'guava', version: '11.0.2'
testCompile 'junit:junit:4.12'
testCompile group: 'org.springframework.boot', name: 'spring-boot-starter-test', version: '2.0.1.RELEASE'
}
// TODO: Add prod profile in application-properties
task prod {
run { systemProperty "spring.profiles.active", "prod" }
}
task dev {
run { systemProperty "spring.profiles.active", "dev" }
}
// To force debug on application boot, switch suspend to y
bootRun {
systemProperties System.properties
jvmArgs=["-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=5005"]
}
tasks.bootRun.dependsOn build
bootRun.mustRunAfter dev
I have two questions:
1) Intellij highlight the tasks with yellow squiggly underline, so I'm wondering if the syntax here is wrong?
2) Do I use gradle-wrapper for something like this or just gradle? I'm trying to better understand the difference.

1) Intellij highlight the tasks with yellow squiggly underline, so I'm wondering if the syntax here is wrong?
Unfortunately, IntelliJ does not support gradle completely, for example, the ext block in the build script is not recognized correctly, so when accessing members defined throught the ext block, IntelliJ fails to resolve its definition & type.
So there's no need for panic when IntelliJ displays a yellow underline, you only need to take notice of the errors reported by the gradle command. If gradle build says OK, then everything is fine.
Meanwhile, IntelliJ is unable to resolve third-party plugins statically, therefore it is also unable to recognize tasks and Task classes added by these plugins. In this case, it will also show this yellowish underline complaining about something like cannot infer argument type.
The solution is to refresh all Gradle projects, by clicking the refresh button on the gradle panel, and if your build script is written correctly, these underlines will most probably vanish. This is because IntelliJ embedds with gradle using the Gradle Tooling API, and during the gradle sync process (fired by refresh all Gradle projects), third-party plugins got resolved and the whole project object model is built, so that IntelliJ would know that nothing is wrong with your tasks.
If gradle build fails, then the problem is with your own build script. On how to write gradle build scripts & tasks correctly, see Authoring Tasks - Gradle User Manual.
2) Do I use gradle-wrapper for something like this or just gradle? I'm trying to better understand the difference.
The Gradle wrapper is explained in the official userguide. To be brief, I would quote:
The Wrapper is a script that invokes a declared version of Gradle, downloading it beforehand if necessary.
So if you don't have a wrapper script in your project, you should execute gradle wrapper to generate one, and then commit it to your VCS. After that, wherever you previously execute gradle <task> in the command line, you can/should replace it with ./gradlew <task> (in *nix environment) or gradlew.bat <task> (in Windows).
The main difference between using the gradle command directly from the command line and the gradle wrapper script is, that the gradle wrapper script will download the gradle binary and uses it to execute gradle builds if no installed gradle binary is found, while using the the gradle command will only result in an error in such case.
Also, when someone else is using your project, he/she can simply clone the repo and run ./gradlew build (in *nix) or gradlew.bat build (in Windows) and your project will build fluently and successfully, regardless of whether he/she has previously installed a gradle distribution.

Gradle: find resolved version of a dependency imported with +

I want to print the last version of a dependency in gradle.
I added my dependency in this way :
compile 'test:test:+'
now I want to print the version of my dependency, because I want to know which version I'm using.
I'm using it in this way :
gradle dependencyInsight --configuration compile --dependency test:test
But my output is this :
+--- test:test:+ -> project : (*)
Is there anyway I can get the real version of my dependency and not the +?

Within app module's build.gradle I've imported Square's Moshi library as follows:
dependencies {
compile 'com.squareup.moshi:moshi:+'
}
Then I executed following command in terminal:
./gradlew app:dependencyInsight --configuration compile --dependency com.squareup.moshi:moshi
Here's the output that I've received:

All easy, open hierarchy of view Project and see External Libraries

If you want to check the overview for all your dependencies, you can check with this command -
Solution 1-
./gradlew app:dependencies
Or
Solution 2-
If you want to check for any specific dependency.you can use gradles' build-in 'dependencyInsight : -
gradle dependencyInsight --configuration compile --dependency compile 'test:test:+'
or
Solution 3-
You can check your project .idea folder
inside your project -> .idea/libraries
there also you can see the final version of dependencies used.

You can do the following:
Use the configuration that contains your jar file
Filter for the the jar file's name
Print the results
This will print the full path as well as the version. You can extract just the jar name if needed.
task printPmdVersion << {
FileTree pmdJar = zipTree(configurations.pmd.filter {
dep -> dep.name.contains("pmd-core")
}.singleFile)
println pmdJar
}
Example of output:
ZIP '/home/user/java/gradle_user_home/caches/modules-2/files-2.1/net.sourceforge.pmd/pmd-core/5.4.1/28715c2f768b58759bb5b373365997c30ac35899/pmd-core-5.4.1.jar'

Once you have added your dependency as "compile 'test:test:+'" build the project.
Then within the "Project" folder structure hierarchy find that dependency within "External Libraries" at the bottommost of folder structure , it will along with its version there. Use that version with your dependency and re-sync/build project again.

It's not a best practice use the '+' sign to always use the latest library version because you could not be able to have a repeatable build if you need one.
I mean, if you have to checkout your previous version of your APK from your Source Control Management system (e.g. Git) that you know it works fine, if you compile today (new library version could have been release)... maybe your old friend APK that was working fine... now it doesn't work fine like your latest one.
That said I suggest you using a gradle plugin like that:
https://github.com/ben-manes/gradle-versions-plugin
You will install in your build.gradle at project level like that:
// Top-level build file where you can add configuration options common to all sub-projects/modules.
apply plugin: 'com.github.ben-manes.versions'
buildscript {
repositories {
google()
jcenter()
}
dependencies {
classpath 'com.android.tools.build:gradle:3.0.1'
classpath 'com.github.ben-manes:gradle-versions-plugin:0.17.0'
// NOTE: Do not place your application dependencies here; they belong
// in the individual module build.gradle files
}
}
allprojects {
repositories {
google()
jcenter()
}
}
task clean(type: Delete) {
delete rootProject.buildDir
}
And you'll find a new gradle task named dependencyUpdate that if you lunch it it will report you all your library versions compared with the latest ones:
------------------------------------------------------------
: Project Dependency Updates (report to plain text file)
------------------------------------------------------------
The following dependencies are using the latest milestone version:
- com.github.ben-manes:gradle-versions-plugin:0.17.0
- junit:junit:4.12
The following dependencies have later milestone versions:
- com.android.support:appcompat-v7 [26.1.0 -> 27.0.2]
- com.android.support.constraint:constraint-layout [1.0.2 -> 1.1.0-beta5]
- com.android.support.test.espresso:espresso-core [3.0.1 -> 3.0.2-alpha1]
- com.android.tools.build:gradle [3.0.1 -> 3.2.0-alpha03]
- org.jacoco:org.jacoco.agent [0.7.4.201502262128 -> 0.8.0]
- org.jacoco:org.jacoco.ant [0.7.4.201502262128 -> 0.8.0]
- com.android.support.test:runner [1.0.1 -> 1.0.2-alpha1]

Including Java library built with Gradle throws NoClassDefFoundError

I am writing a Java library and I would like to build the library with Gradle and then test it from a local test project.
I would prefer using Gradle 3.3 for my objective.
The library should be built for Java5 and higher.
So far my build.gradle looks like this:
plugins {
id 'jvm-component'
id 'java-lang'
}
repositories {
mavenCentral()
}
model {
components {
main(JvmLibrarySpec) {
sources {
java {
dependencies {
module 'commons-codec:commons-codec:1.10'
module 'org.apache.httpcomponents:httpcore:4.4.6'
module 'org.apache.httpcomponents:httpclient:4.5.3'
}
}
}
api {
exports 'io.simplepush'
}
targetPlatform 'java5'
}
}
}
The source code of the library is located in src/main/java/io/simplepush/Notification.java and depends on the dependencies stated in the build.gradle file.
Building the library with ./gradlew build works fine and generates build/jars/main/jar/main.jar.
However when I run a test project from IntelliJ (after including main.jar into the test project), I get the following runtime error:
Exception in thread "main" java.lang.NoClassDefFoundError: org/apache/http/HttpEntity.
It seems like the test project does not know about the runtime dependencies needed by my library.
I am not sure on what is the correct way to tell the test project about the dependencies of my library.
I do not want a fat jar which includes all dependencies.
Listing all dependencies in the test project itself is also not an option.
Preferably I want the library itself to tell the test project about which dependencies it needs.

The library jar which you have created does not contain any dependency information which the IDE/Gradle can then resolve to be able to compile/run the test project. I see that you are using the maven central repository so what you need to do is to publish your library to your local maven repository and in the test project just add a dependency information (no just plain jar file).
So in both library and test project build.gradle add a maven local repository config.
repositories {
mavenLocal()
mavenCentral()
}
And now you need to publish the library to local repository. As you are using the gradle 3.3 you can use the Maven Publishing.
So in the library build.gradle add a maven publishing information.
publishing {
publications {
maven(MavenPublication) {
groupId 'io.simplepush'
artifactId 'project1-sample'
version '1.1'
from components.java
}
}
}
Gradle “maven-publish” plugin makes this easy to publish to local repository automatically creating a PublishToMavenLocal task.
So you can just run
gradle publishToMavenLocal
Which will publish your library with all the dependency information into local maven repository.
And then you just need to add a library information to you test projects build.gradle
dependencies {
// other dependencies .....
module 'io.simplepush:project1-sample:1.1'
}

I solved it by changing several things.
Thanks to #Babl for pointing me in the right direction.
My new library build.gradle looks like this:
plugins {
id 'java'
id 'maven-publish'
}
sourceCompatibility = 1.5
repositories {
mavenLocal()
mavenCentral()
}
dependencies {
compile 'commons-codec:commons-codec:1.10'
compile 'org.apache.httpcomponents:httpcore:4.4.6'
compile 'org.apache.httpcomponents:httpclient:4.5.3'
}
publishing {
publications {
maven(MavenPublication) {
groupId 'io.simplepush'
artifactId 'project1-sample'
version '1.1'
from components.java
}
}
}
Now I can push the library to the local maven repository with ./gradlew publishToMavenLocal.
The build.gradle of the test project uses the application plugin and defines a main class (which is Hello in my case). Then I can run ./gradlew installDist to generate an executable file (see Application plugin docs) which puts all dependencies in the classpath and runs just fine.
group 'com.test'
version '1.0-SNAPSHOT'
apply plugin: 'java'
apply plugin: 'application'
repositories {
mavenLocal()
mavenCentral()
}
dependencies {
compile 'io.simplepush:project1-sample:1.1'
}
mainClassName = "Hello"

This specify what repositories to check to fetch the dependencies from
repositories {
mavenCentral()
}
Therefore, anything that is in the dependecies{} will be fetched from those above.
If the test project is not coupled with the library project, (#RaGe example) new test project needs to know where to take the dependency from - you need to publish it, using preferred method.
After that, your new test project needs to specify the library with the preferred configuration (compile...runtime etc) in the build.gradle dependencies{}
After that depending on IDE you need to refresh the classpath and download the dependency from the specified before repository, the transitive dependencies specified in the library dependency (in this case) will get fetched from test projects repositories{}
Library build.gradle
repositories {
mavenCentral()
}
dependencies {
module 'commons-codec:commons-codec:1.10'
module 'org.apache.httpcomponents:httpcore:4.4.6'
module 'org.apache.httpcomponents:httpclient:4.5.3'
}
test project build.gradle
repositories {
mavenCentral() repository to fetch transitives
mavenLocal() or any other repo that you published the library to
}
dependencies {
pref-conf librarygroup:name:version
}
You can use idea or eclipse plugin in gradle for gradle idea or gradle eclipseClasspath tasks to refresh it with your freshly added dependencies.
With this solution, you should not need to pack the transitive dependencies within the library,
PS. I am just confused after you said you want executable jar.

Gradle Maven plugin "install" task does not work with Android library project

I want to install android library project to local maven repository.
Here is build.gradle:
buildscript {
repositories {
mavenCentral()
}
dependencies {
classpath 'com.android.tools.build:gradle:0.5.+'
}
}
apply plugin: 'android-library'
apply plugin: 'maven'
version = "1.0.0-SNAPSHOT"
group = "com.example"
repositories {
mavenCentral()
}
android {
compileSdkVersion 18
buildToolsVersion "17.0.0"
defaultConfig {
minSdkVersion 9
targetSdkVersion 18
}
}
When I run:
gradle install -i
it gets stuck here:
Executing task ':project:installTest' due to:
Task has not declared any outputs.
Starting process 'command 'd:\android-sdk-windows\platform-tools\adb.exe''. Working directory: D:\Projects\java\....... Command: d:\android-sdk-windows\platform-tools\adb.exe install -r D:\Projects\java\.......\build\apk\project.apk
An attempt to initialize for well behaving parent process finished.
Successfully started process 'command 'd:\android-sdk-windows\platform-tools\adb.exe''
> Building > :project:installTest
So first thing I noticed is that it's trying for some odd reason to deploy it on a device as APK.
Am I doing something wrong or is it just android-library plugin not compatible with maven plugin?

Edit: Please refer to the github page (https://github.com/dcendents/android-maven-gradle-plugin) for the latest instructions and find the correct version to use. The original instructions are not suitable anymore with the latest gradle release.
Original Post:
I've modified the maven plugin to be compatible with android library projects. See the project on github: https://github.com/dcendents/android-maven-gradle-plugin
Configure your android library projects to use it:
buildscript {
repositories {
mavenCentral()
}
dependencies {
classpath 'com.github.dcendents:android-maven-plugin:1.0'
}
}
apply plugin: 'android-library'
apply plugin: 'android-maven'
Then you should be able to install aar into your local maven repository using the install task.
Hope this helps, if you find issues with the plugin please let me know on github and I'll fix it.

Elaborating on CyclingSir's answer, I propose to add a separate "installArchives" task. This should also take care of picking up your custom artifacts (e.g. sources).
apply plugin: 'maven'
task installArchives(type: Upload) {
description "Installs the artifacts to the local Maven repository."
configuration = configurations['archives']
repositories {
mavenDeployer {
repository url: repositories.mavenLocal().url
}
}
}
Note that with Gradle Android plugin v0.5.5, gradle install still tries to install something on a device.

There's an easier solution if you don't want to use a custom plugin. Instead, just recreate the install task with a different name. I called it installArchives. Add the following code to your build.gradle:
task installArchives(type: Upload) {
description "Installs the artifacts to the local Maven repository."
repositories.mavenInstaller {
configuration = configurations.default
pom.groupId = 'my.group'
pom.artifactId = 'my-artifact'
pom.version = '1.0.0'
}
}
You can now run gradle installArchives to install your aar locally.

UPDATE 2014-11-26
The answer below made sense at the time of writing, when Android Build Tools were at version 0.5.5. It is most likely outdated now and probably does not work anymore.
I have personally switched my projects to use android-maven-plugin as described in the answer above, the plugin works fine with the recent versions of Android Build Tools too.
THE ORIGINAL ANSWER FROM FEBRUARY 2014
Publishing as AAR
If you don't mind using an older version of com.android.tools.build:gradle (i.e. 0.5.4), you can use the approach described in this blogpost. Not that according to the discussion in adt-dev mailing-list, this does not work in 0.5.5.
Add the following lines to your build.gradle:
apply plugin: 'maven-publish'
// load bundleRelease task
// this will not load the task in 0.5.5
android.libraryVariants
publishing {
publications {
maven(MavenPublication) {
artifact bundleRelease
}
}
}
To publish to your local maven repo, call this command:
gradle publishToMavenLocal
Publishing as JAR
If your Android Library does not have custom resources and can be published as JAR, then you can use the following build.gradle that works even with 0.5.5.
// build JAR file
task androidReleaseJar(type: Jar, dependsOn: assembleRelease) {
from "$buildDir/classes/release/"
}
apply plugin: 'maven-publish'
publishing {
publications {
maven(MavenPublication) {
artifact androidReleaseJar
}
}
}
To publish to your local maven repo, call this command:
gradle publishToMavenLocal

I just solved the issue by defining an upload archive as described here:
Gradle documentation 52.6.2. Deploying to a Maven repository
uploadArchives {
repositories {
mavenDeployer {
repository(url: "file://${System.env.HOME}/.m2/repository/")
}
}
}
calling
gradle uploadArchives
deploys the artefact to the (in my case local) Maven repo.
I havn't found a simple and more flexible way to specify the local repo's url with e.g. mavenLocal() yet but the above suits my needs.