• a 3rd-party lib is not on Maven central or the desired version is missing
• you built modules/libraries which will be included in your other projects
• …

With the following steps you will be able to serve any artifact from a public GitHub repository by just added a few lines into your pom.xml. I personally wasted quite an amount of time on this topic so I guess I’ll save it here – for you and me.

Ready? Let’s start!

In our example we’ll use our GitHub repository to server a file which is not available at Maven Central as the time of writing.

1. Creating the GitHub repository

Follow this link and create a new repository named mavenrepo.

You could as well choose a different name but then you will have to change every occurance in the following steps. Your call.

2. Creating the content for this repository

Change into the folder where the new repository will be lying on your disk. From here you will be able to push changes into your remote repository and thus update your artifacts.

1
2
3
4
5
6
7
8
9
10
11
12
13

~>cd dev
~/dev>mkdir mavenrepo
~/dev>cd mavenrepo
~/dev/mavenrepo>git init
~/dev/mavenrepo>git remote add origin git@github.com:YOURUSERNAME/mavenrepo.git
~/dev/mavenrepo>mkdir releases snapshots
#empty dirs can't be added to git
~/dev/mavenrepo>touch releases/README
~/dev/mavenrepo>touch snapshots/README
~/dev/mavenrepo>git add .
~/dev/mavenrepo>git commit -m "Initial setup"
#update the GitHub repo just for kicks
~/dev/mavenrepo>git push origin master

Cool, your local maven repository is waiting for it’s first artifact.

3. Creating the first artifact

Now you have to change to the location of your artifact-to-be.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

~/dev>cd ../../downloads/GoogleAnalyticsAndroid_1.3.1
~/downloads/GoogleAnalyticsAndroid_1.3.1>ls
libGoogleAnalytics.jar sample ReadMe.txt
#explanation below
~/downloads/GoogleAnalyticsAndroid_1.3.1>mvn deploy:deploy-file -DgroupId=com.google.android.apps -DartifactId=analytics -Dversion=1.3.1 -Dpackaging=jar -Dfile="libGoogleAnalytics.jar" -Durl=file:../../dev/mavenrepo/releases
 
[INFO] Scanning for projects...
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Building Maven Stub Project (No POM) 1
[INFO] ------------------------------------------------------------------------
[INFO]
[INFO] --- maven-deploy-plugin:2.5:deploy-file (default-cli) @ standalone-pom ---
Uploading: file:../../dev/mavenrepo/releases/com/google/android/apps/analytics/1.3.1/analytics-1.3.1.jar
Uploaded: file:../../dev/mavenrepo/releases/com/google/android/apps/analytics/1.3.1/analytics-1.3.1.jar (43 KB at 751.5 KB/sec)
Uploading: file:../../dev/mavenrepo/releases/com/google/android/apps/analytics/1.3.1/analytics-1.3.1.pom
Uploaded: file:../../dev/mavenrepo/releases/com/google/android/apps/analytics/1.3.1/analytics-1.3.1.pom (400 B at 24.4 KB/sec)
Downloading: file:../../dev/mavenrepo/releases/com/google/android/apps/analytics/maven-metadata.xml
Uploading: file:../../dev/mavenrepo/releases/com/google/android/apps/analytics/maven-metadata.xml
Uploaded: file:../../dev/mavenrepo/releases/com/google/android/apps/analytics/maven-metadata.xml (307 B at 23.1 KB/sec)
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 1.121s
[INFO] Finished at: Sun Sep 11 01:05:09 CEST 2011
[INFO] Final Memory: 3M/77M
[INFO] ------------------------------------------------------------------------

That’s (almost) it. Wait, what? No worries, I will explain the whole line for you so you can easily adjust it to your needs.

1
2
3
4
5
6

mvn deploy:deploy-file 
		#this specifies the artificat and will (=should) match with your dependency-declaration in pom.xml	
		-DgroupId=com.google.android.apps -DartifactId=analytics -Dversion=1.3.1 \ 
		-Dpackaging=jar \ #deploy as jar 
		-Dfile="libGoogleAnalytics.jar" \ #source file to deploy
		-Durl=file:../../dev/mavenrepo/releases #target folder to deploy

