Let's Discuss Publishing

Help/Discuss
1

Coming up on needing to start publishing directly to Maven Central due to the Bintray sunset. Our main project is currently using uploadArchives/MavenDeployer in order to publish already built artifacts, including POMs to OSSH snapshots. This is accomplished by loading up a configuration, and then setting that on uploadArchives. Easy peasy.

It’s a pretty straight shot to just wire the credentials and stuff for OSSHR proper and pop the nexus staging release plugin in, but I figured I’d look into publishing and get upgraded to doing it proper.

Wow, I had no idea what I was in for. Is it just me or does the publishing system, and maven-publish, not feel very idiomatic Gradle? It’s got all this fancy stuff going on with components and variants and meta, but as soon as you want to do something custom, even something very simple but requiring a little flexibility, the whole thing crashes down on you:

  • Doesn’t work with configurations best I can tell(can’t figure out how to get it to lazy resolve their artifacts)
  • Does work with task outputs(?!)
  • Seems to hang everyone up with the dynamic task name, lack of DSL dependsOn, and a frustrating inability to get things configured outside of the configuration phase(I can’t toss it in a doLast apparently or everything explodes)
  • Doing anything custom seems to require delving into Component extensions and/or custom plugins(has to be a plugin the docs say). It’s not super clear if this is a viable path forward or just going to end up a time sink.
  • Seems SUPER opinionated about workflow; a throwback to yester-Gradle

I mean, I’ve written some plugins. Gone spelunking into the Gradle source depths(and Bintray plugin, and Grails plugins, and etc etc). But I don’t think anything has frustrated me more with Gradle than trying to get Publishing to do something outside its narrow imagination.

Searching the forums for potential solutions I mostly ran across people who threw in the towel and went back to uploadArchives or scripts external to Gradle!

So, publishing has been the new hotness for, what, almost a decade now? It really does feel like a throwback to when Gradle had tons weird rough edges baked into the DSL due to a dogmatic use-case perspective(sorry, I had to rework this sentence and this was the best I could come up with…). IIRC correctly a focus over the past few years was breaking out of the “Conservative Java Shop” box. Is the legacy publishing, deprecated for as far back as my Gradle memory goes, every really going away? Is it telling that it hasn’t?

Tomorrow, like those who came before me(such as the one attempting something seemingly simple like publishing a dynamic list of RPM files), I’m going to fall back on uploadArchives and get back to working on stuff that produces value :confused:

2

Just a weird idea, but maybe it would be a tad more productive if you do less ranting and more describing your use-case and what problems you have with realizing it. Then maybe someone could actually willing and be able to help you getting things done properly. Even if I would want to help you, I couldn’t from this post, as it does not really bear any identifiable information other than you being frustrated. :wink:

3

For this, the closest I can suggest is that each artifact of a publication can be configured with builtBy, removing the need to add dependencies to the generated publication tasks. For example:

publishing {
    publications {
        qwe( MavenPublication ) {
            artifact( file('abc') ) {
                builtBy( tasks.buildAbc )
            }
        }
    }
}
4

One thing I personally struggled with was publishing of a selected subproject’s dependency tree instead of all the subprojects. I had to resort to afterEvaluate hacks for this.

5

Can I ask why you need to do this? Sounds like you have code in the same repository/project with different release lifecycles?

6

Kind of. The whole project is an application, but some of its parts are consumed by other developers as libraries. I want to keep everything in one repo for the ease of refactoring and don’t want to pollute our Nexus with unnecessary artifacts.

7

From what I hear, my recommendation for that would be to pull out the things needed as libs by other projects into own repositories with separate release cycles and then use composite builds for “ease of refactoring”.

1 Like