Build process

Why Maven ?

 I had to decide which build system to use, Ant or Maven. We use Ant at work, and it's a fairly sophisticated script, using a lot of inheritance and overriding to build the project. I've written Ant scripts before, and to be honest, it's dull and a bit of a ballache. So I decided to try Maven as :
1. It's new
2. It'll save time on the build dependencies
3. It integrates with Eclipse through the m2Eclipse plug in.

I figured once it was up and running, it'd save time, and it's a useful tool to have.

Maven documentation

The Maven documentation isn't good, it reads like one of those guides that makes more sense after you've been using it a while. I've hunted through a few blogs, some of which are good, but that's inevitably fragmented. I'm using Apache Maven 2 Effective Implementation (by Ching and Porter) as my main reference, and it's proving reasonably useful : better than the initial review on Amazon suggests anyway.

What to use as a Maven repository ?

Maven generally recommends using a proxy repository, and after checking a good article on theserverside.com and the Maven book, decided to check out Archiva . It's turned out to be a good find, being very easy to set up and use, with decent documentation. Again, follow the wizards, there isn't much more to it.

Multi module Maven

So I started to generate a multi module Maven project. It turned out to be simple using the mvn:generate task, the only thing I'd have liked would be some guide to the archetypes available. For a newbie, the list is large and it's not clear what's going to be the best to use.
I hit one massive problem during the build, where the first module would build, but the second module couldn't find the first build's arrtifact, stating the jar could not be found in the local repository. Close review of the logs showed the first module was publishing to the local repository, and I could see it there.
The problem ? The dependency tag in each module's pom.xml :

      <dependencies>
        <dependency>
            <groupId>${project.groupId}</groupId>
            <artifactId>maven-importer</artifactId>
            <version>${project.groupId}</version>
        </dependency>
      </dependencies>

It should have read :

      <dependencies>
        <dependency>
            <groupId>${project.groupId}</groupId>
            <artifactId>maven-importer</artifactId>
            <version>${project.version}</version>
        </dependency>
      </dependencies>

Which drives home the lesson I find most days : it's almost always something simple.

Still, I now have a working Maven build system, and a local archive.

Dev environment

Version Control Choice


Even with something basic, version control is too useful to just omit. I decided to go with the latest version of Subversion (http://subversion.apache.org/) because

• I've administered small scale repositories before, and learning version control admin isn't an objective or something I want to spend any time on.
• With TortoiseSVN (http://tortoisesvn.tigris.org/) it integrates nicely into Windows Explorer, and it's easy to use
• I haven't tried the Subversion Eclipse plug in, but once it's up and running, I'll add this to the IDE.

Installation

I've installed Subversion on the Server machine, and was pretty impressed with the ease of use of Subversion 1.6.13. Previously at work I used a file repository and IIRC it was version 1.4, but setting this new release up as a web server repository proved stunningly easy, simply following the wizards. The browser based front end is pretty good. So now I've got a basic installation up and running, only two users (Admin and Dev users), and my first few files booked in, but with the ability to create multiple repositories as I need them.

Repository per project ? 
I did have an internal debate, whether to go for 1 repository for all projects, or 1 repository per project. I checked the first few links from a Google Search, and, at this point, the 1 repository per project model seems easier. I don't  have any requirements for hook scripts or other cross project concerns at this point, so the admin overhead isn't a consideration (yet)

So from now on, even dev files, Eclipse settings etc can be tracked and rolled back - useful when I'll be doing so much experimenting over the next few weeks. Nice.

Starting points

Hardware
I've currently got a Windows home network, run through a Zoom Modem / Router, with two increasingly old PC's linked. The oldest is an old Dell Pentium 2.4Ghz, 2 GB of RAM. Not the best, but it'll do as a host for the database, build system and application servers.
The other is slightly better HP xw4300 Workstation, 3.2Ghz Pentium D with 3GB of RAM. This is the development machine, but also remains the family PC.
Right now, I don't really want to spend any more money on hardware, so options like more RAM, SSD's etc are out, never mind getting new PC's. Besides, what I've got might not be shiny, but it'll meet my needs for now. Maybe later or if a windfall comes along, but right now I can't justify that  to the other half.

OS : Linux or Windows ?
I've done some Unix before, not much in the last few years, and we're using Linux at work at the moment. I know I could do  Linux VM's, but, improving my Linux isn't really an immediate concern,  and it'll just slow me down for a while. I'll take the easy option and stick with Windows on both. I'll come back to this later, maybe near the project end, and migrate the server to a Linux distro - no idea which one at this stage.

Why am I doing this ?

New Year, New Project
I've started a new software project at home. It'll be a new web app, a fairly standard view onto a database. The main goal of the project is to give me a chance to play with some frameworks that I haven't had a chance to work with yet, give some focus to my reading, explore the bits of IT that I have no experience of ( blogging, hosting and domain names came up straight away !) and if at the end of it, there's an opportunity to make some money out of it, bonus. This blog is to support this project.

What's the aim of the blog ?
In almost every project I've been involved in, normally  a couple of years afterwards, there's been a period of reflection and asking "Why did I choose to do it that way ?"  The main aim of the blog is to capture those decisions and the rationale behind them. By making it public, there might be a chance to get some external review of the decisions - one of the main problems of a one man project, which does limit the learning experience.

It's also going to be a place to put links to articles that have contributed to those decisions, problems encountered and the solutions adopted.

And the name comes from ? 
The name comes from the hundreds of decisions that will have to be made along the way, and the choices that are open. First steps are going to be to think about the supporting  infrastructure, then the stack I'm going to use.

Or at least, that's the idea anyway.