Maven plugin groupId org.codehaus.mojo not searched by default??

I got interested in removing all my explicit org.codehaus.mojo declarations on my plugin dependencies since now Maven supports searching that groupId for a plugin's artifactId. This feature was added a while ago I guess.

Just came across a nasty little bug in Maven 2.2.1 which has been reported since 2.0.9.

[#MNG-4001] Unable to resolve Dashboard mojo from Central - jira.codehaus.org

The summary above is very misleading. In fact I consider myself lucky to find it since it more has to do with any org.codehaus.mojo based plugin.

When I did try to remove my plugin's groupIds I got the classic "Unable to find resource 'org.apache.maven.plugins:buildnumber-maven-plugin:pom:1.0-beta-4' in repository central".

Turns out this may be related to maven metadata in my local repo and/or the remote repos being randomly deleting version info???? See the bug followups for more info.

In fact this bug is nasty because
1. there is no mention in the error that is what could be wrong.
2. Adding a pluginGroups section to your ~/.m2/settings.xml file with that group changes nothing, even in the error output. Plus using -X shows that maven does not even try to locate org.codehaus.mojo version of that plugin or any other groupId specified in your pluginGroups settings. It may have looked at the metadata, but we would never know.
3. Deleting your local maven metadata may only fix the error temporarily or not at all.
4. Try this: Define your plugin configuration in pluginManagement without the groupId. Next, define the same plugin in a profile with the groupId. Run a mvn cmd that activates the profile and you will notice that none of your plugin settings inside plguinManagement gets picked up - and of course there is no warning or messages in the debug output that complain. Add the group id to the pluginManagement section and it all of a sudden works as expected.

So the rule of thumb is leave well enough alone and always explicitly specify the groupId for all plugins except org.apache.maven.plugins groupId which still work.

Blogger: Awesome code syntax highlighting made easy

This post represents my to-date findings on the best way to paste source code into a Blogger based blog post. The goal is to have something with enough sugar for reading the post in the browser and also having it RSS reader compatible.

Several poor man solutions are out there. Examples are here and here.
Basically these are javascript based apps which take your code and apply some html escaping and wrap it with a <pre> tag and inline styles.

I remembered liking what YUI uses on their site. It is a syntax highlighter written by Alex Gorbatchev and can be found here. A summary of how to add it to your Blogger posts is here. This is more advanced in terms of display and user options.

While 'pretty', the Gorbatchev highlighter has the caveat that all the sugar goes away in RSS readers. I mean it works, however the result is just monospaced font.

By combining the Gorbatchev highlighter with the simplified source code formatters approach, I can have the best of both. Code that looks good in the browser and also when read with an RSS reader.

1. Edit your blogger template following the instructions outlined here to activate the Gorbatchev SyntaxHighlighter.

2. (Optional) Install this Firefox add-on Clippings to make pasting the required html into the blogger editor easy.

3. Use the following html to wrap your source code you paste into the editor. Remember that any source code must be html escaped ( < brackets must be escaped!)

<pre class="brush: xml;" style="font-family:Andale Mono, Lucida Console, Monaco, fixed, monospace, monospace;font-size:12px;border:1px dashed #CCCCCC;width:99%;height:auto;overflow:auto;background:#f0f0f0;padding:0px;color:#000000;text-align:left;line-height:14px;">
<!-- your code goes here -->
</pre>

The "brush: xml" part indicates what type of source code you are formatting. I suggest making a new clipping in the Clippings add-on (step 2) for each type source code you typically are pasting into your blog. See this page for more info on brushes and this page on how to specify additional parameters to the source code formatter.

Make sure to use the pre element version of the code block and not the script element version since script tags are removed in rss feeds.

4. Test it out. Create a new blog post, click the 'Edit Html' tab of the blogger editor. Make sure the Post Options include "Show HTML Literally" checked. Right click inside the editor textbox and select a clipping from the Clippings menu to paste a preconfigured pre block. Add some source code and publish your post.
Note: To see the full effect remember to publish your post since the popup preview window in Blogger editor only shows the simplified version of the formatting.

Here is an example of what code will look like when viewed in a browser.

/**
 * SyntaxHighlighter  
 */  
function foo()  
{  
  // it works!  
}

Here is an example of what RSS readers typically display. The class attribute will have no effect.

/**
 * SyntaxHighlighter  
 */  
function foo()  
{  
  // it works!  
}

Caveats:
1. The flash based toolbar will not show up on some mobile platforms for obvious reasons. Not a big deal as that is just sugar.
2. The described solution I use depends on using the Clippings add-on in Firefox and therefore the Firefox browser. Other browsers may have some similar plugins available - I dunno. Either way it is not critical.

If anyone has found a better solution please let me know.

buildnumber-maven-plugin helpful improvements

I've used the buildnumber-maven-plugin to include revision ids and timestamps in my builds for many years. Today I upgraded to the most recent version and that helped get rid of a few workarounds I had in place.

Using a previous version of the plugin, if there was no svn on your path, or your project was not checked in yet to subversion, the plugin failed the build due to svn checks. The workaround I had was to add it to a profile that only got executed when .svn file existed and/or the useReleaseProfile property was 'true'.

Now I am relieved to see I don't need to do that anymore.

For one, there is a 'revisionOnScmFailure' property you can set in the configuration that will be used if there is any type of scm exception - a byproduct of which disables further scm communication.

Second you can specify the plugin to use the javasvn scm provider implementation in case there is no 'svn' executable on your PATH. At first pass it might seem unlikely that when dealing with a subversion based project a developer would not have svn on the path, and that is likely true. Consider though that the svn version may be wrong (in which case svn may complain about not being new enough and fail the build) or you are building in a continuous integration env like hudson and you want reproducible use of the same svn tool. In those cases it makes good sense to configure the plugin with "javasvn". See below example:

<plugin>
  <groupid>org.codehaus.mojo</groupid>
  <artifactid>buildnumber-maven-plugin</artifactid>
  <version>1.0-beta-4</version>
  <configuration>
    <revisiononscmfailure>UNKNOWN_REVISION</revisiononscmfailure>
    <providerimplementations>
      <svn>javasvn</svn>
    </providerimplementations>
  </configuration>
  <executions>
    <execution>
      <id>buildnumber-one</id>
      <phase>validate</phase>
      <goals>
        <goal>create</goal>
      </goals>
    </execution>
    <execution>
      <id>buildnumber-two</id>
      <phase>validate</phase>
      <goals>
        <goal>create</goal>
      </goals>
      <configuration>
        <format>r${buildNumber} {0,date,yyyy-MM-dd'T'HH:mm:ss.SSSZ}</format>
        <items>
          <item>timestamp</item>
        </items> 
      </configuration>
    </execution>
  </executions>
</plugin>

The two executions is so that I can give some context to the ${buildNumber} by prefixing it with 'r' and adding a timestamp formatted along with it.

There are a bunch of other useful properties in this latest release. Thanks to open source.

Mac OS X environment variables + Netbeans + Maven

Applications that are not launched through your terminal in OS X do not read environment variables from ~/.profile, ~/.bash_profile and similar. These applications that launch directly can get their environment from each user's ~/.MacOSX/environment.plist file. ( You have to create it!)

I heard of this before, but I wanted to make note of a quick way to ease the maintaining of that file and finally had a need because of Netbeans.

1. Downloaded Brian D Foy's Perl plist lib and installed it.
2. Used a 3 line script to generate the ~/.MacOSX/environment.plist file from my terminal's ENV variable as he suggested.
3.  Log out and log in for the file to take effect.
   

Now I can be sure the PATH that Netbeans sees is the same thing that mvn and other tools are seeing when I execute them on the cmd line. Also I don't really have to worry about maintaining my env in two places as one is derived from the other.

References
Technical Q&A QA1067: Setting environment variables for user processes
Helpful Summary of other ways to set env variables in OS X
Brian D Foy's Perl plist reader lib and blog post
Netbeans documentation on working with OS X Environment variables

Update
Another method is setting environment variables inside your

/etc/launchd.conf

file as described here - there are clear benefits to this for apps launched outside your personal login.

Maven Special Character Encoding Properties for Sites and Reports

Thanks to the post on the Sonatype blog I've got two other global properties to set in my global parent pom that sets the encoding for Maven reports - most of them anyways.

Sonatype Blog: Special Character Encoding Properties

project.build.sourceEncoding
project.reporting.outputEncoding

Thanks for the summary Anders Hammar.

Slipstream Service Pack 3 into Your Windows XP Installation CD

So I finally got bored of installing Windows XP a few times during some cross platform testing, setting it up with all my options and service packs etc.

I've got a Windows XP SP1a CD, but I wanted an SP3 install out-of-box. I had slipstreamed before, but somehow lost the CD during some moves. The good folks at lifehacker set me straight.

Slipstream Service Pack 3 into Your Windows XP Installation CD - Customization - Lifehacker

What I like about this solution the most is the use of nLite to create the whole package, which worked great! No cmd line work at all. It couldn't be easier I suppose.

Lastly since I was burning it from Windows XP running in VMWare Fusion, I had to enable DMA on the IDE channel my Mac Pro's CD drive was attached with.

Else nLite was throwing a burning error. Simple workaround below courtesy of this link here as a reminder.

To enable DMA mode using the Device Manager

1. Open Device Manager.
2. Double-click IDE ATA/ATAPI Controllers to display the list of controllers and channels.
3. Right-click the icon for the channel to which the device is connected, select Properties, and then click the Advanced Settings tab.
4. In the Current Transfer Mode drop-down box, select DMA if Available if the current setting is "PIO Only."
   If the drop-down box already shows "DMA if Available" but the current transfer mode is PIO, then the user must toggle the settings. That is:
   
   
   • Change the selection from "DMA if available" to PIO only, and click OK.
   • Then repeat the steps above to change the selection to DMA if Available.