Hi. your junior colleague might be interested in the security answer here https://jitpack.io/docs/FAQ/. It's an important matter so will be happy to answer any more questions via email/gitter.
You can also run JitPack on-premises and have full control over build artifacts.
Thanks for the feedback and its good to hear your concerns.
Yes, you can use strings as tags but we recommend using Semantic Versioning just as GitHub recommends for Releases [1]. At some point we may choose to only build tags that match semantic versioning, to be decided. Unlike using just GitHub as source repositories we have some over what we serve and that's the difference.
If you make a conscious decision to release, add release notes and a tag why would you delete it? Especially if you want others to use your project. Its just not part of usual release workflow. Right now you can still get the binary for a tag that has been deleted because we cache it. We will probably add restrictions to prevent building another binary with the same tag.
Thank you for the compliment, Ron. Glad you see an upside to JitPack:) Regarding your concerns:
1. If you add JitPack as a respository then Maven will still check central first. If the artifact is in central it won't bother going to jitpack.io. Also JitPack enforces your group name to point to your GitHub repo to avoid name clashes.
2. Yes, git tags can be deleted but you really shouldn't do that on a public repo anyway. And most of the time people releasing with tags don't change them.
JitPack is built for the common case and not for the edge cases. And we believe that just because there are rare ways to break the system doesn't mean we should keep a high barrier-to-entry. Sharing your work should be easy and it should be easy for others to try your work.
Of course! It's very cool! But I don't think it can be used in production (or even in development of important projects).
1. Say I am the consumer and I use a library author's GH repo with JitPack. Then, when the author releases her library to Central/jcenter/Clojars/whatever, she's free to choose any group name she wants (JitPack can't force her to do anything), and once she does that -- and another of my dependencies transitively depends on that artifact -- I am very likely to get a bug that's very hard to track down. Alternatively, once she publishes to central under a different group name, you might choose to simply break my build, which is also undesirable.
2. Maybe people shouldn't, but they do it all the time. I've done it on occasion, and I'm pretty sure I'll do it again. When that happens -- there's another impossible-to-find bug.
> JitPack is built for the common case and not for the edge cases.
Which means it's a binary repository that is undependable. And remember, those edge cases are out of the library consumer's control.
> just because there are rare ways to break the system
Unfortunately, they are not rare. First, most (actually, virtually all) production-quality Java/JVM libraries are already hosted on some public Maven repo, and any library that becomes production quality is likely to publish the artifacts, so breakage 1 is almost certain. As to 2, you should really get the data from GitHub. I think you'll find that deleting and re-creating tags is a lot more common than you think.
But even if those cases were rare, they can be very, very costly. We're not talking about a breaking build, but actual runtime bugs that might take days to track down.
> doesn't mean we should keep a high barrier-to-entry
True, but the barrier-to-entry for the author is already quite low; jcenter makes it almost nonexistent.
What you've done is something else: you've let the library consumer control the artifact, so you've lowered the barrier for them, which is great! However, by doing so you've ensured that the author will almost certainly inadvertently introduce really, really tricky bugs into the consumer's project, bugs that they can neither control nor track down.
Still, JitPack is a great way to try someones work-in-progress code, to see if it might be worth it to help them make it production-quality. I am sure to give a try some time.
Currently not. Actually you are the first to ask and it sounds like a great feature:) most likely that would mean you host jitpack on premises. It's something we don't provide yet but it is on the road map.
Wonder how high the usage would be. If you have github enterprise setting up Nexus and having build process publish to it seems easier than this build server.
You can also run JitPack on-premises and have full control over build artifacts.