<profiles>
    <profile>
      <id>unix</id>
      <activation>
        <os>
          <family>unix</family>
        </os>
      </activation>
      <build>
        <plugins>
          <plugin>
            <groupId>org.codehaus.mojo</groupId>
            <artifactId>exec-maven-plugin</artifactId>
            <executions>
              <execution>
                <id>set-run-file-perms</id>
                <phase>generate-resources</phase>
                <goals>
                  <goal>exec</goal>
                </goals>
                <configuration>
                  <executable>chmod</executable>
                  <arguments>
                    <argument>0755</argument>
                    <argument>${project.build.directory}/foo.sh</argument>
                  </arguments>
                </configuration>
              </execution>
            </executions>
          </plugin>
        </plugins>
      </build>
    </profile>
  </profiles>

Dear god. 34 lines and a plug-in, just to change the permissions on a file in a platform-specific way??

I should add that the above was written by an extremely smart guy who is a top-notch programmer; no, I don’t think the author is at fault here. Even if there’s a more concise/portable way of achieving the same result in Maven (and there might well be – I admit I’m still a Maven newbie), there’s still the undeniable fact that XML is horrendously verbose, and any code written in it is by nature unnecessarily difficult to maintain. To this end I applaud the ongoing efforts supporting the use of YAML to implement the Maven POM.

It’s worth seeing what the above would look like if we wrote it in rake:

require 'pathname'

desc "Make binary executable"
task :chmod do
  File.new(Pathname.new(build_dir) + "foo.sh").chmod(0755)
end

I don’t think I need to make a case for which is more legible or maintainable. Oh, and the Ruby version is cross-platform.

To continue an anti-XML rant which has been made countless times already: what the ant and Maven people don’t seem to realise is that XML is not a real programming language and is therefore not expressive enough to deal with many cases that a build system needs. The clue’s in the name, guys! “M” is for “markup” not “Turing-complete“. That’s why every time you need to do something vaguely unusual for which there isn’t an ant taskdef or Maven plugin, you have to write hundreds of lines more Java/XML just to cope with that case. That’s why Maven needs so many damn plugins.

The accidental silver lining to this is that because it takes so much effort to accomplish simple tasks, Maven developers find themselves compelled to reuse and share plugins, and to be fair, Maven has some good ideas on how to do this, even if the implementation isn’t always the best. For example, the built-in plug-in repository management and plug-in dependency management seem to work nicely, but unfortunately for some reason it has a propensity to download plug-ins on most runs, far more frequently than any sensible caching layer should.

DSL issues aside, I’m not convinced by the fixed lifecycle philosophy behind Maven either. I wonder if it was borne out of frustration with the lack of proper dependency checking in ant.

That said, I do like how Maven encourages standardization of the build lifecycle and phase namespace thereof, since newcomers to a project immediately know some familiar entry points. But the same could be said of 99% of projects which use Make and use standard rule target names such as install and clean. And I suspect that many developers suffer when they try to shoe-horn their own project’s build requirements into Maven’s standard lifecycle.

My concern with this phased approach is that it is too linear.  The expectation is that a build process is a one-dimensional sequence of steps, and you get to choose your starting point but not much else.  This seems fundamentally wrong to me.  A build dependency tree is well understood to be a DAG, and any build system which doesn’t model this properly seems to me to be burying its head in the sand.  On the other hand, if it does model it properly, which includes implementing proper dependency resolution, the required build lifecycle should emerge naturally without having to dictate that generate-sources comes before compile which comes before test and so on.

I’ve had some ideas of what the ideal build system looks like, and how to get there from the conventional Java world. More on that soon.

Four hours trying to figure out why the hell my changes to .java source files weren’t showing up in the compiled binaries, debugging an unholy mess of ant XML files, before I finally realised how badly ant’s dependency checking sucks … Then 5 minutes of googling for ‘ant sucks’ and I find two excellently written rants which confirm my discovery (you might need to consult google’s cache for the latter).

I shouldn’t have been surprised.  Anything which uses XML as a domain-specific language should have already set the alarm bells ringing, but my excitement at learning something new initially blotted out the dull headache caused by hacking in XML.  Bah!

