Two Guys Arguing

maven – give me my files!

Posted in Uncategorized by benjaminplee on 04.16.09

Every time I work with Maven I like a ton of things about it and get really annoyed by a few.  Today I was faced with an issue for the second time: I have a Maven project that produces a .jar as its artifact and I want to have a build goal produce a directory with that .jar AND copies of the .jar’s that it depends on.  Without this, my only means of distributing my code is if the recipient uses Maven also.  I partially solved this a few months ago and today found a more complete solution.  Its not complete (the .jars end up in a horribly ugly directory under the target folder) but it works … and that’s what matters.

The solutions uses the Maven Assembly plugin.  First, I needed a custom assembly configuration which I put in a file called assembly.xml in the root of my project:

<?xml version="1.0" encoding="UTF-8"?>

This file describes how the plugin should assembly my project; moving all of my dependencies, unpacked, into a single folder.  There is a huge assortment of options available ranging from include/exclude parameters to how/where to move files.  I am still slowly working my way through the reference doc.

Second, I modified my pom.xml to configure the Assembly plugin:


Finally, a call to mvn assembly:directory will compile your project, run the tests, package your project and produce the desired folder. Done.



Posted in bf by youngnh on 04.16.09

bf has a tendency to push the maximum limit of Things I Can Hold In My Head At One Time.

Keeping track of where a variable\’s value is located takes up the bulk of a bf programmer\’s mental bookkeeping. Heck, a quarter of the language\’s syntax ( < and >) is devoted to updating what the current pointer is looking at. bf doesn\’t have any syntactic notion of variables, but it is impossible for me not to assign a cell\’s location some \”reason\” for existing in my program. Variables, in my head, are usually named along the lines of that reason.

Another note, cells in bf hold only numbers, much like every computer; it is simply how you choose to interpret those numbers that makes reasoning about computation simpler or harder. For the most part, I\’ve interpreted bf numbers as one of only three distinct types:

integers, which need no conversion and are usually 8 bits in size and signed
characters, in which the number actually corresponds to an ASCII value
booleans, where the number 0 represents false and any other integer, true

Lets look at some code. A succinct bit of bf is doubling a number. In bf, it might look like this:

++++++  initialize cell 0 to 6
[       while cell 0 is not 0
>++     move to cell 1 and add 2
<-]     move back to cell 0 and decrement

Notice that since bf code only consists of 8 distinct characters, any others including whitespace are considered comments and thrown away, so you can mix plain text comments anywhere in a bf program that you\'d like.

Here cell 0 acts both as the value we are doubling and the index counter for the loop. We decrement it once each time through the loop until it is zero. The doubled result now resides in cell 1, NOT cell 0 where it began life. This is a universally common pattern in bf. Data is its own counter. Unlike the way that most programmers think about memory references — esp. array elements — data is always moving around in bf.

There are two ways to deal with this, accept that data moves around and update where your program will thenceforth look for that variable\'s value, or copy the doubled value back to its original cell. The second approach takes another seven characters of bf, minimum, to achieve, while the first approach takes no extra characters, but diligent and correct bookkeeping on the part of the programmer.

Or, if you are a programmer, then, inevitably, the program you\'ve created to do this for you.