Also publish on Maven Central instead of just Jitpack

[Rolf-Smit]

Currently this library is published to Jitpack, this has a few downsides but most importantly the up-time track-record for Jitpack is well... not the greatest as this issue proves: jitpack/jitpack.io#5337

I also noticed that this library itself is defining a transitive dependency on: https://github.com/MikeOrtiz/TouchImageView which is also using Jitpack (thus also fails when Jitpack is down).

So I think it is best to migrate or also publish this library in a more reputable repository such as Maven Central, the transitive dependency is harder to solve, maybe there are other libraries that could be used instead that are published in Maven Central as well (or bundle it instead of making it a transitive dependency)?

[Speiger]

@Rolf-Smit serious question, since my library is also on jitpack.
Maven-Central can be a pain to use.
Can you provide another maven thats as easy to use as Jitpack?

And then you wouldn't even need to request this since jitpack allows you to use their service without being the owner of the repository, as long it is public

[alexkok]

Thanks for reporting @Rolf-Smit. Is this something you face a lot? JitPack will likely improve on this as well on their side.

As you also mentioned, to support Maven Central (or any other method), we'll need to check or replace the other dependency as well.

We will probably consider adding other methods as well in the future. However, for now we'll keep using JitPack.

Feel free to let us know if you face issues with this again.

[Rolf-Smit]

@alexkok

I'm requesting one more time that you consider migrating this library to Maven Central (or at least making it available there).

For professional use and in a secure enterprise setup, JitPack is not a viable option. Currently, this is the only dependency in our entire project that forces a reliance on it, and we have to mirror it to our own internal repository to meet our security standards. Publishing to Maven Central would resolve this and is standard practice for professional-grade libraries for several key reasons:

• Security & Verification: Maven Central requires GPG-signed artifacts and domain verification. This provides a secure chain of trust, ensuring we are consuming a legitimate, unmodified library.
• Reliability & Immutability: Artifacts on Maven Central are permanent. This protects our builds from breaking due to upstream issues like Git history changes or repository deletions, which is a known risk with JitPack.
• Developer Experience: The requirement to include Javadoc and sources vastly improves the developer experience, especially for debugging and API discovery.

Important Note on Transitive Dependencies:
I also noticed that this library still depends on com.github.MikeOrtiz:TouchImageView, which is also published only on JitPack. This transitive dependency would also need to be addressed (e.g., by bundling it or finding a Maven Central alternative). Otherwise, projects using your library would still be forced to add JitPack to resolve this dependency, defeating one of the primary benefits of migrating. This also represents a security risk, as there is no strong chain of trust for that artifact either.

We cannot consume dependencies directly from JitPack due to these security and reliability risks. I strongly suggest migrating to Maven Central to provide a secure and stable artifact for your user base.

[alexkok]

Hi @Rolf-Smit, thanks for requesting. We'll reconsider and look into it, reopening the issue 👍

[Speiger]

@alexkok its less difficult nowdays.
You can use a github account to validate your account.
They ask you to generate a repo with a very specific name and once done you can delete it and your publish account can get validated.
Once validated you run the same systems like jitpack. (The maven generator)

Its no longer complicated how it was back then.