Category: Development (Page 15 of 18)

Developing systems takes a very different outlook than it does from developing libraries, and again very different from designing languages. Even though on projects when we have specific coding standards, there’s always often a benefit to supporting much more. I appreciate language designers needing to think at a much broader scale about the realm of possibilities than I normally need to for systems I develop.

My example of this appreciation is when I had to debug some java code via a remote terminal on a box where the unwanted behaviour emerged. I was actually thankful for being able to do an import java.util.* rather than having to specify every single class that I wanted to use.

When using the jar-with-dependencies descriptorRef for the maven-assembly-plugin, it creates two files by default, the normal default jar with any library dependencies excluded, and a second jar with all the libraries included appended with “jar-with-dependencies”. Since I find maven help guides unintuitive, it took a while before we found the appendAssemblyId option to turn it off. Here’s the snippet of the pom.xml to create just a single far jar.

<plugin>
  <artifactId>maven-assembly-plugin</artifactId>
  <configuration>
    <appendAssemblyId>false</appendAssemblyId>
    <descriptorRefs>
      <descriptorRef>jar-with-dependencies</descriptorRef>
    </descriptorRefs>
  </configuration>
  <executions>
    <execution>
      <id>make-assembly</id>
      <phase>package</phase>
      <goals>
        <goal>assembly</goal>
      </goals>
    </execution>
  </executions>
</plugin>

We’re using this Maven plugin to generate a fat jar for a utility, effectively including all library dependencies un-jarred and re-jarred into a single distribution. The first part was easy, hooking the assembly goal of the maven-assembly-plugin onto the package goal in the maven build lifecycle. Our pom.xml had this entry in it

<plugin>
  <artifactId>maven-assembly-plugin</artifactId>
  <configuration>
    <descriptorRefs>
      <descriptorRef>jar-with-dependencies</descriptorRef>
    </descriptorRefs>
    <archive>
      <manifest>
        <mainClass>com.thekua.maven.ExampleProgram</mainClass>
      </manifest>
    </archive>
  </configuration>
  <executions>
    <execution>
      <phase>package</phase>
      <goals><goal>assembly</goal></goals>
    </execution>
  </executions>
</plugin>

We tried adding in our own entry into the manifest, the CruisePipelineLabel, with a value that should be set by Cruise. We added the new section so our pom.xml now looked like this:

<plugin>
  <artifactId>maven-assembly-plugin</artifactId>
  <configuration>
    <descriptorRefs>
      <descriptorRef>jar-with-dependencies</descriptorRef>
    </descriptorRefs>
    <archive>
      <manifest><mainClass>com.thekua.maven.ExampleProgram</mainClass></manifest>
        <manifestEntries>
          <CruisePipelineLabel>
            ${env.CRUISE_PIPELINE_LABEL}
          </CruisePipelineLabel>
        </manifestEntries>
    </archive>
  </configuration>
  <executions>
    <execution>
      <phase>package</phase>
      <goals><goal>assembly</goal></goals>
    </execution>
  </executions>
</plugin>

After running the target and inspecting the manifest.mf, I couldn’t see the additional property set. I did some searching, found a bug apparently fixed in the 2.2-beta-2 version. After some debugging, I found out that the plugin apparently does not include these additional entries if the value is not set. I tested this out by changing the line to:

<manifestEntries>
  <CruisePipelineLabel>aTestValue</CruisePipelineLabel>
</manifestEntries>

So the answer to whether or not maven-assembly-plugin ignores an element in the manifestEntries is to ensure the value is set before testing it. It looks like a null value is interpreted as “don’t include”.

Our current development team is split, some working on windows machines, others on macs, with continuous integration tests running against both windows and linux environments. We’ve had a need to run operating specific JUnit4 tests and I got a little tired putting guard clauses into different @Before, @After and @Test methods to prevent a particular block of code running.

Using the new org.junit.runner.Runner annotation, and SystemUtils from commons-lang, here is the result:

package com.thekua.java.junit4.examples;

import org.apache.commons.lang.SystemUtils;
import org.junit.internal.runners.InitializationError;
import org.junit.internal.runners.JUnit4ClassRunner;
import org.junit.runner.notification.RunNotifier;

public class RunOnlyOnWindows extends JUnit4ClassRunner {

    public RunOnlyOnWindows(Class klass) throws InitializationError {
        super(klass);
    }

    @Override
    public void run(RunNotifier notifier) {
        if (SystemUtils.IS_OS_WINDOWS) {
            super.run(notifier);            
        }
    }
}

Our test classes, then look like this:

...
@RunWith(value=RunOnlyOnWindows.class)
public class WindowsOnlySpecificFooBarUnitTest {
    ...
}

Of course, you can use any other particular variations like SystemUtils.IS_OS_UNIX, or SystemUtils.IS_OS_MAC but we haven’t needed to yet.

Of course, this is easily turned into some sort of conditional runner abstract class but at least you get the basic idea.

File.setReadonly(true) doesn’t actually work on windows (at least on the JDK that we’re working on). According to the bug report filed here, it is just setting the DOS flag that prevents it from being deleted just not being written to.

Meanwhile, assuming you have mounted a read only disk partition in windows to, say X:, new File(“X:/”).canWrite() returns true when it really should be returning false. I’m still trying to find the bug reported to sun for this, or will later update this entry to include it. It seems to persist when running against both jdk1.5.0_15 and jdk1.6.0_07.

This is probably something that old timers in Java will probably know, so I’m posting this more for my reference. Trying to execute:

Runtime.getRuntime().exec("dir");

results in the following stack trace.

java.io.IOException: CreateProcess: dir error=2
  at java.lang.ProcessImpl.create(Native Method)
  at java.lang.ProcessImpl.(ProcessImpl.java:81)
  at java.lang.ProcessImpl.start(ProcessImpl.java:30)
  at java.lang.ProcessBuilder.start(ProcessBuilder.java:451)
  at java.lang.Runtime.exec(Runtime.java:591)
  at java.lang.Runtime.exec(Runtime.java:429)
  at java.lang.Runtime.exec(Runtime.java:326)

After doing some reading

error=2

apparently means file not found. The fix for something like this is to first pass everything to the windows command line shell (cmd.exe on windows xp). This seems to do the job better:

Runtime.getRuntime().exec("cmd /c dir");

The slash-C means “Carries out the command specified by string and then terminates”.