Understanding Gradle #12 - Publishing Libraries

What is a Maven Repository and how do I publish my libraries/components to it?
🚀 Online course - Modern Gradle Fundamentals www.udemy.com/...
🏎️ Training on your Gradle topics onepiece.softw...
✨ Support with your Gradle project onepiece.softw...
💙 Follow me on Mastodon mastodon.socia...
▶️ 0:00 Publishing libraries
▶️ 0:15 Maven repository structure
▶️ 1:35 Gradle Module Metadata
▶️ 2:51 Configure publishing for library subprojects
▶️ 4:26 DSL concepts for publishing: "components"/"publications"
▶️ 6:11 Configure repositories to publish to
▶️ 6:54 Running publish tasks
▶️ 7:11 Using published versions of libraries
▶️ 8:41 Summary
💾 Example on GitHub: git.io/J1Fq1
💾 Example for using timestamp version: github.com/jjo...
Related Videos:
⏩ 08 Declaring Dependencies: • Understanding Gradle #...
⏩ 11 Capability Conflicts: • Understanding Gradle #...
⏩ 13 Aggregating Custom Artifacts: • Understanding Gradle #...
Further Readings:
📕 Setting up publishing: docs.gradle.or...
📕 Configuring Repository Credentials: docs.gradle.or...
📕 Customizing Publishing: docs.gradle.or...
📕 Consumable Configurations (Variants): docs.gradle.or...
📕 Gradle Module Metadata: docs.gradle.or...
📕 Publishing Gradle Module Metadata with Maven: github.com/jjo...

[@ShaunBurch]

This was very helpful! Especially loved the explanations and use of kts! Thank you!

[@cirline1429]

Great Video, Only Real Developers Value know it's value

[@kunwarparikshitraghav973]

excellent explaination, thanks bro

[@leonsdebnath]

Really great video!

[@user-vg7jz1sz5k]

hi
do you have videos about release version management
for how to automate version increment

[@jjohannes]

I haven't done anything on that yet. But it is an important topic related to this video. And something that often comes up with my clients or in the community. I put the topic on my list of topics for future videos.

[@Omega3131]

This video is great, but can you explain how to publish the plugins themselves? I'm trying to run Arquillian integration tests on project 'server' that uses the convention plugin 'com.my.server' and it complains that the plugin can't be found in the repositories. So I added 'mavenLocal()' to the 'dependencyResolutionManagement' repositories in its settings file and now I want to publish the plugin there. The problem I'm having is that declaring any publishing configuration on the plugin itself will actually configure the project for publishing as you've shown, while I want to configure the plugin for publishing.
I tried to do this configuration on the build file of the plugins project itself. One problem here is that now it publishes all the plugins, including the parent plugins project, and that they will all have the same version. Another is that I end up with the groupId being 'com.my.server' and the artifactId being 'com.my.server.gradle.plugin' (the file name is 'com.my.server.gradle'), so now I have duplication of the 'com.my' part. I'm confused as to the roles of the file name vs. the 'group = "com.my"' configuration.
I would like to have the following:
- the file name shouldn't have the 'com.my' part, just "server.gradle", if it's even possible and correct (I thought defining the group name to 'com.my' will do the trick)
- the publishing location in the local maven repo will be to '.m2/repository/com/my/server' and not '.m2/repository/com/my/server/com.my.server.gradle.plugin' or just '.m2/repository/server', which are 2 results I'm getting as I play around with this
- the plugin declarations of 'server' should use 'id "com.my.server" version "1"' and not 'id "server" version "1"'
- be able to define the version of each of the convention plugins and not have them share the same version
As you can see, I'm confused about where to declare things and what name gets copied to where when dealing with plugins. Would be very grateful for any help.

[@jjohannes]

Hi @Omega3131, it's a bit hard for me to understand your full setup from this comment. So I share a few pointers that I hope can help you figure out the issues you are having:
For using plugins from a repository, you should define the repository in *pluginManagement { repositories.maven(...) }* (not dependencyResolutionManagement, which is for repositories that contain libraries you want to use in your code). Also, instead of publishing to mavenLocal(), you can directly include the plugin build using *pluginManagement { includeBuild(...) }* See also my explanation here: ua-cam.com/video/Ajs8pTbg8as/v-deo.html
I wrote this guide on Gradle plugins that shows how to write and publish them (using different languages). Maybe that helps to clarify some things: github.com/jjohannes/gradle-plugins-howto
Regarding the group (com.my...): This can be confusing indeed. In Gradle, plugins have two things: (1) the *Plugin ID* and (2) The *group* + *name* coordinates when you publish. (1) is a specific Gradle plugins concept, (2) is the general identification of components in Maven repositories as explained in this video (technically, Gradle plugins are Jars with class files and metadata inside like any other Java library).
When you use the Kotlin DSL to write plugins, the *file name* is the *Plugin ID* . The *group* is whatever you define in the *build.gradle.kts* of your plugins build. If you want different groups/versions, you need to split up your plugins into multiple Gradle (sub)projects.
When you publish, one Jar can contain multiple plugins and then these all have the same "group" and "version". In addition, Gradle publishes a so-called "Marker" for each plugin. This is only a POM file. Here the group is computed by Gradle based on the plugin ID. This is so that Gradle can find plugins in repositories only by ID. E.g., if you write *plugins { id("my.published.plugin") version "1.0" }* Gradle can find the plugin in the repository although you never give it the "group" + "name" for the Jar file that contains the plugin. See: docs.gradle.org/current/userguide/plugins.html#sec:plugin_markers
The Markers *do not* contain the plugins. They only point Gradle to the Jar that contains plugins and several markers can point to the same Jar with multiple plugins inside.

[@Omega3131]

@@jjohannesThanks! The naming really is confusing. I will try to create an issue on your repo with my setup.

[@amitverma7545]

Here you define manual version but how we can increment this version automatically

[@jjohannes]

That's a very good question. The best solution I know of is generating a timestamp yourself and set that as version. For example:
*version = "1.0-${SimpleDateFormat("yyyyMMddHHmmssSSS").format(Date())}"*
The tricky part is to use the same timestamp for the whole build if you publish multiple modules. The most compact way to achieve that is to set the version in the *root project* and then use that in all the subprojects.
Add a *build.gradle.kts* to the root:
*import java.text.SimpleDateFormat*
*import java.util.Date*
*version = "1.0-${SimpleDateFormat("yyyyMMddHHmmssSSS").format(Date())}"*
Use that version in all the subprojects, e.g. in *my-java-base.gradle.kts* for the example in this video:
*group = "org.example.my-app"*
*version = rootProject.version*
I shared a full example here: github.com/jjohannes/gradle-demos/tree/main/publish-with-timestamp-version

[@amitverma7545]

@@jjohannes thanks a lot it worked for me the only part needed is my nexus policy allow version to publish with 1.0.0-SNAPSHOT what changes need to do in your script so that every time it's incremented