Amazing, this was sorely needed!
Just-in-time packager for GitHub repositories
11–20 of 33 posts
Re: Just-in-time packager for GitHub repositories
#12Using source repositories as packages sounds like an awful idea. Not only do you have to deal with runtime dependencies, but also compile, test, and other dependencies. What happens if the tags are not numbers? What if a tag you are using is deleted? Go ask the Erlang community about the issues they have with using GitHub repos as "packages". Here is a discussion about packaging: http://mostlyerlang.com/2015/01/27/05…
I think you might be misunderstanding how this service works.
The Github repositories don't serve the packages.
Jitpack checkouts the repository code, builds it, and serves it like a normal maven repository. Here is a sample repository https://github.com/jitpack/maven-simple and the maven repository it is served from: https://jitpack.io/com/github/jitpack/maven-simple/0.1/maven...
Re: Just-in-time packager for GitHub repositories
#13Using source repositories as packages sounds like an awful idea. Not only do you have to deal with runtime dependencies, but also compile, test, and other dependencies. What happens if the tags are not numbers? What if a tag you are using is deleted? Go ask the Erlang community about the issues they have with using GitHub repos as "packages". Here is a discussion about packaging: http://mostlyerlang.com/2015/01/27/05…
I think you might be misunderstanding how this service works. The Github repositories don't serve the packages. Jitpack checkouts the repository code, builds it, and serves it like a normal maven repository. Here is a sample repository https://github.com/jitpack/maven-simple and the maven repository it is served from: https://jitpack.io/com/github/jitpack/maven-simple/0.1/maven...
That's correct
Re: Just-in-time packager for GitHub repositories
#14Does jitpack currently support repositories in Github Enterprise?
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.
Re: Just-in-time packager for GitHub repositories
#15Nice! This should make it a lot easier for developers to publish their projects.
I thought the same. Publishing small JS libs is easy, just drop a Bower file and register it. For maven I need to build it, sign it, get access to a central repo (can take days) and then finally upload it. Of course, this means that the quality is often much higher, but I think the barrier is a bit too high as it is right now.
> For maven I need to build it, sign it, get access to a central repo (can take days) and then finally upload it.
Those are the steps required to host your artifacts on Maven Central. Hosting on other public Maven repositories requires less work, and if you host your own, you set the bar (you can even turn a GitHub repo into a Maven repo, and upload with a git push).
Having said that, if you've built something worth using, the extra steps required to publish to Maven Central are both negligible with respect to your overall effort, and are more than worth it (getting the initial access usually takes hours, or one day at most, and only has to be done once for the entire organization/author).
So far, the only projects I've seen that are not already hosted on Maven Central or any other public Maven repository (jcenter, Clojars, java.net and others), are usually short programming exercises or works-in-progress.
Re: Just-in-time packager for GitHub repositories
#16Love this project, almost surprising that nothing like this exists today for the maven world.
It does. There are gradle/Maven tasks to upload your artifacts to public Maven repos, and they're easy to set up so that Travis publishes them whenever you create a tag.
Re: Just-in-time packager for GitHub repositories
#17A very nice project that reduces the barrier-to-entry of Maven artifact publishing, and saves an open-source project author a couple of hours of annoying work, but I have two concerns:
1. It might cause clashes for repositories that are hosted on a public Maven repository. Maven artifacts have one name, and one name only. Now, they may have two (with versions that are not necessarily aligned, to boot). This can wreak havoc on transitive dependencies.
2. Because git tags can be deleted and re-created, this repository breaks one of the strongest guarantees made by all (public) Maven repos, namely, that once a release artifact is published, it can never, ever change. This makes artifact versions unreliable.
In short, release artifacts must be unique and must be immutable; this project breaks both. That will cause actual runtime bugs that are virtually impossible to catch (and are bound to cost much more than the one-time setup -- per organization! -- of Maven hosting).
The sort of capabilities and guarantees required for source code management (and are provided by SCMs like git) are not the same as those required of binaries.
Re: Just-in-time packager for GitHub repositories
#18Using source repositories as packages sounds like an awful idea. Not only do you have to deal with runtime dependencies, but also compile, test, and other dependencies. What happens if the tags are not numbers? What if a tag you are using is deleted? Go ask the Erlang community about the issues they have with using GitHub repos as "packages". Here is a discussion about packaging: http://mostlyerlang.com/2015/01/27/05…
I think you might be misunderstanding how this service works. The Github repositories don't serve the packages. Jitpack checkouts the repository code, builds it, and serves it like a normal maven repository. Here is a sample repository https://github.com/jitpack/maven-simple and the maven repository it is served from: https://jitpack.io/com/github/jitpack/maven-simple/0.1/maven...
I got that it is building a binary and basically placing it in a local repo. I also get that it is looking for a binary from a GitHub Release first, which is mildly better.
I still think solutions like this are putting your build process at great risk. You will have build issues that are no fault of your own and completely out of your control. Unless you clone the github repository and then use that as your source. And cloning will have issues and risks of its own.
EDIT: See pron's reply for describing the risks: https://news.ycombinator.com/item?id=9029870
Re: Just-in-time packager for GitHub repositories
#19Earlier quoted context omitted.
I think you might be misunderstanding how this service works. The Github repositories don't serve the packages. Jitpack checkouts the repository code, builds it, and serves it like a normal maven repository. Here is a sample repository https://github.com/jitpack/maven-simple and the maven repository it is served from: https://jitpack.io/com/github/jitpack/maven-simple/0.1/maven...
I got that it is building a binary and basically placing it in a local repo. I also get that it is looking for a binary from a GitHub Release first, which is mildly better. I still think solutions like this are putting your build process at great risk. You will have build issues that are no fault of your own and completely out of your control. Unless you clone the github repository and then use that as your source. A…
[deleted]
Re: Just-in-time packager for GitHub repositories
#20A very nice project that reduces the barrier-to-entry of Maven artifact publishing, and saves an open-source project author a couple of hours of annoying work, but I have two concerns: 1. It might cause clashes for repositories that are hosted on a public Maven repository. Maven artifacts have one name, and one name only. Now, they may have two (with versions that are not necessarily aligned, to boot). This can wreak…
3) This creates an insane MITM opportunity.
Not only are they spitting back opaque binaries, but they're doing so by running arbitrary and untrusted user code.
There are already single-command tools for releasing a project to Maven, including tagging the release, bumping the version number in the build file, building and signing the jars, and uploading the results to a Maven repository.
Given that, why would you SaaS trusted builds!?!