This message was deleted.

We place shared objects (including services) in scoped plugins. We also have some plugins that use the shared classes from others. But generally speaking that is the best way to have shared functionality between applications, yes.

Plugins are one way like Steve suggested, and are probably the most efficient way, however, you do have to maintain and test that new library, compile it, deploy it locally, and release it to an internal repo(assuming it's not something you're going to open source). If you go this route make sure to include the src in your artifact within the gradle build, so that from your project you can easily debug that dependency, because if don't you'll only see a decompiled version which will be a little harder to debug. Another way is by using a gradle subproject dependency. The advantage to this is that in IDEs you can edit both your project and sub-project from the same project, and compilation is automatically handled. The sub-project can be kept in the same folder/git structure as the project or not. The downside to this is if that subproject becomes large or a dumping ground, when not cached or when you change it will get compiled along with the rest of your code. This can also allow you to create tightly coupled code, that will be harder to break up later if you want to do that. A third way you can share code is by calling one project from another via rest or message queues. This could be relatively simple, but you will have to scale the project so that it can handle the additional traffic if it is significant. This also increases the burden of trancing errors, the need for centralized logging, and having to run both apps at the same time to be fully functional. A fourth way is to break off code into microservices or microfunctions. The advantage of this is you have independently deployable code, that is loosely coupled to your original project, via rest calls(sync/async) or via message queues. Another advantage to this is that you can keep your projects from getting too large and having long compile/startup times. The downside is that you now have another project to manage, deploy, and scale, and you may have to invest in new tools and training for things like container services, Kubernetes, helm charts, etc. So those are four ways you can share code between projects. All of them have trade-offs, that you will have to weigh depending on where your project is and where you want it to go.

FWIW we develop the plugin functionality usually as a gradle sub-project so, we don't have to keep publishing it during development..