Fetch and make available react-native jcenter dependencies

[mikehardy]

First job as a proof of concept is to preserve and make accessible the most important artifacts in a way that allows user verification of authenticity (if possible) and is efficient but that does not rely on collaboration across lots of repos

• I believe the list is yoga proguard-annotations, a couple flipper items, and fbjni?
  • [Deadline: Feb 1st, 2022] JCenter is being sunset -- What's the plan for react-native? react-native-community/discussions-and-proposals#331 (comment)
• decide where an how to store them?
  • initially in this repo?
  • all the signature contents etc should be with them an unaltered, like the maven repo tree I think?
  • maybe store them as a compressed single file that may be expanded post-download?

[mikehardy]

If this could be pure gradle there's the potential for it to be a gradle plugin and help a much broader community

[mikehardy]

It appears to be possible to take existing jars and publish them on jitpack - you don't always have to build from source: https://gist.github.com/jitpack-io/f928a858aa5da08ad9d9662f982da983 - then typical maven/gradle coordinates work perfectly. This seems ideal

I think the task here - with that new knowledge - becomes "create easy script to publish existing jars on jitpack" and then rely on dependency-coordinate-resolution-bending and focus on that vs package formatting / URL fetching etc.

[mikehardy]

make jitpack.yml like:

install:
- FILE="-Dfile=jars/my-library.jar"
- mvn install:install-file $FILE -DgroupId=com.github.user -DartifactId=repo -Dversion=1.0 -Dpackaging=jar -DgeneratePom=true

apparently "root directory also needs a pom.xml" for this to work

<?xml version="1.0" encoding="iso-8859-1"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
			    http://maven.apache.org/maven-v4_0_0.xsd">
	<groupId>com.github.user</groupId>
	<artifactId>repo</artifactId>
	<version>1.0</version>
</project>

Renaming is handled sort of like this per an answer on the gist

the groupId and artifactId will be overwritten by JitPack at the time of build. If you put another username then the groupId will still be 'com.github.YourUsername'

And for this to be pleasant it would be best if there was the ability to do this within this single repo somehow, as folders or something, which is maybe possible? Vs a repository proliferation (though that's possible perhaps - a jcenterizer org and repos for gradle plugin and each jar we need to mirror. Appears to be possible to produce multiple jars per repo like this: https://github.com/jitpack/gradle-multiple-jars / https://www.jitpack.io/docs/BUILDING/#gradle-projects

That will publish all the jars with the version from this repo vs the version of the jars, but that can be handled by embedding the version of the jar in it's re-mapped jar name.

e.g.

• com.facebook.yoga:proguard-annotations:1.16.0 becomes
• com.github.mikehardy.jcenterizer.yoga-proguard-annotations-1-16-0:1.0

more generally

• <org>.<repo>:<artifactId>:<repo-version> becomes
• com.github.mikehardy.jcenterizer:<repo>-<artifactId>-<repo-version-hyphenated>:<jcenterizer release>

So the task is to come up with a local repo structure here that - in combination with either a jitpack.yml or a build.gradle produces that sort of multiple-jar publication on jitpack.io

https://jitpack.io/com/github/jitpack/gradle-multiple-jars/1.0.1/build.log