I followed the solution given here: upload artifact to artifactory using gradle, but it is not working for me.
Here is my code:
apply plugin: 'artifactory'
apply plugin: 'maven-publish'
/* Specify the repositories to be used for downloading artifacts */
repositories {
maven {
url = "${artifactory_contextUrl}/repo"
}
}
/* Define the repository (in artifactory) where artifactoryPublish task should publish */
artifactory {
contextUrl = "${artifactory_contextUrl}"
publish {
repository {
repoKey = "${artifactory_repoKey}"
username = "${artifactory_user}"
password = "${artifactory_password}"
}
}
defaults {
publications ('integTestPublish')
}
}
publishing {
publications {
integTestPublish(MavenPublication) {
setArtifactId(project.name + '-' + integTestJar.appendix)
artifact integTestJar.archivePath
}
}
}
The error is:
> Could not find method defaults() for arguments [build_3a14r6bjhcvi883gaucf1jd8f0$_run_closure1_closure5_closure9#71bc1581] on root project 'samples'.
GAV used for artifactory plugin is:
classpath group: 'org.jfrog.buildinfo', name: 'build-info-extractor-gradle', version: '2.1.0'
What is wrong here ? can someone point me to DSL/API doc of artifactory plugin version 2.1.0
My gradle version is 1.11
As explained in the user guide, artifactory plugin of version 2.X is intended to work with maven plugin, not maven-publish plugin. For working with publications please use artifactory-publish plugin of version 2.X, or, preferably, use version 3.0 of com.jfrog.artifactory plugin. It is intended to work with maven-publish publications and compatible both with Gradle 1 and Gradle 2.
This answer contains a fully working example.
Related
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.
I can publish artifacts using the JFrog Bintray Gradle plugin, but am getting a 405 when trying to use maven-publish plugin.
All the examples I've found use the JFrog plugin.
My Bintray repo is a Maven one and would like to stay with the generic maven plugin for uploads.
I noticed the JFrog plugin uses a repo url like https://api.bintray.com/content/<USERNAME>/artifact-sandbox/.
If I can use maven-publish should it use the same url?
publishing {
publications {
myPublication(MavenPublication) {
from components.java
groupId 'samples'
artifactId 'gradle-project'
version '.1'
}
}
repositories {
maven {
url = "<REPO-URL>"
credentials {
username = '<USERNAME>'
password = '<BINTRAY-KEY>'
}
}
}
}
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
}
}
}
I am integrating gradle to archiva.I was able to build the jar of the project successfully , but craeting inside build/libs.
I want to add this jar to my archiva repository internal after build. please guide me
my archiva repo
http://localhost:8080/repository/internal/
See Gradle docs:
Chapter 34. Maven Publishing - describes how to use 'maven-publish' gradle plugin to define publications and repositories.
34.4. Performing a publish - contains full example of additions to build.gradle:
apply plugin: 'java'
apply plugin: 'maven-publish'
group = 'org.gradle.sample'
version = '1.0'
publishing {
publications {
mavenJava(MavenPublication) {
from components.java
}
}
}
publishing {
repositories {
maven {
url "http://localhost:8080/repository/internal/"
credentials {
username repoUser
password repoPassword
}
}
}
}
Add credentials {} section if you need to supply username/password for repository. repoUser and repoPassword are variables defined somewhere else. For example, apply gradle-properties-plugin and define these variables in gradle-local.properties:
repoUser=jsmith
repoPassword=secret
Make sure not to commit this file into source code repository.
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).