jitpack.io failing causes inability to build or work on projects using squidlib

[SquidPony]

For at least the last week I have been unable to use squidlib through jitpack.io due to the library never being fully served. This means that I cannot build or run without disconnecting jitpack.

I have no idea what's up with jitpack. Their site loads okay and most of their pages open right away. Hitting the log or trying to pull the artifact through gradle both just hang forever (an hour is the longest I actually gave it). All google tells me is that jitpack is the best thing ever and it has no problems...

[tommyettinger]

Woah, that's odd. It's worked for me so far, I use it in https://github.com/tommyettinger/ColorGuard much of the time. One thing I noticed was that sometimes the commit builds don't appear in the list for some indeterminate amount of time, but you can still build them using the first 10 chars of a commit hash on GitHub, such as this commit, one that fixes a recursion bug in one method would use 1d85a814ce as your version in your Gradle config. I'll try it now.

[SquidPony]

As an example, the log page for the most recent commit will not load for me: https://jitpack.io/com/github/SquidPony/SquidLib/1d85a814ce/build.log

I'm wondering if it's a connection problem on their (my?) end maybe.

The rest of their site seems fine...

[tommyettinger]

It might still be building. It's possible the docs may need to be cleaned up because they add quite a lot to repo size, and JitPack may be cloning each time, I don't know. The change history on all the JavaDocs is a hefty download.

[tommyettinger]

It seems to have been working for a while; I remember this was mentioned either over a week ago on IRC and was fixed then. The solution, which I should have mentioned, is that you can always build SquidLib and install it locally with the command mvn install from the root of the project, or a similar command in an IDE used on squidlib-parent . This uses different dependency coordinates, which is a small hassle but can normally be worked around by putting the coordinates in one place as a Maven property or Gradle variable/property, and switching from the JitPack ones to the Maven Central ones (which are also used for locally installed SquidLib snapshots).
The JitPack style mentioned (using squidlib-util as an example) is com.github.SquidPony.SquidLib:squidlib-util:COMMIT_HASH_FIRST_10_CHARS for Gradle, and for Maven,

	<dependency>
	    <groupId>com.github.SquidPony</groupId>
	    <artifactId>squidlib-util</artifactId>
	    <version>COMMIT_HASH_FIRST_10_CHARS</version>
	</dependency>

The Maven Central style (and local installation style) is com.squidpony:squidlib-util:3.0.0-SNAPSHOT for Gradle, and for Maven,

<dependency>
    <groupId>com.squidpony</groupId>
    <artifactId>squidlib-util</artifactId>
    <version>3.0.0-SNAPSHOT</version>
</dependency>

Using this method needs Maven "installed," or more accurately, just present on your computer where you can access it (it doesn't need to be added to the PATH or anything, you just might need to specify the path to the mvn executable). Then, when you run mvn install, it should download the dependencies for all projects (RegExodus for -util, libGDX for the display module, and BlazingChain for -extra, plus JUnit for running the tests that it will do during installation), and wrap up by installing the modules. This can be useful if you intend to tinker with the library, and want to depend on it in a different project without committing code to SquidLib that needs some other project to see how well it works..