GitHub provides the ability to publish/host (binary) releases. My idea is to use the Github Releases as repository in Gradle. (Travis is able to automatically deploy to Github Releases, so this would give a very smooth workflow.)
This would remove the burden of managing a 3th party maven repository.
I know there is https://jitpack.io, but its not free for private usage and it also seems to fail more complex builds involving 3th party tools. (And why should a repository build things itself, this is the job of the CI server)
Using the Github Rest API to find projects & release versions seems to be a logical step and actually just another form of repository. This would even work with private repositories, where as public maven repos obviously would not be possible.
Would it make sense to write a plugin which provides a new repository âgithub-releasesâ? Iâd like to give this a try. Maybe someone can point out another plugin which implements a custom repo, if this is possible?
This is something we as community plugin authors never quite got right so far. For the JRuby plugin we added the option to firing up a little jetty servlet in order to do the Gem -> Maven conversion. That is not a great solutions IMHO, but it had to be done becasue the Gradle API curretnly offers little in the way to help plugin authors to solve this problem.
Then there was the Gradle Repositories Plugin, but it no logner works with later versions of Gradle. You can poke around in there to get some ideas.
Most (all?) github repositories only publish binaries as release artifacts, how will you obtain the publishing pom information (eg transitive dependencies)?
Will you be able to deal with non-standard jar naming conventions?
Will you support jars nested within zips?
How will you determine groupId and artifactId? (the github user / repo may be different to the groupId / artifactId)
If a github repo represents a multi-module build youâll need a mechanism to support multiple artifact idâs per release version
Iâm guessing that youâll need the option to provide custom mappings when github release artifacts donât conform exactly to conventions. Where will this mapping meta-data live? in the github repo? or in the clientâs build.gradle?
Points 4 & 5 sound like they may require a releaseevent webhook to maintain a mapping between github repos and groupId / artifactId
The idea with a local âadapterâ maven server sounds interesting as it would not require any changes to Gradle or a Plugin. On the other hand, a plugin which can handle this would probably be more effective.
We need to have basic information of the artefact, especially its transitive dependencies. Thus we still need an ivy.xml or pom.xml as it is used when published to a normal maven/ivy repository.
Since we should not need to checkout the git repository (this would slow down builds especially if many of the dependencies would use this form of repository), we would require a ivy.xml or a pom.xml in the Github Releases, next to the jar.
For multi module build (which is quite important) this would require multiple poms in the Release downloads.
foo-client.jar
foo-client-sources.jar
foo-client.pom.xml
foo-server.jar
foo-server-sources.jar
foo-server.pom.xml
The version would be directly mapped from the Release Tag.
The above would look for a Repository named âMyRepositoryâ for a Release with the Tag 1.0.0 or v1.0.0 and pull in the jar/pom prefixed with MyModule.
Could this work?
PS: I think it makes a lot of sense to handle each GitHub User/Organisaiton as a unique repository. Especially if you need to authenticate to them, since different GitHub Users would require different tokens.
I think you need to step back and think about your primary objectives. Iâm guessing the main objective is for something that âjust worksâ for github projects.
The need for pom.xml/ivy.xml is now a custom requirement and will likely require a custom âpublishâ step. So, the convenience seems to have faded and it now looks like youâre rolling your own repository with itâs own publishing mechanism.
As much as Iâd love to see a âjust works for Github Releaseâ solution, I cant see how transitive dependencies could be handled by pure magic. They must be specified by some means, and if this happens with an additional file, why not reuse the pom.xml.
This indeed requires an additional step to create the pom, but Gradle seems to be able to just create the publish pom, without actually publishing:
model {
tasks.generatePomFileForMavenJavaPublication {
destination = file("$buildDir/libs/${jar.baseName}-pom.xml")
}
}
In essence, this would reuse a GitHub âUserâ as Maven repository.
Have you considered using github as a maven repository?
Yes, but pushing binaries into a git repo is not good practice. Due to the nature of git this leads to bloating the repo in no time.
Apparently the Ivy custom Url attempt would be able to handle ivy/pom files, not only binaries. This looks very promising.