
If you often use maven, then you are surely faced with a situation when some necessary artifact is not in the maven central. Of course, you can always install the missing jarnik in your local repository
~/.m2
, but this adversely affects the portability of the build, because on the machine of a colleague who does not have this jar installed, the build will not be collected.
It is also possible to use a local file as a dependency not from the repository, but for this in the project it is again necessary to store it somewhere, and pushing to the source control is not very good.
But there is another option. You can use one of your Google Code or GitHub repositories as a repository for maven artifacts. Consider how this can be done.
')
I will show with the example of GitHub, but there is no fundamental difference, you can even use BitBucket, even Google Code. The main thing is that you have HTTP (S) access to the root of your repository.
As an example, I will put in the platform repository and tools from the Android SDK, because New versions of the platform in the maven central appear with a huge lag, if they appear at all. To simplify the deployment of the Android SDK, we will use the wonderful project
maven-android-sdk-deployer .
Go to GitHub and create a new repository, let's call it
maven-repo , for example. Make
git clone , go to the folder of our working copy and create two folders,
releases and
snapshots .
Install the Android SDK, download the required platforms and add-ons, and create the
ANDROID_HOME
environment variable pointing to the SDK.
We clone
maven-android-sdk-deployer . To install the platform components into your local
~/.m2
just
mvn install is enough, but we need to install the artifacts in our local repository. To do this, you need to slightly edit the root pom.xml. Open it, find the repo.url and put it to the URL pointing to the working copy of our repository. The URL to a point in the file system must begin with the prefix
file://
and, for example, it looks like this for me:
file: /// Users / TheDimasig / Dropbox / sources / my / maven-repo / releases
Everything is ready to enclose artifacts locally. We make
mvn deploy , recline on the back of the stool and enjoy the process :)
Attention at the time of writing the article maven-android-sdk-deployer, contained a bug . The fact is that Google decided to remove the analytics dzharnik from the SDK Manager, so that the process does not fall with an error at the analytics deployment step, you need to comment out the
analytics module inside
maven-android-sdk-deployer/extras/pom.xml
Almost everything is ready. Go to the folder of our repository and do
git add . git commit -m 'Android SDK artifacts' git push
The repository is initialized and ready to use! Open a maven project that needs dependencies from it and add the repository URL to pom.xml
<repositories> <repository> <id>d-tarasov-releases</id> <url>https://github.com/d-tarasov/maven-repo/raw/master/releases</url> </repository> </repositories>
That's all. Now in the project dependencies you can specify artifacts from our repository.
In addition, you can configure the deployment of our maven projects in the newly created repository. To do this, pom.xml needs to add a
distributionManagement section.
<distributionManagement> <repository> <id>repo</id> <url>https://github.com/d-tarasov/maven-repo/raw/master/releases</url> </repository> <snapshotRepository> <id>snapshot-repo</id> <url>https://github.com/d-tarasov/maven-repo/raw/master/snapshots</url> </snapshotRepository> </distributionManagement>
But if you make mvn deploy directly, then the build will fail, because maven will attempt to dump artifacts not into your local working copy of the artifact repository, but directly onto the github. To avoid this, you must call deploy with the
altDeploymentRepository parameter
. mvn -DaltDeploymentRepository=snapshot-repo::default::file:///Users/TheDimasig/Dropbox/sources/my/maven-repo/snapshots clean deploy
After that, you can do git add, commit and push your artifact to the githabb as usual.
The big disadvantage is that GitHub has a limit on the maximum size of a binary file available via http. Because of this, some artifacts can not be used, since when accessing them via http, an error is issued
Error: blob is too big