I have a Java application which uses a custom library named com.abc.XYZLogging.
This library is dependent on org.springframework:spring-context:4.3.7.RELEASE and org.slf4j:slf4j-api:1.7.10.
So the dependency diagram is like this:
com.abc.XYZLogging
|---org.springframework:spring-context:4.3.7.RELEASE
|---org.slf4j:slf4j-api:1.7.10
|---log4j:log4j:1.2.17
All the artifacts are present in the correct locations and in the same repo. However gradle picks up only the first level com.abc.XYZLogging and it does not pickup any other dependency in the hierarchy.
I use gradle 4.2 and Oracle JDK 1.8.144. This happens even when I invoke gradle clean build from command line and via Buildship plugin in eclipse.
Is there any dependency mapping missing in my artifactory ?
Example of how to configure a repository based on Artifactory to behave like in a Maven style using artifactory's own plugin, as sometimes just pointing to artifactory as usually done is not enough.
This is just an example for getting libs from artifactory, to publish extra config is necessary. Also this example is for a multi-build where the build script is separated from the artifactory config. More at: https://www.jfrog.com/confluence/display/RTF/Gradle+Artifactory+Plugin
This first example is getting the plugin from artifactory itself, and the second for jcenter.
buildscript {
dependencies { classpath "org.jfrog.buildinfo:build-info-extractor-gradle:latest.release" }
repositories {
maven {
credentials {
username = artifactory_username
password = artifactory_password
}
url "https://.../artifactory/libs-release"
}
}
}
allprojects{
apply plugin: org.jfrog.gradle.plugin.artifactory.ArtifactoryPlugin
artifactory {
resolve {
contextUrl = "https://.../artifactory"
repoKey = 'libs-global'
username = artifactory_username
password = artifactory_password
}
}
}
buildscript {
repositories {
jcenter()
}
dependencies {
classpath "org.jfrog.buildinfo:build-info-extractor-gradle:latest.release"
}
}
apply plugin: "com.jfrog.artifactory"
OR simpler, in newer versions
plugins {
id "com.jfrog.artifactory" version "latest.release"
}
so you can use blocks like:
artifactory {
resolve {
contextUrl = "https://.../artifactory"
repoKey = 'libs-global'
username = artifactory_username
password = artifactory_password
}
}
Related
When I run "gradle build", it generates a build/libs/project-version.war file which is able to run by itself with "java -jar" command. But when I run "gradle artifactoryPublish", it saves on the artifactory repository a "project-version-plain-war" file which does not have tomcat embedded.
I am following this instruccions https://www.jfrog.com/confluence/display/JFROG/Gradle+Artifactory+Plugin
The lines added to the gradle.build are something like this:
plugin "maven-publish"
plugin "com.jfrog.artifactory"
artifactory {
...
}
subprojects {
plugin "war"
group = group
version = version
publishing {
publications {
MavenPublication(MavenPublication) {
from components.web
}
}
repositories{
maven { url "https://artifactory-server" }
}
}
}
help is appreciated
Using from components.web means that you are publishing the artifact produced by the war task. You need to publish the artifact produced by the bootWar task. You can do so by changing the publication to use artifact bootWar instead:
publishing {
publications {
MavenPublication(MavenPublication) {
artifact bootWar
}
}
repositories{
maven { url "https://artifactory-server" }
}
}
This is described in the reference documentation for Spring Boot's Gradle plugin.
I have a huge java multimodule application which uses gradle to manage build and dependencies.
In one of the modules let's say module1 the project is using gretty plugin
module1/build.gradle
plugins{
id 'org.gretty'
}
gretty is having a transitive dependency on ch.qos.logback:logback-classic:1.1.3
I want to bump the logback version to the latest. For that I have tried below solutions
dependencies {
// 1 try
implementation 'ch.qos.logback:logback-classic:1.2.6'
// 2nd try
implementation ('ch.qos.logback:logback-classic:1.2.6') {
force = true
}
// 3rd try
constraints {
implementation('ch.qos.logback:logback-classic:1.2.6') {
because 'some xyz reason'
}
}
}
But none of this is having any impact on logback version. Need some suggestion now
What you have done so far is for application dependencies, not build dependencies. To change or add additional dependencies to the build itself, use the buildscript block. So for you case, to bring in a more recent version of Logback:
buildscript {
repositories {
maven {
url "https://plugins.gradle.org/m2/"
}
mavenCentral()
}
dependencies {
classpath 'ch.qos.logback:logback-classic:1.2.6'
}
}
https://docs.gradle.org/current/userguide/tutorial_using_tasks.html#sec:build_script_external_dependencies
You can then invoke the buildEnvironment task to view the dependencies of the build.
I have a multi-module project which supports maven and gradle builds hence it contains pom.xml files along side with build.gradle. I'm working on a demo and I would like to show how to build and deploy to nexus the same project using either gradle or maven. That's why I have two different build systems in case you wonder why.
You may see the project structure below.
You may look into the code here.
I've configured the gradle maven-publish plugin in order to publish all modules to my local nexus repository however when I run gradle publish I hit this error:
Execution failed for task ':publishMavenJavaPublicationToMavenRepository'.
> Failed to publish publication 'mavenJava' to repository 'maven'
> Artifact machinery-config-0.0.1.jar wasn't produced by this build.
The issue is related with having the publishing section within $rootDir/build.gradle.
It's confusing maven-publish somehow which is trying to publish an artifact that doesn't exist machinery-config-0.0.1.jar, machinery-config is the name of the rootProject.
One workaround could be to remove the publishing section from the rootProject and duplicate it in the sub-projects. I don't like that approach cuz I will end up with a lot of duplicated code.
Could you point me out a better way to use maven-publish within a multi-module project ?
After some digging I realized that I had two issues:
publishing section was outside of subprojects section, then gradle tried to deploy an artifact using rootProject.name ignoring the included modules.
group & version properties were outside subprojects therefore deployed artifacts had undefined as version number, e.g machinery-config-core-undefined.jar
In order to fix issue number two I had moved group & version into subprojects section.
My build also produces a BOM artifact hence I need two publications from components.java and from components.javaPlatform, so I wrote this script gradle/ext/publish-common.gradle which exports two functions I will use later on both publications to keep code duplication at bay.
def pom(it) {
it.licenses {
license {
name = 'The Apache License, Version 2.0'
url = 'http://www.apache.org/licenses/LICENSE-2.0.txt'
}
}
it.developers {
developer {
id = 'eljaiek'
name = 'Eduardo Eljaiek'
email = 'eduardo.eljaiek#gmail.com'
}
}
it.scm {
connection = 'scm:git:git://github.com/eljaiek/machinery-config.git'
developerConnection = 'scm:git:git#github.com:eljaiek/machinery-config.git'
url = 'https://github.com/eljaiek/machinery-config'
}
}
def nexusRepository(it) {
it.url = version.endsWith('SNAPSHOT') ? project.nexusSnapshotsUrl : project.nexusReleasesUrl
it.credentials {
username project.nexusUser
password project.nexusPasswd
}
}
ext {
pom = this.&pom
nexusRepository = this.&nexusRepository
}
I had added from components.javaPlatform publication into machinery-config-dependencies/build.gradle in order to deploy the BOM artifact
apply plugin: 'maven-publish'
apply from: "$rootDir/gradle/ext/publish-common.gradle"
publishing {
publications {
mavenBom(MavenPublication) {
from components.javaPlatform
pom { x -> pom(x)}
}
}
repositories {
maven { x -> nexusRepository(x) }
}
}
apply from: "$rootDir/gradle/ext/publish-common.gradle" will aplly the script I wrote, this is required in order to import pom() and nexusRepository() functions into my build script.
To deploy from components.java artifacts I had added a publishing section in subprojects under if (it.name != 'machinery-config-dependencies') statement into $rootDir/build.gradle
apply plugin: 'ru.vyarus.pom'
apply from: "$rootDir/gradle/ext/publish-common.gradle"
publishing {
publications {
mavenJava(MavenPublication) {
from components.java
pom { x -> pom(x)}
}
}
repositories {
maven { x -> nexusRepository(x) }
}
}
I had used Gradle POM plugin instead of maven-publish. It provides maven's dependencies declaration simplicity and implicitly applies maven-publish plugin.
See the code here
References
Extract common methods from Gradle build script
The Java Platform Plugin
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.
How to Publish (deploy) local (.war .jar) files to Artifactory using Gradle version 1.12?
Dear all
I'm having a hard time trying to make this because of the older version of Gradle that I can not change because specifications, I would be very gratefully if someone can help me with this code.
What I have done till now:
buildscript {
repositories {
maven { url 'http://jcenter.bintray.com' }
}
dependencies {
classpath(group: 'org.jfrog.buildinfo', name: 'build-info-extractor-gradle', version: '3.0.1')
}
}
apply plugin: com.jfrog.artifactory-upload'
artifactory {
contextUrl = 'http://my.domain.com/artifactory/'
resolve {
repository {
repoKey = 'remote-deploy'
maven = true
}
}
}
NOTE: I don't know how to set my the local files to be uploaded but I read that I can use something like this "$rootDir\build\lib\buildProject.war"
With the suggestions I made this changes in my code:
apply plugin: 'com.jfrog.artifactory-upload'
apply plugin: 'maven-publish'
apply plugin: 'maven'
apply plugin: 'distribution'
buildscript {
repositories {
maven { url 'http://jcenter.bintray.com' }
}
dependencies {
classpath(group: 'org.jfrog.buildinfo', name: 'build-info-extractor-gradle', version: '2.2.5')
}
configurations {
published
}
}
artifactoryPublish.skip = true
task sourceJar(type: Jar){
from file("build/libs/"+project.archivesBaseName2+".jar")
classifier = 'sources'
}
artifacts{
archives sourceJar
published sourceJar
}
artifactory {
contextUrl = 'http://www site com/artifactory/'
publish {
contextUrl = 'http://www site com/artifactory/' //The base Artifactory URL for the publisher
//A closure defining publishing information
repository {
repoKey = 'jarDeploy'
username = 'user'
password = 'pass'
}
defaults{
//This closure defines defaults for all 'artifactoryPublish' tasks of all projects the plugin is applied to
properties{
//Optional closure to attach properties to artifacts based on a list of artifact patterns per project publication
mavenJava 'org.jfrog:*:*:*#*', key1: 'val1'
publicationName 'group:module:version:classifier#type', key1:'value1', key2:'value2'
}
publishBuildInfo = true //Publish build-info to Artifactory (true by default)
publishArtifacts = true //Publish artifacts to Artifactory (true by default)
publishPom = true //Publish generated POM files to Artifactory (true by default).
publishIvy = false //Publish generated Ivy descriptor files to Artifactory (true by default).
}
}
resolve{
contextUrl = 'http://www site com/artifactory/' //The base Artifactory URL for the resolver
repository{
repoKey = 'jarDeploy' //The Artifactory (preferably virtual) repository key to resolve from
username = 'user' //Optional resolver user name (leave out to use anonymous resolution)
password = 'pass' //The resolver password
maven = true //Resolve Maven-style artifacts and descriptors (true by default)
}
}
}
Now I see Build publications on Arctifactory but are empty no files to download
[buildinfo] Properties file path was not found! (Relevant only for builds running on a CI Server)
Creating properties on demand (a.k.a. dynamic properties) has been deprecated and is scheduled to be removed
in Gradle 2.0. Please read http://gradle.org/docs/current/dsl/org.gradle.api.plugins.ExtraPropertiesExtensi
on.html for information on the replacement for dynamic properties.
Deprecated dynamic property: "publishPom" on "task ':api:artifactoryPublish'", value: "true".
Deprecated dynamic property: "publishIvy" on "task ':api:artifactoryPublish'", value: "false".
Deprecated dynamic property "publishPom" created in multiple locations.
Deprecated dynamic property "publishIvy" created in multiple locations.
:webapp:artifactoryPublish
Deploying build info to: http://www site com/artifactory/api/build
Build successfully deployed. Browse it in Artifactory under http://tc-scm.bitnamiapp.com/artifactory/webapp/
builds/leadgnome-services/1423748387989/2015-02-12T09:39:45.642-0400/
BUILD SUCCESSFUL
Artifactory plugin uploads a file set that is prepared by another plugin. Considering your version of Gradle, that will probably be the maven plugin.
maven plugin creates and populates a configuration (usually called archives) which contains the files it built. This configuration needs to be specified in the artifactory closure.
You can see number of examples here.
P.S. The 3.0.1 version of the plugin won't probably work with such and old Gradle. Please check the docs for the compatibility matrix.