Hosting a Maven repository on github

Question

I have a fork of a small open sourced library that I'm working on github. I'd like to make it available to other developers via maven, but I don't want to run my own Nexus server, and because it's a fork I can't easily deploy it to oss.sonatype.org.

What I'd like to do is to deploy it to github so that others can access it using maven. What's the best way to do this?

what licensing issues are you facing in OSS Sonatype? Just curious since I use it myself. — Archimedes Trajano, Feb 03 '14 at 06:10
There's a tool that allows you to expose your GitHub repo via maven directly. https://jitpack.io http://stackoverflow.com/a/28483461/3975649 — metrimer, Apr 24 '15 at 09:02
Github also announced a package registry that supports maven. Currently in public-beta: https://github.com/features/package-registry — Kaan, Jul 14 '19 at 10:23

score 512 · Accepted Answer · edited Mar 04 '20 at 21:20

512

The best solution I've been able to find consists of these steps:

Create a branch called mvn-repo to host your maven artifacts.
Use the github site-maven-plugin to push your artifacts to github.
Configure maven to use your remote mvn-repo as a maven repository.

There are several benefits to using this approach:

Maven artifacts are kept separate from your source in a separate branch called mvn-repo, much like github pages are kept in a separate branch called gh-pages (if you use github pages)
Unlike some other proposed solutions, it doesn't conflict with your gh-pages if you're using them.
Ties in naturally with the deploy target so there are no new maven commands to learn. Just use mvn deploy as you normally would

The typical way you deploy artifacts to a remote maven repo is to use mvn deploy, so let's patch into that mechanism for this solution.

First, tell maven to deploy artifacts to a temporary staging location inside your target directory. Add this to your pom.xml:

<distributionManagement>
    <repository>
        <id>internal.repo</id>
        <name>Temporary Staging Repository</name>
        <url>file://${project.build.directory}/mvn-repo</url>
    </repository>
</distributionManagement>

<plugins>
    <plugin>
        <artifactId>maven-deploy-plugin</artifactId>
        <version>2.8.1</version>
        <configuration>
            <altDeploymentRepository>internal.repo::default::file://${project.build.directory}/mvn-repo</altDeploymentRepository>
        </configuration>
    </plugin>
</plugins>

Now try running mvn clean deploy. You'll see that it deployed your maven repository to target/mvn-repo. The next step is to get it to upload that directory to GitHub.

Add your authentication information to ~/.m2/settings.xml so that the github site-maven-plugin can push to GitHub:

<!-- NOTE: MAKE SURE THAT settings.xml IS NOT WORLD READABLE! -->
<settings>
  <servers>
    <server>
      <id>github</id>
      <username>YOUR-USERNAME</username>
      <password>YOUR-PASSWORD</password>
    </server>
  </servers>
</settings>

(As noted, please make sure to chmod 700 settings.xml to ensure no one can read your password in the file. If someone knows how to make site-maven-plugin prompt for a password instead of requiring it in a config file, let me know.)

Then tell the GitHub site-maven-plugin about the new server you just configured by adding the following to your pom:

<properties>
    <!-- github server corresponds to entry in ~/.m2/settings.xml -->
    <github.global.server>github</github.global.server>
</properties>

Finally, configure the site-maven-plugin to upload from your temporary staging repo to your mvn-repo branch on Github:

