Dear Sonatype,
a year ago I published an authentication plugin on github which was gratefully picked up by a few companies (I can only tell from what people tell me in issues and mails). With the release of 3.78 you mentioned your switch from karaf to spring in your release notes and said that this would affect custom plugins, for obvious reasons.
I’d like to give some feedback on plugin development before this change and how it looks now. Before 3.78, you used a maven profile provided by sonatype’s parent pom which would bundle everything as kar and then you would drop it in the deploy/ directory where nexus would find and load it. In the plugin code you would use the javax.inject annotations to make nexus find your components and add them to its lifecycle.
The documentation on how to do all of this (especially on interacting with nexus’ own architecture components) was rather poor, but you could get there with some fantasy and by reading in the nexus-public git repo.
Unfortunately, a lot of this sparse documentation is obsolete and there is nothing to replace it, plus, the code in the nexus-public repo hasn’t been updated for more than 1 month, so there is no chance to learn how to make it work starting with 3.78.
I tried some things to make nexus pick up my plugin again, like adding a configuration class with the org.springframework.boot.autoconfigure.AutoConfiguration annotation, adding my packaged jar to the nexus classpath and even manually repackaged it into your new “uber jar” (which would be really complicated for simple users of custom plugins). According to the (debug) logs nexus doesn’t find it in any of these places. Your LicensedApplicationJarFilter seems to be working with a hardcoded allowlist defining what to load.
Maybe I missed something, but to be honest it really shouldn’t be that hard to get a custom plugin deployed. I would have expected you just keep looking at the deploy/ directory and load whatever jar I put there. I would appreciate some help with making this work, because I need that plugin for internal use in our company and my community of users is also hoping to be able to update again soon.
On a side note: Back in April 2024 when I was about to publish my plugin, I was contacting nexus-feedback@sonatype.com, asking about correct licensing etc., trying to make sure I am not violating any rights of yours. Unfortunately, I never received an answer. I am really happy that there is/was the option to develop plugins, as that was the only reason we could stay with nexus as artifact store, because even in the pro version only SAML is supported as SSO authentication. It would be great, in case you continue to allow custom plugins, if you could work out some responsive place to go for the developer community to get started, as such threads don’t seem to receive answers and the responsiveness in nexus-public is really low as well.
As someone loving the open source approach, I think Sonatype can benefit a lot from a healthy plugin ecosystem but it requires a minimum of support to get going and especially during transition phases like the last year (orientdb → h2, osgi → spring) as nexus is a quite complex piece of software and it takes a lot of energy to understand anything in the beginning.