HNHacker News
TopNewBestAskShowJobs

jitpack

67 karma · joined January 23, 2015

https://jitpack.io
submissionscomments
jitpack··on Dear GitHub
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.

jitpack··on Lightweight android swipe-to-dismiss library for RecyclerView
So which one is it?
jitpack··on Show HN: Jitpack.io – GitHub to maven, one less step in software publication
Thanks for the submission and recommendation! Very happy you like it and find useful.

Sometimes its good to be lazy and it could mean that you were doing something that can be simplified or automated. Thats what we try to do.

jitpack··on JitPack – Just-In-time Packager – Build GitHub Repos On-Demand
Thanks for submitting!
jitpack··on Just-in-time packager for GitHub repositories
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.

[1] https://github.com/blog/1547-release-your-software

jitpack··on Just-in-time packager for GitHub repositories
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.

jitpack··on Just-in-time packager for GitHub repositories
That's correct
jitpack··on Just-in-time packager for GitHub repositories
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.
jitpack··on Just-in-time packager for GitHub repositories
There are! Probably Sbt first and then Leiningen.
jitpack··on Easy-to-use package repository for JVM-based projects
At the moment it's only available as a cloud service but we're considering a self-hosted version later on.

Sha1 support sounds like an interesting idea. Care to open an issue for that?:)

jitpack··on Fluent Java HTTP Client
OkHttp by square seems quite fluent and is widely used. What does jcabi offer that's not available there?

http://square.github.io/okhttp/