My company proxy/firewall settings are blocking jcenter and mavencentral etc, therefore, I can't get Gradle custom plugins from GitHub.
I'm using gradle 4.7 and still using that old way of getting plugins with buildscript{} - which is Gradle 1.x. I would like to use plugins{} and just put id's inside that block but I can't because of the default repository is trying to fetch it from.
Is there a way to amend plugins repo? Maybe in init.gradle or a cmd arg?
Or maybe just add another one to look at. I found a few links but those already expired and my last resort would be just to check the source code. I hope there is a simple answer to this.
Gradle 2.1 and higher want to use this
plugins {
id "de.undercouch.download" version "3.4.3"
}
Gradle 1.x and 2.0 using this at the moment
buildscript {
repositories {
mynexusrepo()
}
dependencies {
classpath 'de.undercouch:gradle-download-task:3.4.3'
}
}
apply plugin: 'de.undercouch.download'
I found a working solution. It changed a few times already but for the 4.7 version of Gradle, this looks like a working solution.
Remember that some of the plugins need to be in GString "" !
This need to be in settings.gradle as the first block to work.
pluginManagement {
repositories {
maven { url "http://cdlnexus01:8081/nexus/content/groups/GradlePlugins/" }
maven { url "http://cdlnexus01:8081/nexus/content/groups/public/" }
maven { url "https://plugins.gradle.org/m2/" }
}
}
Related
Im have my library, for help me with spring stuff, build.gradle looks like
plugins {
id 'java-library'
id 'maven-publish'
id "io.spring.dependency-management" version "1.0.11.RELEASE"
}
dependencyManagement {
imports {
mavenBom 'org.springframework.boot:spring-boot-dependencies:2.7.0'
}
}
dependencies {
implementation 'org.springframework.boot:spring-boot-starter-data-mongodb'
}
publishing {
// Default maven publish settings
}
When publishing, Gradle generates .module files, and then if the library is used by gradle, it prioritizes .module files over .pom files
The problem is that no dependencyManagement information is written to the .module file, and so when I try to use the library in another project, I get
Could not determine the dependencies of task ':shadowJar'.
> Could not resolve all dependencies for configuration ':runtimeClasspath'.
> Could not find org.springframework.boot:spring-boot-starter-data-mongodb:.
Required by:
project : > project :database > ru.spliterash:spcore-spring-database-mongo:1.0.0-SNAPSHOT:20220714.235637-1
I can solve this problem by disabling the generation of .module files, and gradle will have to use a pom file in which the version is written, but maybe if there is some more correct solution, because it seems to me that this is not entirely correct
I have found a solution to the problem.
In new versions of gradle, this appeared as a built-in solution, and now spring dependency management plugin is not needed. In order to add a maven bom, it is enough just to write, and it will be correctly entered into the module file
dependencies {
implementation(platform('org.springframework.boot:spring-boot-dependencies:2.7.0'))
implementation(platform('org.springframework.cloud:spring-cloud-dependencies:2021.0.2'))
implementation 'org.springframework.boot:spring-boot-starter-data-mongodb'
}
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 using a dependency module-x which has may or may not have SNAPSHOT version of trivial/other dependencies. When I build the application I wanted to make sure that all the trivial/other dependencies are of release type and not SNAPSHOT as SNAPSHOT keeps changing.
build.gradle file
dependencies {
implementation 'org.my-group-x:module-x:1.2'
}
it downloads a bunch of dependencies and it may have multiple dependencies which are of SNAPSHOT typed
module-y:2.0-SNAPSHOT.jar
module-z:3.1-SNAPSHOT.jar
module-k:2.7-SNAPSHOT.jar
How I can make sure it is rejected and not added to the application? Also i dont know the dependencies to exclude it specifically.
You can exclude dependencies in build tools, see:
https://docs.gradle.org/current/userguide/dependency_downgrade_and_exclude.html#sec:excluding-transitive-deps
You can also configure the Maven repositories used in Gradle, see:
https://docs.gradle.org/current/userguide/declaring_repositories.html#sec:repository-content-filtering
Here is an example to use only release versions or only snapshot version:
repositories {
maven {
url "https://repo.mycompany.com/releases"
mavenContent {
releasesOnly()
}
}
maven {
url "https://repo.mycompany.com/snapshots"
mavenContent {
snapshotsOnly()
}
}
}
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.
I am the mantainer of the Java 8 java.time JSP tags library. I have little experience publishing libraries on my own. For the publication of this library I did some research and ended with a gradle build script that you can check in GitHub. The process is a bit clunky but it works in the end.
There seem to be a general understanding that the jcenter() repository is gaining a lot of attention. Probably because of android. Anyway I saw an encouraging blog post and decided to give it a try and migrate that library to JCenter publishing insted of Maven Central. Should be easy.
It is not, for me at least. Probably my fault as my knowledge of Maven, artifacts and all that stuff is poor. Anyway I gave it some hours of research and come up with a new gradle build to publish to my Bintray maven repository. Which, if I'm not wrong, is the first step towards publishing to JCenter.
This is what I have so far:
plugins {
id "com.jfrog.bintray" version "1.6"
}
apply plugin: 'java'
apply plugin: 'maven-publish'
group = 'net.sargue'
version = '1.1.2'
sourceCompatibility = 1.8
compileJava.options.encoding = 'UTF-8'
compileTestJava.options.encoding = 'UTF-8'
repositories {
jcenter()
}
configurations {
testCompile.extendsFrom compileOnly
}
dependencies {
compileOnly 'javax.servlet:javax.servlet-api:3.0.1'
compileOnly 'javax.servlet.jsp:javax.servlet.jsp-api:2.2.1'
compileOnly 'javax.servlet.jsp.jstl:javax.servlet.jsp.jstl-api:1.2.1'
testCompile 'junit:junit:4.12'
testCompile 'org.springframework:spring-test:4.1.7.RELEASE'
}
jar {
manifest {
attributes 'Implementation-Title': 'Java 8 java.time JSP tags',
'Implementation-Version': version
}
}
task javadocJar(type: Jar) {
classifier = 'javadoc'
from javadoc
}
task sourcesJar(type: Jar) {
classifier = 'sources'
from sourceSets.main.allSource
}
publishing {
publications {
MyPublication(MavenPublication) {
from components.java
artifact sourcesJar
artifact javadocJar
artifactId 'java-time-jsptags'
pom.withXml {
asNode().children().last() + {
resolveStrategy = Closure.DELEGATE_FIRST
name 'Java 8 java.time JSP tags'
description 'JSP tag support for Java 8 java.time (JSR-310)'
url 'https://github.com/sargue/java-time-jsptags'
scm {
connection 'scm:git:git#github.com:sargue/java-time-jsptags.git'
developerConnection 'scm:git:git#github.com:sargue/java-time-jsptags.git'
url 'git#github.com:sargue/java-time-jsptags.git'
}
licenses {
license {
name 'The Apache License, Version 2.0'
url 'http://www.apache.org/licenses/LICENSE-2.0.txt'
}
}
developers {
developer {
id 'sargue'
name 'Sergi Baila'
email 'sargue#gmail.com'
}
}
}
}
}
}
}
bintray {
user = BINTRAY_USER
key = BINTRAY_KEY
publications = ['MyPublication']
pkg {
repo = 'maven'
name = 'java-time-jsptags'
licenses = ['Apache-2.0']
vcsUrl = 'https://github.com/sargue/java-time-jsptags.git'
version {
name = project.version
desc = 'Java 8 java.time JSP tags'
gpg {
sign = true
passphrase = BINTRAY_GPG
}
}
}
}
You can find the result of the latest publication on my public Bintray maven repository. You can compare it to the files for the same version currently available on Maven Central.
Congratulations if you are reading this so far, because I haven't formulated ANY question yet. Sorry about that.
My questions:
Is the gradle build script correct and the proper/canonical way? Given that the library is quite simple I found the build script huge and clunky. It is supposed to be easier and it even has a gradle plugin. But the new script is longer than the maven central one.
What about the *.md5 and *.sha1 files? Will be generated by JCenter, Maven Central, the sync proces... or should I do it?
There is some way of testing all these without publishing an actual version of the library given that there is no unpublish capabilities on the repositories? (and for a good reason, eh? leftpad anyone?).
First, great job figuring it out. It looks good and works good.
It's bigger than the other one not because you use Bintray instead of Central, but because you use maven-publish plugin instead of maven, and being more powerful, the config is a bit more verbose. You can use Bintray (and the bintray plugin) with both maven and maven-publish, whatever you prefer.
Re testing it – you can always run a test build against your private repository (click in the Set Me Up button to get instructions on how to set up your Maven and/or Gradle to resolve from it).
Another validation will be syncing to Maven Central. It will fail if something is wrong with your package metadata.
Re md5 and sha1, we don't see a reason to store computable metadata as files on a modern distribution platform, but we send them to Maven Central when we sync.