For 3rd-party-libraries which aren’t subject to change (i.e. no snapshots) use the releases folder for your own snapshots use – you guessed it – the snapshots folder.

Your maven repository is almost ready to serve.

4. Online artifacts!

Let’s change back to the maven repository. To make everything world accessible we have to commit and push the files.

1
2
3
4
5
6
7

~/downloads/GoogleAnalyticsAndroid_1.3.1>cd ../../dev/mavenrepo
# add everything which has changed or is new
~/dev/mavenrepo>git add .
# commit everything into the git-repo
~/dev/mavenrepo>git commit -m "Add Google Analytics library 1.3.1"
# push it to GitHub
~/dev/mavenrepo>git push origin master

So cool,eh? You can jump online to your GitHub repository to check if they’re there as expected. Aaalmost done.

5. Using your new maven repository

There are two ways to make maven aware of new repositories besides the pre-configured one. Either in ~/.m2/repositories/settings.xml which would be global for every repository but just for your user account. Or you can add the information into the pom.xml of your project. Since we want all developers for this project to easily use the new repository we will use the later.

Open your pom.xml and add the following lines for our example. Of course you have to edit the group-id, artifact and version according to your lib.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47

<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">
    <modelversion>4.0.0</modelversion>
    <!-- ... more project definition -->
 
    <dependencies>
 
        <dependency>
		<groupid>com.google.android.apps</groupid>
		<artifactid>analytics</artifactid>
		<version>1.3.1</version>
        </dependency>
        <!-- more dependecies... -->
    </dependencies>
 
    <!-- build config etc. ... -->
 
    	<repositories>
		<repository>
			<id>YOURUSERNAME-snapshots</id>
			<url>https://raw.github.com/YOURUSERNAME/mavenrepo/master/snapshots</url>
			<releases>
				<enabled>false</enabled>
				<updatepolicy>always</updatepolicy>
				<checksumpolicy>warn</checksumpolicy>
			</releases>
			<snapshots>
				<enabled>true</enabled>
				<updatepolicy>never</updatepolicy>
				<checksumpolicy>fail</checksumpolicy>
			</snapshots>
		</repository>
		<repository>
			<id>YOURUSERNAME-releases</id>
			<releases>
				<enabled>true</enabled>
				<updatepolicy>always</updatepolicy>
				<checksumpolicy>fail</checksumpolicy>
			</releases>
			<snapshots>
				<enabled>false</enabled>
				<updatepolicy>always</updatepolicy>
				<checksumpolicy>warn</checksumpolicy>
			</snapshots>
			<url>https://raw.github.com/YOURUSERNAME/mavenrepo/master/releases</url>
		</repository>
	</repositories>
</project>

That’s it!

6. Final: See it in action

Now we can start up maven to make use of the new configuration.

1

mvn clean package

If everything went well you should see “BUILD SUCCESS” and if you scroll up a bit you should see some Download-lines regarding your new repository. Maven will now try to load every new dependency from your GitHub-maven-repo so you can always decide if you want to host it yourself for some reason.

If you encountered errors along the way please let me know. This post is the result of several hours of trail and error and you should be fine following it. But of course it’s always possible you’ll run into problems.

Update:I noticed that I used the wrong group-id for my example. Normally it doesn’t hurt but it confuses everyone and so to be perfect added “.apps” to every occurance of this package-name.

stevie@box:~/dev/myproject/common [master]$


If you add the following lines into your ~/.bashrc you’ll always know which branch you are on.

Additionally you’ll be informed if the remote branch (if any) has been changed by adding “*” to the branches name. How cool is that?

stevie@box:~/dev/myproject/common [master *]$


Here are the lines to add which will do the magic for you:

1
2
3
4

export GIT_PS1_SHOWDIRTYSTATE=true
export GIT_PS1_SHOWUNTRACKEDFILES=true
export GIT_PS1_SHOWSTASHSTATE=true
export PS1="${PS1::$((${#PS1}-3))}\$(__git_ps1 ' [\[\e[34;1m\]%s\[\e[0m\]]')\$ "

