I’ve used Maven and Nexus at work quite extensively, and since I’ve become familiar with the tooling, I’ll never go back. When using a mature language like Java that has an expansive ecosystem, dependency management is a must. Maven has its rough edges, but it does get the job done, and I’ve always been pleasantly surprised with how easy it is to use Nexus and how little maintenance it really requires.
I’m planning on doing a bit more Java development at home, and I’d like to have my own Nexus repository hosted on my internal network. Part 2 of this article will cover configuring Nexus and the benefits of using it. In this part of the article, I’ll walk through the steps for setting up and configuring Nexus from a base Ubuntu 11.10 Server installation.
For my purposes, I would like the end result of my installation to be that I can go to nexus.my.home (a DNS name on my internal network) and be able to interact with Nexus, so I’ll be doing some additional configuration with Apache Web Server to make this happen.
It’s been a while since I’ve had to set up a new SVN repository on my home network, so now that its time, I figured I write a quick post documenting the steps along the way.
For those that may be unfamiliar with it, SVN is a commonly used version control system. It allows users to manage the changes to source code over time so that a user can quickly restore old versions, analyze change sets, and control how change sets are applied to a set of source code. SVN is likely the de facto open source centralized version control system. It grew up from the older CVS project, but it should be noted that it is a centralized version control system. There a number of distributed version control systems out there such as git, Mercurial, and Bazaar, which are gaining adoption very quickly and provide a number of benefits for projects with many users. For my home use, I’m the only user, and I’m familiar with the ins an outs of SVN, so I’ve stuck with it.
SVN is also one of the most well documented open source projects out there, primarily because of the excellent work that goes into the SVN Book. The online content is freely available, and its essentially the same content that is published in the O’Reilly reference. It is update often and is very comprehensive. If you have any questions about SVN, I’d start there.
Now that I’ve gotten that out of the way, on to the content. I want to set up an SVN Repository for a new project I’m working on. There are a number of ways in which you can choose to organize SVN, but I generally follow the 1 project per repo model. I use Apache and WebDav to connect to my SVN repos so that I can access them directly over http. Assuming you already have SVN and Apache installed, there are really three quick parts to the setup. Create the SVN Repo, Configure the WebDav connection, and Setup the SVN Repo.
Create the SVN Repo
To create the svn repo, you’ll make use of the svnadmin command line tool. It provides a number of SVN mainteance functions including the create repository functionality. I usually create the repository as root, and then after it is created update the permissions so that the web user is the owner and the group is the SVN group. This allows both Apache and SVN processes access to the files. The commands needed to set this up are below.
#create the new SVN repo
sudo svnadmin create /storage/svn/myNewRepo/
#change permissions on the new repo so that Apache and SVN can access it
sudo chown -R www-data.svn /storage/svn/myNewRepo/
Configure the WebDav Connection
Creating the WebDav interface is also just as easy. You’ll create a simple Location entry in your Apache configuration which defines the parameters needed for users and the SVN connection. For me, I put the configuration in the default website on my SVN server (on Ubuntu its /etc/apache2/sites-available/default), and I use the Apache AuthUserFile to control users of the repo. I have set up user accounts for other repos, so I’m just going to hook into the existing file.
The location information in my Apache file is shown below. I add it directly the default VirtualHost listing for the server.
AuthName "Subversion Repository"
From there, its just a quick Apache restart with sudo /etc/init.d/apache2 restart and then you should be able to access the repository over HTTP in your browser by going /svn/myNewRepo on your server (i.e. http://server.my.home/svn/myNewRepo). You should see a simple page listing the repository information, version 0 as the version number, and an empty directory since we haven’t added any content yet.
Setup the SVN Repo
Your svn repository is now ready to use. Most repositories follow the general pattern of a trunk/branches/tags structure, so to make sure things are working, I’m going to create those directories using the svn command line client. Thereare a number of ways to do this, but I’m just going to create one directory at a time directly on the server. The commands look like this.
svn mkdir http://server.my.home/svn/myNewRepo/trunk --message "Creating the basic SVN structure for the project"
svn mkdir http://server.my.home/svn/myNewRepo/branches --message "Creating the basic SVN structure for the project"
svn mkdir http://server.my.home/svn/myNewRepo/tags --message "Creating the basic SVN structure for the project"
And that is all that’s needed. You can verify that it worked by going to the svn repo’s web address again and verifying that the list of folders has updated. Typically you would then check out the SVN trunk and then start checking in your code.
I will be posting a series of articles on my experience with getting up and running with WordPress. In this post, I’ll outline the steps I went through to get WordPress up and running on my Ubuntu Web Server, but first a bit of background about why I’d even want to do this.
I’m setting up a blog to document some of my interests and various activities I’m involved in (you may have already guessed that since you’re already reading my blog). I have a hosting provider that allows me to setup and use WordPress fairly easily via a simple cPanel installation. Setup was pretty much a breeze and I was up and running with WordPress 2.9.2 in less than a minute or so.
One of the things I’ve always liked to have though is a sandbox environment. I’ve got a home network that consists of various salvaged and cobbled together machines, most of which run Ubuntu’s server distribution, and one of them is a “web server” set aside just for this type of thing.