I’m a little unsatisfied with the way the JFrog Artifactory plugin works. Does anyone have any alternative solutions that still push build metadata to the repository?

We were in the same boat and switched to core publishing. Our plugin isn't OSS unfortunately. Haven't seen anything else out there

that works fine just just don’t get build-info pushed right?

Right, our internal plugin adds back build-info

okay… I’m looking at implementing that myself right now… although I’ve probably burnt too much time on this already 😞

What's wrong with using good old maven-publish?

Nothing unless you need Artifactory build info

Which would be leaving a bunch of the Artifactory feature set on the table so to speak.

Hello, @Chris & @Danny Thomas I’m part of the team developing the Gradle Artifactory plugin at JFrog. Could you please share the reasons you are not satisfied with the plugin?

I don’t recall the precise details… but my main issues relate to integrating the publication to Artifactory as a “secondary aspect”. I have a large-ish Gradle project where the primary publications are to a Nexus instance. I had wanted to add the secondary publication of a handful of artifacts to an Artifactory instance. From memory I had two main problems. One: there was general feeling of “non-standardness” about the way Artifactory handles registering publications (especially in a multi-module project). This didn’t play well with my existing publication setup. I was hoping for something that was much more closely aligned with the existing Ivy publication approach. I actually started to prototype my own plugin that worked by using a

SharedService

as a “concentrator” point for the IvyPublications of a project (possibly keyed against repository ID/URL) that could then handle collection and publication of the build metadata at the closure of the service. This would have allowed a more “this is an extension” approach that suited my existing builds much better. Secondarily, while playing around with the Artifactory plugin I kept running in to issues with build-info metadata generation that seemed counter-intuitive and hard to debug. From my POV the sum of “this thing integrates weirdly” + “this thing is frustrating me” exceeded my threshold for “I can build something that does this better in-house”. To draw a comparison, I didn’t personally fold the Nexus plugin in to our build, but I don’t ever see evidence of it’s fingers outside of the root project. To me thats the mark of a nice integration… it’s present where necessary, but otherwise keeps out of the way. For now this work has been shelved, I might get back to it in the next few months.

From my POV the sum of “this thing integrates weirdly” + “this thing is frustrating me” exceeded my threshold for “I can build something that does this better in-house”

Essentially this for us too. Several releases broke, weird coupling of tasks across projects - we wanted to move to Gradle core publishing only, much simpler, publishes run in parallel during the build, etc.