I just love it. Thank you so much!

Link: Andy Maleh – Code Painter: Mouse-less Eclipse

If you could answer all these questions with a “yes” you might have noticed afterwards that you can’t do anything with this project because eclipse created it as “general project”, meaning no java, php or anything other specialized nature. This results in certain functions like Run as Java application not being accessable.

There are several solutions to that problem – but most of them are really ugly, imho. But since I don’t want to keep anything from you I will explain these methods too. So let’s get started…

The wrong way

The intuitive way you propably would start the task “to checkout a new project from SVN” might be “File -> New -> Project -> Others…-> Checkout a project from SVN”. In the result you’d have the previously mentioned “general project” which is pretty useless.

solution #1: edit .project

After the creation of the new project you quit eclipse, browse to the project folder in your file system and open the .project-file in a editor.

You’ll find these lines:

<natures>
</natures>

Change it to match:

<natures>
<nature>org.eclipse.jdt.core.javanature</nature>
</natures>

Save the file and fire up eclipse again, you will have your svn-project recognized as Java-project. This solution might be quick but the drawbacks are the quit/edit/start-sequence outside of eclipse and the necessity to find the right “nature” for your svn project.

solution #2: delete and recreate

After having completed the checkout you will delete your project. Yes, you read right. (I told you these methods are ugly! ) But when deleting be sure you don’t check the box for physically deletion of the files (so they’ll remain inside your workspace).

When you finished deleting the project you create a new project for the kind of project the svn project should represent (i.e. java, php etc.). While in the creation wizard be sure you select the same folder where the svn project has been checked out into.

The newly created project will have the right project type and will contain all files from the repository. Sometimes it is necessary to refresh the workspace (windows: hit F5 on the project).

Although this method also results in having the right data with the correct project type it has a bad taste jumping through these hoops in order to finish a simple task like that.

Since I wasn’t pleased with all those solutions I kept on looking. Finally I found…

The right way

Besides the following solution is the one most hoopless (no pun intended) the claim “right” is justified because it seems that this is the way the eclipse devs want us to check out a project.

In order to accomplish the task at hand you have to

• open the SVN Exploring-perspective
  ( Windows -> Open Perspective -> Other… -> SVN Exploring)
• create a new repository location or select the desired source
• browse to the parent folder of your new project (e.g. trunk)
• right click on the folder, choose Checkout…
• in the new dialogue you will have the chance to select Check out as a project configured using the New Project Wizard, take that chance, fill out the rest as you please and hit Finish
• in the new project wizard which will open next you can choose your desired project type (e.g. java) and set up everything like you would in a normal project (e.g. compliler compliance level, JRE, related projects etc.)
• after hitting this finish button you will notice that the svn is queried to retrieve the code
• and you’re done!

In my opinion this way is the most hazzle-free way to check out a new project though I love to see it the other way around too (New->Project->New Project from SVN -> yada yada yada -> “Please select a project type or press OK to let it remain a generel project.”). Until this is implemented I will go with the second best solution.

Have a good look a the compiled list and be sure to bookmark it for the next crisis with TSVN…

Link: Subversion and TortoiseSVN tips and tricks.

svn switch --relocate <oldUrl> <newUrl>

Mind that “oldUrl” and “newURl” have to be full addresses, not some kind of subdirs or relative to another.

Juist to mention it: Subversion 1.4 and 1.5 repositories are not backwards compatible and whenever you use a 1.5 client to check something in there is hardly any way to move back to 1.4 (and 1.4 clients won’t work with the repository anymore).

You might remember sentences like “But it worked yesterday!” or “Why the hell did I change that and when?” which were common companions when I looked at code I wrote a while back.

To avoid situations like this, a version control system could be a valid solution with more benefits than just less confusion.

Ernie Leseberg made the effort to collect most of the reasons I could think of on why to use a VCS with a small team or even if you are working alone.

If you don’t use a VCS yet give the article below a read and hopefully you will change your mind.

Link: Why use version control for solo developers or small teams