Publish project to Maven Central

[spetruninCapitalOne]

Hey there, thank you for developing this cool project.

I'm trying to see if its possible to port one of our Spring APIs into it, but due to company restrictions can only install it if it's in Maven Central (which basically get cloned to our local Artifactory every now and then). We not allowed to pull JARs from JetPack or any other outside services..

Another alternative for me will be to fork it and push it to our Artifactory manually for every update, which I would like to avoid in the long run

I don't have experience dealing with Maven public repos, but will be happy to learn and help
I guess are there any reasons against doing it?

[Rattlyy]

Not a mantainer of the project, but from my experience deploying to maven central is a very tedious procedure.
If you can't add other repositories, as a workaround while this gets sorted out, you could try compiling the modules with Gradle:

sourceControl {
  gitRepository(java.net.URI("https://github.com/codeborne/klite.git")) {
    producesModule("com.github.codeborne.klite:server")
    producesModule("com.github.codeborne.klite:jdbc")
    // list all subprojects you depend on in build.gradle.kts, use their un-prefixed names, e.g. server, not klite-server
  }
}

[halfstrik]

Thanks @Rattlyy , but my problem is that our CI/CD pipeline literally blocks everything that is outside of our bank's network...
Public Github - out of network, JitPack - out of netwrok, even Maven Central is blocked itself...
They do mirror and "bless" Maven Central (along with NPM, PyPI etc) into internal Artifactory and only allow download from it. I'm guessing they run each package through variety of scanners and filters.

I understand that the process likely not the quickest and easiest and ready to help with it, hopefully it will help more people like me, who's Sysadmins are kinda crazy 😁

[angryziber]

@halfstrik do you think that Klite can be acceptable for use at all in such an organization that blocks repos?
I am thinking, is it still worth the effort of publishing to Maven central, if it still won't be used from there?

[spetruninCapitalOne]

@angryziber this is a good question actually. I assume that they will allow anything from Maven Central (but I'm not 100% sure).

We did rewrite one of our services in klite (it used to be in Spring/Hibirnate), this turns out to be very easy to do code-wise.

The main problem was to get the Jar files in our pipeline, we had to create a zip archive and upload it to company's Artifactory and then download and extract into local maven-home folder...

But it should be worth comparing to the amount of Spring-related vulnerabilities we are getting every week (tomcat and friends)

But of course if we put klite into Maven Central - the adoption for folks in our company would be much easier, and we will be able to advertise it for other teams as well (without the need to maintain ad-hoc deployment).

If you guys don't want to deal with Sonatype/Maven, we can submit a request on your behalf and deal with the correspondence and any changes (if those needed, e.g. code coverage add or what not), if you will give us such permission. Or we will be happy to support and assist you in this process anyway we can.

(sorry accidentally delete my previous comment)

[Chase22]

Getting this onto sonartype is imo a good idea in general. It makes downloading it easier without having to declare a separate repository. For @spetruninCapitalOne: Would it be an option to mirror the repository and build custom artefacts into your companies repository?

[halfstrik]

@Chase22 that what we were trying to do at first, however it was problematic to build it correctly in our build system and satisfy all the company standards (like 80% code coverage, and etc), we were not sure how to befriend coverage for gradle modules and Sonar system..
(Also during its build klite invokes Docker, which of course was absent on build agent, so we would have to patch it)

So eventually we just found a way to upload jars directly to our Artifacory. Not ideal solution, but works.. we will have to manually refresh it for every new version also..
Having it in Sonotype would reduce this friction for us for sure.