Infer artifactId and groupId from git url

[TheElan]

Using git remote get-url origin we can get url like git@github.com:TheElan/org-build-system-updater.git, from it a groupId can be extracted as github.com:TheElan -> github.com.TheElan and name as org-build-system-updater as artifactId

This way we are both compliant with jitpack scheme on other maven as well as locally without a need to setup it manually for each project. This would also work nicely with forks.

The only problem I can see here is jitpack building behavior. It looks like it doesn't clone but copy files, which means there is no git repo when it's building, might need to find some workaround either changing smth in jitpack.yml.

[SinTh0r4s]

*com.github.TheElan

Jitpack provides the correct version from git tags. They might block certain git functionality as they deem it not safe.

[SinTh0r4s]

We should dig a bit deeper to guard against cyclic dependencies. Gradle will resolve all dependencies including cyclic ones and choose the most up-to-date version for each. But it only considers artifacts for conflicts with the same group and artifact I'd.

Example A:

compile("com.github.TheElan:ForgeGradle:1.4")
compile("com.github.TheElan:GorgeGradle:1.3.4")

Will be reduced to ForgeGradle@1.4

Example B:

compile("com.github.TheElan:ForgeGradle:1.4")
compile("com.github.GTNewHorizons:GorgeGradle:1.3.4")

Will import both dependencies are those are deemed separate. That is the inherent danger of Jitpack. It will quickly break builds if you mix up forks!

Anyway, if the current project (for example GalacticGregGT5) is included transitively by a circular dependency, the Gradle properties group, version and project folder name as artifactId are used to remove duplicates and so on. Currently our modgroup is set to the proper reverse domain name, but that will create issues with Gradle conflict resolution as groups won't match and result in duplicate entries at runtime. We could provide some sort of jitpack override in the considered organization.gradle or change the build script itself to pull the group directly from git in the future.

[SinTh0r4s]

I am much more in favour of using the proper group for publishing on jitpack and use a script to mass update all 123 existing repositories dependency declarations. This will protect us from long term issues with forks!

[TheElan]

Publishing with same group on jitpack is illegal and doesn't make much sense. Its a responsibility of repo owner to make sure they won't have forks in the projects.

The simple reason of it being illegal - you don't own original forge gradle repo and can't post under their name new versions.

I suggest putting a simple guard which will check artifact ides, since they should not change (don't remember seeing case where some repo was forked and then renamed).