<build>
    <plugins>
        <plugin>
            <groupId>com.github.github</groupId>
            <artifactId>site-maven-plugin</artifactId>
            <version>0.11</version>
            <configuration>
                <message>Maven artifacts for ${project.version}</message>  <!-- git commit message -->
                <noJekyll>true</noJekyll>                                  <!-- disable webpage processing -->
                <outputDirectory>${project.build.directory}/mvn-repo</outputDirectory> <!-- matches distribution management repository url above -->
                <branch>refs/heads/mvn-repo</branch>                       <!-- remote branch name -->
                <includes><include>**/*</include></includes>
                <repositoryName>YOUR-REPOSITORY-NAME</repositoryName>      <!-- github repo name -->
                <repositoryOwner>YOUR-GITHUB-USERNAME</repositoryOwner>    <!-- github username  -->
            </configuration>
            <executions>
              <!-- run site-maven-plugin's 'site' target as part of the build's normal 'deploy' phase -->
              <execution>
                <goals>
                  <goal>site</goal>
                </goals>
                <phase>deploy</phase>
              </execution>
            </executions>
        </plugin>
    </plugins>
</build>

The mvn-repo branch does not need to exist, it will be created for you.

Now run mvn clean deploy again. You should see maven-deploy-plugin "upload" the files to your local staging repository in the target directory, then site-maven-plugin committing those files and pushing them to the server.

[INFO] Scanning for projects...
[INFO]                                                                         
[INFO] ------------------------------------------------------------------------
[INFO] Building DaoCore 1.3-SNAPSHOT
[INFO] ------------------------------------------------------------------------
...
[INFO] --- maven-deploy-plugin:2.5:deploy (default-deploy) @ greendao ---
Uploaded: file:///Users/mike/Projects/greendao-emmby/DaoCore/target/mvn-repo/com/greendao-orm/greendao/1.3-SNAPSHOT/greendao-1.3-20121223.182256-3.jar (77 KB at 2936.9 KB/sec)
Uploaded: file:///Users/mike/Projects/greendao-emmby/DaoCore/target/mvn-repo/com/greendao-orm/greendao/1.3-SNAPSHOT/greendao-1.3-20121223.182256-3.pom (3 KB at 1402.3 KB/sec)
Uploaded: file:///Users/mike/Projects/greendao-emmby/DaoCore/target/mvn-repo/com/greendao-orm/greendao/1.3-SNAPSHOT/maven-metadata.xml (768 B at 150.0 KB/sec)
Uploaded: file:///Users/mike/Projects/greendao-emmby/DaoCore/target/mvn-repo/com/greendao-orm/greendao/maven-metadata.xml (282 B at 91.8 KB/sec)
[INFO] 
[INFO] --- site-maven-plugin:0.7:site (default) @ greendao ---
[INFO] Creating 24 blobs
[INFO] Creating tree with 25 blob entries
[INFO] Creating commit with SHA-1: 0b8444e487a8acf9caabe7ec18a4e9cff4964809
[INFO] Updating reference refs/heads/mvn-repo from ab7afb9a228bf33d9e04db39d178f96a7a225593 to 0b8444e487a8acf9caabe7ec18a4e9cff4964809
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 8.595s
[INFO] Finished at: Sun Dec 23 11:23:03 MST 2012
[INFO] Final Memory: 9M/81M
[INFO] ------------------------------------------------------------------------

Visit github.com in your browser, select the mvn-repo branch, and verify that all your binaries are now there.

enter image description here

Congratulations!

You can now deploy your maven artifacts to a poor man's public repo simply by running mvn clean deploy.

There's one more step you'll want to take, which is to configure any poms that depend on your pom to know where your repository is. Add the following snippet to any project's pom that depends on your project:

<repositories>
    <repository>
        <id>YOUR-PROJECT-NAME-mvn-repo</id>
        <url>https://github.com/YOUR-USERNAME/YOUR-PROJECT-NAME/raw/mvn-repo/</url>
        <snapshots>
            <enabled>true</enabled>
            <updatePolicy>always</updatePolicy>
        </snapshots>
    </repository>
</repositories>

Now any project that requires your jar files will automatically download them from your github maven repository.

Edit: to avoid the problem mentioned in the comments ('Error creating commit: Invalid request. For 'properties/name', nil is not a string.'), make sure you state a name in your profile on github.

edited Mar 04 '20 at 21:20

Ginkobonsai

177
3
13

answered Dec 23 '12 at 18:43

emmby

99,783
65
191
249

2

(Note that the preferred way to host maven artifacts is to still use a nexus server. However, using github can work as a lightweight alternative when an existing server or hosting your own is not an easy option. Also, note that you won't be able to browse your maven repository directly. Github does not allow you to browse directory structures when using raw. However, you can always browse the repo by going to your github page and browsing the `mvn-repo` branch.) – emmby Dec 23 '12 at 18:43
28

Note also that this solution will overwrite your previous artifacts every time you deploy. This is appropriate for snapshot repositories, but not for released artifacts. To disable that behavior, set `true` in your site-maven-plugin configuration. If you do that, though, I think you'll have to manually create the mvn-repo branch in github and delete all its files the first time around. – emmby Dec 23 '12 at 21:47
13

+1 clever and well presented. My only criticism is that you did not include a link to the Maven plugins site: https://github.com/github/maven-plugins. Thx I was looking for a way to publish my Maven site to github! – Mark O'Connor Dec 23 '12 at 23:46
Alternative approach which perhaps takes care of your versioning problem: http://cemerick.com/2010/08/24/hosting-maven-repos-on-github/. Less elegant, but uses Maven client to publish locally. Perhaps one could encorporate this into a new Maven plugin for git. – Mark O'Connor Dec 23 '12 at 23:57
1

Thanks Mark! Thanks for the link. I did actually include a link to https://github.com/github/maven-plugins#readme, but it's useful to have it here as well. Also, the cemerick link was a starting point for this solution. It's good stuff, but it doesn't automate the push to github. – emmby Dec 24 '12 at 00:24
I take back my criticism :-) – Mark O'Connor Dec 24 '12 at 08:41
1

This clever hack seems to work if you own the source to the jar you want to publish, but what if you don't have the source? – Ring Jan 06 '13 at 03:51
Thanks for this cool little approach @emmby. But as mentioned in the below post, could you please clarify a bit as to how another project's POM would reference the binaries we push to our repo...? Especially, what is it that does into `` & `` elements of the repository? Is there any convention there..? Can one test the url to ensure it will work fine...? I was able to create & push the mvn-repo branch for my project onto GitHub. But not clear how to specify the repo-URL & id in the dependent project's POM. (Please refer to my post below). Many thanks. – fritz Mar 13 '13 at 09:26
Though I have specified the username and password in the settings.xml, while using github as repository the build is not able to download the files. ` id https://github.com/My-Group/comapny/tree/mvn-repo/ true always ` – Nandish A Mar 14 '13 at 12:55
@genthaler made some edits that completely broke this for me. Specifically the distributionManagement section stopped working. I've reverted back to the previous version, but see http://stackoverflow.com/revisions/14013645/3 if you want to see his revisions – emmby Oct 08 '13 at 18:49
8

This approach does not work when Two-Factor authentication is used on github. See my note in the issue here: https://github.com/github/maven-plugins/issues/36#issuecomment-31005606 – Dag Dec 20 '13 at 12:09
20

In order to make this work for **multi-module projects**, you can also simply use `internal.repo::default::file://${user.dir}/target/mvn-repo` with the *maven-deploy-plugin*, and `${user.dir}/target/mvn-repo` with *site-maven-plugin*. This will deploy all artifacts into the root ("parent") project, and push them to the respective parent direcory on github. Otherwise, the build of each sub-module will overwrite that of the sub-module built before... – s.d Feb 25 '14 at 16:58
In the server settings, you may omit your username and replace your password with a scope-limited access token. See: https://github.com/github/maven-plugins – Travis Mar 14 '14 at 04:34
1

If you don't want to include your github login in your settings.xml, [you can use OAuth2](https://github.com/github/maven-plugins#settingsxml) – thomas88wp May 31 '14 at 14:53
If you are using maven version 3.1 or above, you need to change the version of site-maven-plugin to 0.9, or you will see this error: Execution default of goal com.github.github:site-maven-plugin:0.8:site failed: An API incompatibility was encountered while executing com.github.github:site-maven-plugin:0.8:site: java.lang.NoSuchMethodError: org.apache.maven.execution.MavenSession.getRepositorySession()Lorg/sonatype/aether/RepositorySystemSession; – Geir Engdahl Jun 05 '14 at 07:05
@emmby Thanks for the awesome answer. I'd successfully able to host maven repo on github. How can I achieve this for bitbucket. – Shashank Agrawal Aug 19 '14 at 07:19
@emmby: wonderful answer... the whole thing works like charm.. only thing I am yet to figure out is how to do this if my git repo is private... any help? – azi Oct 13 '14 at 07:12
This doesn't seem to work anymore with the current state of github – quarks Dec 01 '14 at 17:44
7

Two suggestions that make it work (at least for me): Set current version of Github plugin (right now it would be 0.11). Also I would suggest everybody to use a OAUTH token instead of the password. You can generate it in 'Settings->Applications->Personal Access Tokens'. Than you also can inline it into the POM via and store the token as environment variable. ````YourUserName ${GITHUB_OAUTH_TOKEN```` – Florian Loch Feb 12 '15 at 18:55
This answer sounds like such an overhead compared to what Bae is suggesting in his answer... – iku Mar 12 '15 at 14:01
@s.d i tried your solution, and the `maven-site-plugin` says: *basedir does not exist* (despite the fact it is indeed exists). :( – WonderCsabo Apr 18 '15 at 08:42
Is there a way to use this with a organisation repo? I tried to use the organisation name in the element, but it didn't work. I also tried with organisation owner usernames to the same result. – Simeon May 03 '15 at 11:23
It is possible to use with an organization repo. Use your github user name and password in the `settings.xml` file and set `your-organization-name` in the pom file. – Max Jul 13 '15 at 20:20
Hi, following above suggestion, i am getting below error trace while doing mvn deploy. org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal com.github.github:site-maven-plugin:0.12:site (default) on project spark-parent_2.10: Error creating commit: Invalid request. For 'properties/name', nil is not a string. For 'properties/name', nil is not a string. – piyush.mukati Dec 12 '15 at 10:30
I have a video tutorial about Maven deploy (https://www.youtube.com/watch?v=gBd5Yraoqp4) and release (https://www.youtube.com/watch?v=FFq0V_LZGZ4) to GitHub. – Sven Amann Mar 10 '16 at 11:18
This method implies a repo per artifact approach. Of course you could use the same shared staging directory for all artifacts, but once you have a large enough repo you will have problems with Java memory heap. I would prefer to use the Maven exec plugin and call the git binary to push the new artifacts. – lordscales91 Dec 16 '16 at 12:26
Has anyone gotten this to work with private repositories as of December 2016? Perhaps redundant, but I asked question here: http://stackoverflow.com/questions/41192900/using-a-private-github-repository-to-host-a-private-maven-artifact. The dependent project was unable to download the jar using either username and password, or a token, when the repo was set to private. Things were fine when it was public. – Justin Dec 19 '16 at 15:10
@WonderCsabo this happened for me when I copy-pasted the code above. It did something strange with the character encoding of the filename. Try typing out mvn-repo explicitly, it should work. – user1580492 May 30 '17 at 18:05
Thanks for this post, it is very helpful. However, after getting it all to work on a multi-module project I found that there are some GitHub restrictions on the size of artifacts. We have some all-inclusive uber-jars that were 50MB, and the upload to GitHub failed for those (I am assuming because of size, smaller ones worked). It was also very slow to upload. I am thinking a private repo or one of the services is really the only way to go for a sizable project. – dbschwartz Nov 25 '17 at 14:38
It took me a few attempts to get things working with a github person access token. here it is an example in the public domain https://github.com/simbo1905/microservices-demo/blob/f68e21736f72939e72d76e3dce9b4777c10592e2/pom.xml#L135 You need to generate a GitHub personal access token and give it the scope to publish to the repo and read your email address as per https://github.com/github/maven-plugins/issues/63#issuecomment-102610887. Then you need to set the token as an envar with `export GITHUB_OAUTH_TOKEN=xxx` – simbo1905 Feb 18 '19 at 11:38
As of 31-Aug-2020, this does not work (anymore). When I try to access my repo on github with the mentioned URL format `https://github.com/YOUR-USERNAME/YOUR-PROJECT-NAME/raw/mvn-repo/`, it simply returns a 404. – basZero Aug 31 '20 at 21:03
How to use this repo as an artifact while creating a maven project? Like this `mvn archetype:generate "-DarchetypeGroupId=org.example" "-DarchetypeArtifactId=sem-ver" "-DarchetypeVersion=1.0.0" "-DgroupId=com.example" "-DartifactId=boilerplate-semver" "-Dversion=1.0.0" "-DinteractiveMode=false"`. – Mani Feb 07 '22 at 14:51

Bae · Answer 2 · 2018-01-28T01:59:05.503

129

Don't use GitHub as a Maven Repository.

Edit: This option gets a lot of down votes, but no comments as to why. This is the correct option regardless of the technical capabilities to actually host on GitHub. Hosting on GitHub is wrong for all the reasons outlined below and without comments I can't improve the answer to clarify your issues.

Best Option - Collaborate with the Original Project

The best option is to convince the original project to include your changes and stick with the original.

Alternative - Maintain your own Fork

Since you have forked an open source library, and your fork is also open source, you can upload your fork to Maven Central (read Guide to uploading artifacts to the Central Repository) by giving it a new groupId and maybe a new artifactId.

Only consider this option if you are willing to maintain this fork until the changes are incorporated into the original project and then you should abandon this one.

Really consider hard whether a fork is the right option. Read the myriad Google results for 'why not to fork'

Reasoning

Bloating your repository with jars increases download size for no benefit

A jar is an output of your project, it can be regenerated at any time from its inputs, and your GitHub repo should contain only inputs.

Don't believe me? Then check Google results for 'dont store binaries in git'.

GitHub's help Working with large files will tell you the same thing. Admittedly jar's aren't large but they are larger than the source code and once a jar has been created by a release they have no reason to be versioned - that is what a new release is for.

Defining multiple repos in your pom.xml slows your build down by Number of Repositories times Number of Artifacts

Stephen Connolly says:

If anyone adds your repo they impact their build performance as they now have another repo to check artifacts against... It's not a big problem if you only have to add one repo... But the problem grows and the next thing you know your maven build is checking 50 repos for every artifact and build time is a dog.

That's right! Maven needs to check every artifact (and its dependencies) defined in your pom.xml against every Repository you have defined, as a newer version might be available in any of those repositories.

Try it out for yourself and you will feel the pain of a slow build.

The best place for artifacts is in Maven Central, as its the central place for jars, and this means your build will only ever check one place.

You can read some more about repositories at Maven's documentation on Introduction to Repositories

edited Jan 28 '18 at 01:59

answered Mar 05 '14 at 22:30

Bae

7,516
5
36
42

3

Totally agree, and makes sense for forks you want to keep around for awhile. But this can be a lot of overhead for just a small patch to an existing project. – emmby Mar 06 '14 at 19:02
If it is short lived, then get them to build it themselves. You will always face trade-offs like this. – Bae Mar 17 '14 at 23:18
6

I doubt Github has a problem with it, as they wrote the plugin that enables this capability. I agree it's less than idea, but c'est la vie. – PHY6 Jun 25 '14 at 17:05
4

It's not always possible to deploy an open source project on Sonatype. For instance when your project depends on another open source project that it isn't already deployed (and it can't be deployed because it doesn't meet the sonatype requirements). – Gab Aug 28 '14 at 12:27
1

@Gab then your dependency is not really open source. You should contact the other project and explain this and get them to fix their licensing. (Sun was a culprit of this behaviour in the past) – Bae Oct 08 '14 at 05:59
1

@Bae It is not a question of licensing. Some project owner decide not to publish on central simply because it's not their priority. Your way is not possible in the real world. If you want to test: convince this to publish on Central https://code.google.com/p/sd-dss/ . It's a big Open Source project funded by EU community :) – Gab Oct 12 '14 at 11:16
1

@Gab Then push it yourself to Central. The Sonatype documentation outlines the steps you need and if it is truly open source then *anyone* can do this. – Bae Oct 13 '14 at 06:26
@Bae the UsageGuide link is dead. Would you please update it? I think the new location is http://central.sonatype.org/pages/ossrh-guide.html – Justin Wrobel Dec 12 '14 at 20:09
1

There is another issue with the github solution: if someone wants to use your stuff, he wants to be sure that the repo won't lose the artifact, gets shut down or whatever. Deleting a repo on Gitrhub is easy. It's not as easy on Central. Using github for snapshot releases seems reasonable though. – user1050755 Mar 02 '16 at 10:49
How about a simple argument that using Github speeds up things 10-fold for a beginner? Learning, practicing and troubleshooting maven central deployments will take years for a novice. It is totally not user friendly – Andrey Chaschev Nov 12 '17 at 23:32
@AndreyChaschev As outlined in the solution, your trade off is that it slows down your build for every extra Maven Repo that needs checking. If you have valid feedback about the usability issues of Maven Central then pursue getting them fixed. Adding layers of workarounds isn't the right answer either. – Bae Nov 13 '17 at 03:50
@Bar finding the way that others people value and actually use is the best way. JS was a slow, narrow scoped and let's say not serious platform in the beginning, now it's artefact deployment system leaves Java far behind. All thanks to community. Github represents community and is easy to use. The other available thing is Maven hosted repository at JFrog's Bintray which is free for Open Source – Andrey Chaschev Nov 16 '17 at 05:55
1

You are correct, after trying the approach above I found with large uber-jars GitHub's API would consume them and we had to abandon this direction. With the limitations and the time it takes to upload to GitHub it convinced me that GitHub is just not the right tool. Someone commented that GitHub made this plugin, which is true, but it's really for GitHub Pages (which are small and not an issue). Hosting your own Maven repo or possibly one of the repo services is best (although the services don't look great or they are very expensive). – dbschwartz Nov 25 '17 at 14:41
this option would get less downvotes if it actually explained why using github-based repo in particular is bad, instead of just spreading FUD about using multiple repos and large files in git in general – OlegYch Jan 25 '18 at 13:30
@OlegYch Thanks for your feedback. Could you elaborate how the details under why 1) and 2) are FUD. They are clear explicit reasons for why a github-based repo is a bad idea. – Bae Jan 26 '18 at 04:44
@Bae it is fud because it assumes that a) having multiple repos is always bad, b) having binaries in any git repo is bad; and has nothing to do with hosting a maven repo on github – OlegYch Jan 27 '18 at 21:22
@OlegYch As per the explanation, a) having multiple repositories slows down your maven build, as each artifiact is checked in every repository. That is not FUD, that is fact.b) git is meant for version control, binary artifacts are outputs and something that can be regenerated, they dont benefit from version control and git's differencing algorithms, they just bloat your git repo and slow down people's clones. But I can see how the answer isn't explicitly explain that. – Bae Jan 28 '18 at 00:46
@OlegYch Thanks for the feedback, I've updated the answer text to include more detail. – Bae Jan 28 '18 at 01:59
GitHub introduced https://git-lfs.github.com/ solution, that costs $5/mo for 50GB storage and 50GB bandwidth. – Nik Handyman Feb 20 '18 at 00:23
@n0mer That's great about git-lfs, but how does that address the real concerns I raise in this answer? It doesn't. If it's open source then it belongs in only one repo *Maven Central*. – Bae Feb 20 '18 at 04:12
@Bae it addresses your concern of not storing binaries in git - and offers appropriate way how to mitigate it. – Nik Handyman Feb 20 '18 at 13:45
@n0mer Fair enough, the bloating however is the least of the concerns :) – Bae Feb 20 '18 at 20:56
if you want to only speed up gradle sync then you can see the following post https://stackoverflow.com/a/57686895/2629825 – Muhammad Omer Aug 28 '19 at 07:37

score 52 · Answer 3 · edited Jan 25 '19 at 09:55

52

You can use JitPack (free for public Git repositories) to expose your GitHub repository as a Maven artifact. Its very easy. Your users would need to add this to their pom.xml:

Add repository:

<repository>
    <id>jitpack.io</id>
    <url>https://jitpack.io</url>
</repository>

Add dependency:

<dependency>
    <groupId>com.github.User</groupId>
    <artifactId>Repo name</artifactId>
    <version>Release tag</version>
</dependency>

As answered elsewhere the idea is that JitPack will build your GitHub repo and will serve the jars. The requirement is that you have a build file and a GitHub release.

The nice thing is that you don't have to handle deployment and uploads. Since you didn't want to maintain your own artifact repository its a good match for your needs.

edited Jan 25 '19 at 09:55

Anton Krosnev

3,964
1
21
37

answered May 04 '15 at 16:39

Andrejs

26,885
12
107
96

1

JitPack is pretty good, but forces you to change every groupId that you have around. They say that this can be avoided, but it requires that you add an entry to the DNS of your company, which is totally impractical in most cases. I've been trying with JP once, then I decided that this is too stupid to go ahead. – zakmck Sep 22 '15 at 15:31
1

Changing the groupId of your projects is not necessary. You can still install those projects using 'com.github.User' groupId. But perhaps your use case is different. – Andrejs Sep 22 '15 at 16:41
Yes, it is very much. Because I already have tens of them around my organisation and external users, and because I want my own brand on them. How one can be so fool to try to force me into his own groupId is one of the things why I'm thinking of making a career change. – zakmck Sep 22 '15 at 16:45
Moreover, I don't see any real need for JP guys to throw such requirement at me (they could just intercept Maven requests from the repository spec). – zakmck Sep 22 '15 at 16:51
Sure, but then you could easily fake the groupId and pretend you are another organisation. GroupId needs to be verified somehow and DNS records is one way of doing it. How would you deal with it? – Andrejs Sep 22 '15 at 16:52
But this can be solved by other means, e.g. adding /user or /organisation to the repository URL. It's actually something that was already fine in Maven, I don't see any sensible reason to introduce their own coordinate system, which is impossible to comply with in most situations. And it's a shame, cause, for the rest, JP is very cool. – zakmck Sep 22 '15 at 16:56
Well, that sounds reasonable. Maybe open a feature request?:) – Andrejs Sep 23 '15 at 10:27
1

Good idea, I've done it: https://github.com/jitpack/jitpack.io/issues/209, thanks :-) – zakmck Sep 23 '15 at 12:44
Also, Maven Central will stop supporting `com.github.*` from April 2021, the alternative is to use `io.github.*` https://central.sonatype.org/changelog/#2021-04-01-comgithub-is-not-supported-anymore-as-a-valid-coordinate – julian-alarcon Apr 13 '21 at 17:47

score 23 · Answer 4 · edited Dec 07 '19 at 05:55

23

Since 2019 you can now use the new functionality called Github package registry.

Basically the process is:

generate a new personal access token from the github settings
add repository and token info in your settings.xml

deploy using

mvn deploy -Dregistry=https://maven.pkg.github.com/yourusername -Dtoken=yor_token

edited Dec 07 '19 at 05:55

HRJ

17,079
11
56
80

answered Sep 29 '19 at 01:46

Ruslan López

4,433
2
26
37

1

As of 2019, this is the best option. – HRJ Dec 07 '19 at 05:56
2

But for using it by someone else, it looks like he/she needs to configure settings.xml with respective URL and auth info – hemu May 09 '20 at 05:45
3

Very strange... You create your public package, but another people need authentication before get it – Amerousful May 12 '20 at 09:32
However, for private repos, after certaing usages / month, the pricing comes into picture – Lokeshwar Tailor Jun 12 '20 at 15:37
5

`Github Package Registry` is useless for open source projects because clients cannot download artifacts without authorization. – expert Feb 03 '21 at 19:04

score 9 · Answer 5 · answered Sep 27 '13 at 13:49

Another alternative is to use any web hosting with webdav support. You will need some space for this somewhere of course but it is straightforward to set up and a good alternative to running a full blown nexus server.

add this to your build section

     <extensions>
        <extension>
        <artifactId>wagon-webdav-jackrabbit</artifactId>
        <groupId>org.apache.maven.wagon</groupId>
        <version>2.2</version>
        </extension>
    </extensions>

Add something like this to your distributionManagement section

<repository>
    <id>release.repo</id>
    <url>dav:http://repo.jillesvangurp.com/releases/</url>
</repository>

Finally make sure to setup the repository access in your settings.xml

add this to your servers section

    <server>
        <id>release.repo</id>
        <username>xxxx</username>
        <password>xxxx</password>
    </server>

and a definition to your repositories section

            <repository>
                <id>release.repo</id>
                <url>http://repo.jillesvangurp.com/releases</url>
                <releases>
                    <enabled>true</enabled>
                </releases>
                <snapshots>
                    <enabled>false</enabled>
                </snapshots>
            </repository>

Finally, if you have any standard php hosting, you can use something like sabredav to add webdav capabilities.

Advantages: you have your own maven repository Downsides: you don't have any of the management capabilities in nexus; you need some webdav setup somewhere

score 7 · Answer 6 · answered Aug 24 '14 at 13:00

7

As an alternative, Bintray provides free hosting of maven repositories. That's probably a good alternative to Sonatype OSS and Maven Central if you absolutely don't want to rename the groupId. But please, at least make an effort to get your changes integrated upstream or rename and publish to Central. It makes it much easier for others to use your fork.

answered Aug 24 '14 at 13:00

Guillaume

18,494
8
53
74

3

I couldn't believe it when I tried, but Bintray doesn't support snapshots. Useless. – zakmck Sep 22 '15 at 15:33
6

It's not free anymore. $150 a month. – Johann Oct 06 '16 at 00:46
I think it is fee for open source software projects: https://www.jfrog.com/open-source/ – iBiber Sep 09 '17 at 08:26
1

JFrog is shutting down Bintray and JCenter. https://jfrog.com/blog/into-the-sunset-bintray-jcenter-gocenter-and-chartcenter/ – Joe Bowbeer Apr 05 '21 at 03:03

score 0 · Answer 7 · answered Oct 09 '18 at 20:58

0

If you have only aar or jar file itself, or just don't want to use plugins - I've created a simple shell script. You can achieve the same with it - publishing your artifacts to Github and use it as public Maven repo.

answered Oct 09 '18 at 20:58

Orest Savchak

4,529
1
18
27

score 0 · Answer 8 · answered May 26 '21 at 06:48

0

I'd like to add another alternative, a Gradle plugin I've been working on lately: magik.

Basically it allows to publish directly on a github repository acting as a maven repository.

answered May 26 '21 at 06:48

elect

6,765
10
53
119

score 0 · Answer 9 · answered Nov 21 '21 at 20:13

I came here looking to do the same thing, unlitmately host my Maven repository for free, but after more research I ended up here: https://jfrog.com/start-free/

The setup was quite strightforward, has a good free tier which will serve me for the forseeable future, and has additional (paid for) upgrades which may well come in handy in the future.

So far I am very pleased indeed !

Hosting a Maven repository on github

9 Answers9

Linked