I have a simple plugin with greet task doing some 'Hello World' print.
plugins {
id 'java-gradle-plugin'
id 'groovy'
id 'maven-publish'
}
group = 'standalone.plugin2.greeting'
version = '1.0'
gradlePlugin {
plugins {
greeting {
id = 'standalone.plugin2.greeting'
implementationClass = 'standalone.plugin2.StandalonePlugin2Plugin'
}
}
}
publishing {
publications {
maven(MavenPublication) {
groupId = 'standalone.plugin2.greeting'
version = '1.0'
from components.java
}
}
}
Now, I have runner application to just run the greet task
buildscript {
repositories {
mavenLocal()
}
dependencies {
classpath 'standalone.plugin2.greeting:standalone-plugin2:1.0'
}
}
apply plugin: 'standalone.plugin2.greeting'
With apply plugin natation it works OK, but when I use plugins notation instead like this:
plugins {
id 'standalone.plugin2.greeting' version '1.0'
}
it doesn't work.
The error message is:
* What went wrong:
Plugin [id: 'standalone.plugin2.greeting', version: '1.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 'standalone.plugin2.greeting:standalone.plugin2.greeting.gradle.plugin:1.0')
Searched in the following repositories:
Gradle Central Plugin Repository
What is the difference? According to documentation apply plugin is old and should not be used.
Before the introduction of the plugins block, plugin dependencies had to be resolved in the same way as regular project dependencies using a combination of repositories and dependencies. Since they need to be resolved before running the actual build script, they need to be defined in the special buildscript block:
buildscript {
repositories {
// define repositories for build script dependencies
}
dependencies {
// define build script dependencies (a.k.a. plugins)
}
}
repositories {
// define repositories for regular project dependencies
}
dependencies {
// define regular project dependencies
}
Once the dependencies were resolved, they could be applied using apply plugin:.
By default, the new plugins block just resolves the plugins from the Gradle Plugin Repository. This is a regular Maven repository, so it can be used using the old way, too:
buildscript {
repositories {
maven {
url "https://plugins.gradle.org/m2/"
}
}
}
In your case, the plugin only exists in mavenLocal, so the plugins block cannot resolve it, as it only looks into the Gradle Central Plugin Repository. You may use the pluginManagement block to resolve plugins from custom repositories.
As described in the article linked above, it is necessary to create a link between the plugin identifier (used inside the plugins block) and the Maven coordinates that provide the respective plugin. To create this link a marker artifact following a specific convention must be published. The Gradle Plugin Development Plugin automatically publishes this marker artifact if used in combination with the Maven Publish Plugin.
Related
I'm a beginner in gradle, using version 4.8.
Whatever I do , the plugins are never found. I get this error message:
Plugin [id: 'org.jetbrains.kotlin.jvm', version: '1.3.20'] 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 'org.jetbrains.kotlin.jvm:org.jetbrains.kotlin.jvm.gradle.plugin:1.3.20')
Searched in the following repositories:
Gradle Central Plugin Repository
No matter how many repositories I add, it seems it is only looking in "Gradle Central Plugin Repository"
My gradle.build file:
buildscript {
repositories {
mavenCentral()
maven {
url "https://plugins.gradle.org/m2/"
}
}
dependencies {
classpath "org.jetbrains.kotlin:kotlin-gradle-plugin:1.3.20"
classpath "org.jetbrains.kotlin.jvm:kotlin-gradle-plugin:1.3.20"
}
}
plugins {
id 'java'
id 'org.jetbrains.kotlin.jvm' version '1.3.20'
id 'kotlin2js' version '1.3.20'
}
Can you help me?
Try the following gradle.build configuration:
buildscript {
repositories {
mavenCentral()
}
dependencies {
classpath "org.jetbrains.kotlin:kotlin-gradle-plugin:1.3.20"
}
}
plugins {
id 'java'
}
apply plugin: 'kotlin2js'
repositories {
mavenCentral()
}
When you include the plugin by id, it seems Gradle wants to retrieve the plugin from the Gradle plugin portal, but the Kotlin plugin is not there, it's part of the buildscript dependency. Using it with the apply plugin works. You can also find a slightly different working example here.
I had similar problem because i forgot about proxy settings like systemProp.https.proxyHost and systemProp.http.proxyHost and etc. that was set in ~/.gradle/gradle.properties.
I fixed configuration and plugin was successfully dowlnloaded
Check gradle.properties and try to add correct proxy settings if you behind firewall or escape this settings if you not.
you need to add repository mavenCentral() to the buildscript dependencies.
for example: kotlin-gradle-plugin:1.3.20. also the documentation hints for that.
Go to your project and then to the Gradle script. In Gradle, Go to Setting.Gradle and change the Fist Bitray Url to https://plugins.gradle.org/m2/.
I am currently having a problem when publishing a Gradle build to a snapshot Artifactory repository where 'SNAPSHOT' is not being resolved to a timestamp. The jars can be found on the repo but are in the format of '1.0.1-SNAPSHOT.jar' instead of e.g. '1.0.1-20180420.112216-1.jar'. This is causing problems when other builds depend on the project in question. We currently have Maven builds which are pushing to the same repo without any problems.
I am using the maven-publish and com.jfrog.artifactory plugins. It is worth mentioning that I don't have a lot of Gradle experience.
Relevant pieces from build.gradle:
apply plugin: 'java'
apply plugin: 'maven-publish'
apply plugin: 'com.jfrog.artifactory'
artifactory {
contextUrl = ${rep.url}
publish {
ext.systemProperties = System.getenv()
println "Publishing using this user: ${systemProperties.artifactory_user}"
println "Publishing to this repo: ${systemProperties.artifactory_repo}"
repository {
repoKey = "${systemProperties.artifactory_repo}"
username = "${systemProperties.artifactory_user}"
password = "${systemProperties.artifactory_password}"
maven = true
}
defaults {
publications('mavenJava')
}
}
}
publishing {
publications {
mavenJava(MavenPublication) {
from components.java
}
}
}
relevant from gradle-wrapper.properties:
distributionUrl=https\://services.gradle.org/distributions/gradle-4.0.2-bin.zip
Environment variables come from Jenkins and are the same used in our maven builds.
I don't see where you actually set your jar name in the code at all. The Gradle doc for the Maven Publishing plugin tells you how you can customize the publication identity of your artifact:
publishing {
publications {
mavenJava(MavenPublication) {
groupId 'org.gradle.sample' // Modify the artifact group
artifactId 'project1-sample'// Modify the artifact name
version '1.1' // Modify the artifact version
from components.java
}
}
}
If you are not overriding these values in the publishing closure as shown above, the default values of the project are being used for naming the artifact which is defined by the group and version properties of your project. The default version value is version '1.0-SNAPSHOT' if you start a Gradle project from scratch in IntelliJ for example.
The following code should help you to resolve your issue:
publishing {
publications {
mavenJava(MavenPublication) {
version 'your_time_stamp'
from components.java
}
}
}
If a have a custom plugin which handles the building and deploying of a specific component, where do I list the dependencies (other components in my system) which are required for the build?
Dependencies for your Gradle plugins should be listed in the buildscript portion of the build.gradle file. See this chapter of the User Guide, which also has an example:
buildscript {
repositories {
jcenter()
}
dependencies {
classpath "com.jfrog.bintray.gradle:gradle-bintray-plugin:0.4.1"
}
}
apply plugin: "com.jfrog.bintray"
If your custom plugin depends on jar files on your local machine, I gather that you need to add those files as a "flatDir" repository in the repositories entry, as described here:
repositories {
flatDir {
dirs 'lib1', 'lib2'
}
}
I have a Gradle project which does a couple of orthogonal things:
Compile and run some Java.
Generate and publish an artifact.
This artifact is nothing to do with the Java; it's generated by a custom JavaExec task. However, the auto-generated POM (from the Maven plugin) seems to include the wrong dependencies. Question: How can I prevent this?
My build.gradle looks something like this:
apply plugin: "java"
apply plugin: "maven"
configurations {
foo // Custom configuration for the artifact I want to build and publish
}
// Dependencies for Java configurations (nothing to do with foo)
dependencies {
compile "foo:foo:1.1"
testCompile "bar:bar:2.2"
}
// Custom task
task generateFoo(type: JavaExec) {
ext.outputFile = new File(buildDir, "foo.bar")
...
}
artifacts {
foo file: generateFoo.outputFile, builtBy: generateFoo
}
uploadFoo {
repositories {
mavenDeployer { ... }
}
}
I invoke Gradle like this:
./gradlew uploadFoo
AFAICS, the foo configuration is unrelated to the Java configurations. So I expect the published POM to list no dependencies. However, I observe all the unrelated dependencies listed.
The Gradle docs for the Maven plugin hint at dependency mapping with conf2ScopeMappings, but I'm entirely unclear what (if anything) I should be doing with this.
Note: I'm using Gradle wrapper 1.6; I'll be trying the latest to see if that makes a difference...
I managed to setup similar configuration with both maven and maven-publish gradle plugins.
In my case I was using custom Jar task with custom configuration, but it should work because the artifacts { ... } are used in both cases.
With maven plugin, your build.gradle would look like:
apply plugin: "java"
apply plugin: "maven"
configurations {
foo // Custom configuration for the artifact I want to build and publish
}
// Dependencies for Java configurations (nothing to do with foo)
dependencies {
compile "foo:foo:1.1"
testCompile "bar:bar:2.2"
}
// Custom task
task generateFoo(type: JavaExec) {
ext.outputFile = new File(buildDir, "foo.bar")
...
}
artifacts {
foo file: generateFoo.outputFile, builtBy: generateFoo
}
uploadFoo {
repositories {
mavenDeployer {
pom.scopeMappings.with {
mappings.clear()
addMapping(300, configurations.foo, 'runtime')
}
pom.artifactId = 'other artifact id than main jar'
...
}
}
}
This solution was inspired by following thread:
http://gradle.1045684.n5.nabble.com/pom-generation-and-inherited-dependencies-td1436197.html
Note the line:
addMapping(300, configurations.foo, 'runtime')
You can add other configurations as well, or use other maven scope than the 'runtime' scope.
300 stands for priority, which is not significant in this case.
Advantage of this solution is that we have quite fine control over dependencies and their mappings. Disadvantage would be that this will not work for the install task. We would need to setup different poms for the install task, which might be possible, but it is beyond my knowledge.
Alternative with usage of maven-publish plugin:
apply plugin: "java"
apply plugin: "maven-publish"
configurations {
foo // Custom configuration for the artifact I want to build and publish
}
// Dependencies for Java configurations (nothing to do with foo)
dependencies {
compile "foo:foo:1.1"
testCompile "bar:bar:2.2"
}
// Custom task
task generateFoo(type: JavaExec) {
ext.outputFile = new File(buildDir, "foo.bar")
...
}
artifacts {
foo file: generateFoo.outputFile, builtBy: generateFoo
}
publishing {
publications {
foo(MavenPublication) {
from new org.gradle.api.internal.java.JavaLibrary(\
configurations.api.artifacts.toArray()[0], \
configurations.api.allDependencies)
artifactId 'other artifact id than main jar'
}
}
repositories {
maven { ... }
}
}
gradle tasks will give you possible publish commands:
publish - Publishes all publications produced by this project.
publishFooPublicationToMavenLocal - Publishes Maven publication 'foo' to the local Maven repository.
publishFooPublicationToMavenRepository - Publishes Maven publication 'foo' to Maven repository 'maven'.
publishToMavenLocal - Publishes all Maven publications produced by this project to the local Maven cache.
...
The advantege of maven-publish alternative is that it will work for both local and remote maven repositories. Disadvantage may be a fact that we are using the internal API which may change in future and that all dependencies are mapped to the 'runtime' maven scope. Also the MavenPublication snippet would be much more verbose and more internal API would be used if we would like to use some other maven scope or apply some scope mapping.
I am using Gradle 1.10
I have configured Gradle to publish project artifact using new Maven Publisher Plugin, unfortunately this plugin has problem with dependency in generated pom.xml - dependencies has scope runtime instead of compile.
My configuration is like this:
apply plugin: 'maven-publish'
publishing {
publications {
mavenCustom(MavenPublication) {
from components.java
}
}
repositories {
maven {
url "https://api.bintray.com/maven/codearte/public/fairyland"
credentials {
username = bintrayUser
password = bintrayKey
}
}
}
}
Publishing was simple with one command:
gradle publish
How to achieve this in old (working) way? Is possible to automate project taging when project is released?
Ok, I figured it out:
apply plugin: 'maven'
uploadArchives {
repositories {
mavenDeployer {
name = 'Codearte Public Repository'
repository(id: 'codearte-repository', url: 'https://api.bintray.com/maven/codearte/public/fairyland'){
authentication(userName: bintrayUser, password: bintrayKey)
}
}
}
Uploading with command:
gradle uploadArchives
The fact that all POM dependencies have runtime scope is a known limitation of the new, incubating maven-publish plugin. Until this gets fixed, you can either fix it up yourself by using the publication.pom.withXml hook, or fall back to the maven plugin. Both plugins are documented in the Gradle User Guide.
Tagging is an entirely different question. You can either use one of the third-party Gradle SCM plugins or call out to a command line tool (e.g. with an Exec task).