[Update: before you think about imitating the following approach, you should know that I gave up with Blogger and switched to WordPress which is far more flexible and easy to hack.]

Unfortunately it turns out that Blogger’s XML-based template layout system is not quite as flexible as it first seems. It’s almost superb, but has some key omissions:

• Flow control is limited to <b:if>, <b:else>, and <b:loop>. Crucially, you can’t break out of a loop.
• No writable variables of any kind.
• Conditional testing via <b:cond> is extremely limited. I kept expecting to find some comprehensive documentation for the xmlns:expr namespace (which is used via things like <a expr:href='data:blog.homepageUrl + "search/label/foo"'>), but it doesn’t exist, simply because all you can really do is simple comparisons using a limited set of data and hardcoded strings.
• There are no string-handling functions, and you can’t get access to the current QUERY_STRING to do any kind of parametrisation (for example, show some HTML saying which label you are currently viewing based on what comes after /search/label/ in the current URL).
• The box generated by the status-message includable is hardcoded to either be invisible or say “Showing label foo. Show all posts”. It cannot be customised.

I briefly considered ditching the idea of fiddling with this XML, and just using Javascript and CSS to hide the posts I wanted hidden, but persevered and came up with a solution with the following ingredients:

• I will label all posts with at least one of ‘geek’ or ‘main’, or possibly both. Posts labelled ‘main’ will appear on the default home page view. This is unfortunately necessary since there is no general way of excluding posts with a particular label, only including. The reason for this is that the only way to test for membership in a set of labels is by looping over all the post’s labels, and when you find the one you are including for, you output the post’s contents. If you were trying to exclude, you’d need a temporary variable to flag when you’d found the excluded label, then use that outside the loop.
• I used a standard template modification trick to limit visible posts on the home page to those labelled ‘main’.
• I wrapped my custom code in stuff like <b:if cond='data:blog.pageType != "item"'> so that it wouldn’t mess with single-post views.
• I figured out that http://blogs.adamspiers.org/search/label/ is a URL which will yield a view containing all posts, circumventing the <b:if cond='data:blog.url == data:blog.homepageUrl'> equality test in my default view (http://blogs.adamspiers.org/search/ also works)
• I reimplemented the status-message box from scratch, using Javascript:

  var labelsel = document.URL.match(/\/search\/label\/(.*)/);
  var view = 'unknown';
  if (document.URL == "<data:blog.homepageUrl/>") {
  view = 'default';
  } else if (labelsel) {
  switch (labelsel[1]) {
  case "": view = 'all';     break
  case "main":       view = 'default'; break
  case "geek":       view = 'geek';    break
  default:           view = 'label';
  }
  } else if (document.URL.match(/\/search.*updated-min/)) {
  view = 'time range';
  } else {
  view = 'unknown';
  }
  
  switch (view) {
  case 'all':
  document.write("Showing all posts.  <a href='/search/label/main'>Hide the geek stuff</a> or <a href='/search/label/geek'>hide the non-geek stuff</a>");
  break;
  case 'default':
  document.write("Not showing computer stuff.  You can see <a href='/search/label/geek'>the geek stuff</a>, <a href='/search/label/music'>music stuff</a>, or <a href='/search/label/'>all posts together</a>.");
  break;
  case 'geek':
  document.write("Only showing computer stuff.<br/><a href='/search/label/'>See all posts</a> or <a href='/search/label/main'>just the non-geek stuff</a>");
  break;
  case 'label':
  document.write("Only showing posts labelled <strong>" + labelsel[1] + "</strong>.<br/><a href='/'>Go to default view</a>");
  break;
  case 'time range':
  document.write("Showing posts within a time range.<br/><a href='/'>Go to default view</a>");
  break;
  case 'unknown':
  document.write("Unknown viewing mode, but don't panic.");
  break;
  default:
  document.write("BUG: Don't know how to handle viewing mode " + view);
  }
  

• I replaced the non-item part of the feedLinks includable with a hardcoded version.
• I altered the label-listing widget to exclude the ‘main’ label from being displayed.

If you want to look at my complete layout template, it’s here.