Mac OS X doesn’t remount network drives when booted. You have to do this yourselves.

You can easily automate this by creating an application using the automator and add it to your login items.

You automator script should contain two items:

• Get Specified Servers
• Connect to Servers

Save the script as an application and put it into login items for your user account. This will execute your small application each time you login and you should be reconnected to your NAS on startup.

Many maven projects uses the maven site plugin to generate there documentation.

The maven-site-plugin uses the doxia to let authors write xdoc, apt and fml documents as the source for there project documentation. These written documents is processed by doxia to generate html and merged into the complete project site by the maven-site-plugin.

I found doxia and especially the apt language somehow lacking in functionality. I would like to use the syntaxhighlighter to be able to highlight code examples on the fixedformat4j project.

Doxia comes out-of-the-box with a small bunch of macros and you have the ability to write custom macros as well.

Custom macro

pom.xml:

    org.apache.maven.doxia
    doxia-modules
    1.0-alpha-11
  
  4.0.0
  com.ancientprogramming.maven.doxia
  doxia-module-syntaxhighlighter
  1.0-alpha-11
  Doxia :: syntaxhighlighter
  


        org.codehaus.plexus
        plexus-maven-plugin
        
          
            
              descriptor
            
          
        
      
    
  

Changes to the snippet plugin:

...
  public void execute(Sink sink, MacroRequest request)
      throws MacroExecutionException {
    System.out.println("ancientprogramming - running execute");
    String id = (String) request.getParameter("id");

    required(id, "id");

    String urlParam = (String) request.getParameter("url");

    String fileParam = (String) request.getParameter("file");

    String codeParam = (String) request.getParameter("code");

    required(codeParam, "code");

    URL url;

    if (!StringUtils.isEmpty(urlParam)) {
      try {
        url = new URL(urlParam);
      }
      catch (MalformedURLException e) {
        throw new IllegalArgumentException(urlParam + " is a malformed URL");
      }
    } else if (!StringUtils.isEmpty(fileParam)) {
      File f = new File(fileParam);

      if (!f.isAbsolute()) {
        f = new File(request.getBasedir(), fileParam);
      }

      try {
        url = f.toURL();
      }
      catch (MalformedURLException e) {
        throw new IllegalArgumentException(urlParam + " is a malformed URL");
      }
    } else {
      throw new IllegalArgumentException("Either the 'url' or the 'file' param has to be given.");
    }

    StringBuffer snippet;

    try {
      snippet = getSnippet(url, id);
    }
    catch (IOException e) {
      throw new MacroExecutionException("Error reading snippet", e);
    }

   sink.rawText("... syntaxhighlighter prefix ...");
   sink.rawText(snippet.toString());
   sink.rawText("... syntaxhighlighter postfix ...");
}
...

Note: wordpress obfuscates the above code where I wrote the syntax hightlighter pre and post fix. You can see what you actually should write at the syntaxhighligther project.

Use custom macro
To be able to use the macro you have to add your macro as dependency to the maven-site-plugin:

  org.apache.maven.plugins
   maven-site-plugin
   
     ${basedir}/src/site
     src/site/fixedformat4j-template.vm
   
   
    
      com.ancientprogramming.maven.doxia
      doxia-module-syntaxhighlighter
      1.0-alpha-11
    
  

%{code-snippet|id=basicusage|code=java|file=../../BasicUsageRecord.java}

Change your site template
Before the the source can be highlighted in your documentation you should add the syntaxhighlighter javascript and stylesheets to your template.
See how to change your template here.

This is the way I prefer tagging and branching my code when developing and releasing software. I use subversion but the overall guidelines can be applied by any versioning tool - say CVS.
I assume that you keep your source in the recommended structure:

• trunk
• tags
• branches

Versioning

Always use three digits to denote a release: major.minor.bugfix. ex: 1.2.0.

Name your trunk code like this: major.minor-SNAPSHOT, where major.minor denotes the next version to release. ex: The version in production is 1.2.0, you should name the trunk version 1.3-SNAPSHOT. I use snapshot to tell others that such a version is an arbitrary build along the way to a stable 1.3 release (The name ’snapshot’ is inherited from maven).

Releasing

When releasing your code, you should tag the version you release by the version. This gives you a chance to always branch from that specific release if a bugfix is required. Ex: you 1.3-SNAPSHOT is ready to go into production. Tag a version by the name 1.3.0.
Even though some versioning tools allow you to commit to a tag, you should not do so. Tags is an image of the sourcecode at the release time!

At the same time you should change your trunk version t0 1.4-SNAPSHOT.

Branching

If your newly created release contains a bug that can’t wait to be fixed until your next trunk release, you should create a branch. Do so from your release tag.

You should name your branch like this: major_minor_bugfix, where major and minor is the same as the software in production. Ex: 1_3_bugfix.

Merging

I do not recommend having unmerged code on your branch for to long.
I suggest you you merge your software back to trunk for each fix you do. At least you should merge your branch back to trunk when your release a new version.

To assist you in this I suggest your commit message tells what revisions that is involved, - The revision from the branch and the revision on trunk.

Subversion commands

The following is the commands to use in subversion. I assume you use ssh to access subversion and the subversion repository is located at ancientprogramming.com in the directory /var/subversion:

Tagging in subversion

$ svn copy svn+ssh://username@ancientprogramming.com/var/subversion/project/trunk \
svn+ssh://username@ancientprogramming.com/var/subversion/project/tags/1.0.0

Branching in subversion

Similar to tagging except the path.

$ svn copy svn+ssh://username@ancientprogramming.com/var/subversion/project/tags/1.0.0 \
svn+ssh://username@ancientprogramming.com/var/subversion/project/branches/1.0-bugfix

Merging

I will split this into two cases. The case where you merge from the branch the first time and the following merges.

First merge from a branch

First you want to know what revision you are to merge from.That is the revision your branch was created at. You find that revision by executing the following command in your branch checkout:

$ svn log –stop-on-copy

That will list all your changes created on your branch since it was created. You can see the revision where your branch where created in the log output.

Knowing the revision you are ready to merge your changes. Change to a working copy of your trunk code and make sure your checkout is up to date by executing and findout the revision to merge into:

$ svn up

This will update your trunk copy and output the revision you are to merge into.
Now merge the changes by using the following command on your trunk working copy:

$ svn merge -r rev1:rev2 \
svn+ssh://username@ancientprogramming.com/var/subversion/project/branches/1.0-bugfix

where rev1 equals the revision your branch was created and rev2 equals the revision on your trunk working copy.

Fix any conficts and commit your code. It is important that your commit message contains the to revisions you merged. I suggest you write the following. That message is important in later merges:

$ svn commit -m ‘Merged branches/1.0-bugfix rev1:rev2′

Following merges from branch

The next time you would like to merge, you execute the following in your working copy of your trunk code to find the revision to merge from:

$ svn log | grep -i merge

This assume that your commit message when merging contains the text merge - as we did in the first case.
The revision to use is the revision you merged into the last time +1.

Ex your log message looks something like this: ‘Merged project/brances/1_2_bugfix r1631:r1682 into head’, the revision to use is 1683.

With that version just repeat the steps from the ‘First merge from a branch’.

I suggest you read here to find more about branching and merging in subversion.