Using 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?<p>Go ask the Erlang community about the issues they have with using GitHub repos as "packages". Here is a discussion about packaging: <a href="http://mostlyerlang.com/2015/01/27/054-packages/" rel="nofollow">http://mostlyerlang.com/2015/01/27/054-packages/</a>
A 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:<p>1. It might cause clashes for repositories that <i>are</i> 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.<p>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.<p>In short, release artifacts must be unique and must be immutable; this project breaks both. That <i>will</i> 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).<p>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.