that’s great…

Programmer Personality Test

I took Doolwind’s Programmer Personality Test, and got a DHSB. It was explained it as follows:

You’re a Doer.
You are very quick at getting tasks done. You believe the outcome is the most important part of a task and the faster you can reach that outcome the better. After all, time is money.

You like coding at a High level.
The world is made up of objects and components, you should create your programs in the same way.

You work best in a Solo situation.
The best way to program is by yourself. There’s no communication problems, you know every part of the code allowing you to write the best programs possible.

You are a liBeral programmer.
Programming is a complex task and you should use white space and comments as freely as possible to help simplify the task. We’re not writing on paper anymore so we can take up as much room as we need.

This may be true, I don’t know. I will assume it means I am awesome. He also had a link to a Jung personality test, and I was an INTJ; again, awesome. If you want to see a general description of your type, look here. If ya get a chance, take the tests and post your results.

Getting the right manifest classpath

If you use Apache’s Ant to create archives (jars or wars), you most likely include a manifest(.mf). Well in the past when I’ve needed to note the dependencies on other jars, I’ve would have to come up with some rubbish hack. Things would look something like this:

        <jar destfile="${build.dir}/${core.jar}" basedir="${tmp.build.dir}" index="true">
            <manifest>
                <attribute name="Built-By" value="${authors}"/>
                <attribute name="Implementation-Title" value="core"/>
                <attribute name="Implementation-Version" value="${version} at ${TODAY}"/>
                <attribute name="Implementation-Vendor" value="${company}"/>
                <attribute name="Class-Path" value="foo.jar yep.jar test.jar etc…"/>
            </manifest>
        </jar>

Thanks to Ant 1.7.0, things are a bit different. With the addition of the manifestclasspath task, manifest classpath generation is a bit easier.

       <manifestclasspath property="manifest.classpath" jarfile="${jars.build.dir}/hack.jar">
            <classpath>
                <fileset dir="${jars.build.dir}">
                    <exclude name="junit-4.1.jar"/>
                </fileset>
            </classpath>
        </manifestclasspath>

        <jar destfile="${build.dir}/${core.jar}" basedir="${tmp.build.dir}" index="true">
            <manifest>
                <attribute name="Built-By" value="${authors}"/>
                <attribute name="Implementation-Title" value="core"/>
                <attribute name="Implementation-Version" value="${version} at ${TODAY}"/>
                <attribute name="Implementation-Vendor" value="${company}"/>
                <attribute name="Class-Path" value="${manifest.classpath}"/>
            </manifest>
        </jar>

Note the jarfile attribute is set to ${jars.build.dir}/hack.jar. hack.jar never comes into existence. The reason being is manifestclasspath attempts to create the classpath relative to the items in their actual location. Since this is during a build process, the location is temporal, and the incorrect parent dir is prepended. By convincing the manifestclasspath task that the jars are all in the same dir as the proposed, the jars are added without the unnecessary parent dir. For some seem trivial, but remember, it’s the small things.