kafsemo.org

import static org.junit.Assert.assertEquals;

import org.junit.Test;
import org.junit.experimental.theories.DataPoints;
import org.junit.experimental.theories.Theories;
import org.junit.experimental.theories.Theory;
import org.junit.runner.RunWith;

@RunWith(Theories.class)
public class TestEncodeBits
{
    @DataPoints
    public static long[] randomNumbers = {
    	0, 1, 0x0123456789abcdefL, -1
    };
    
    private void assertSingleBitDifference(long a, long b)
    {
    	assertEquals(1, Long.bitCount(a ^ b));
    }
    
    @Test
    public void encodeZeroInZero()
    {
    	long result = EncodeBits.encode(0, 0);

    	assertSingleBitDifference(0, result);
    	
    	assertEquals(0, EncodeBits.decode(result));
    }

    @Theory
    public void encodeEverythingAgainst(long rndm)
    {
    	for(int i = 0; i < 64; i++) {
    		long result = EncodeBits.encode(rndm, i);
    		
    		assertSingleBitDifference(rndm, result);
    		
    		assertEquals(i, EncodeBits.decode(result));
    	}
    }
}

I’m constructively complaining about Maven

Monday, 18 January, 2010 (#)

If I’m saying anyone who’s used Maven should have a list of criticisms then I suppose I should put down a couple of mine.

Offline operation

It’s largely an exaggeration that you need to be online to run ‘mvn clean’, but there’s truth in it. Maven lazily fetches functionality from its central repository, so anything new fails without a connection. I’ve been bitten by this — I couldn’t run a test report until I got online again. I want a fully offline mode: a simple way to pre-load and know the core functionality will work. If I can install it through my OS’s package manager all the better. There’s nothing conceptually complicated here, just an archive with all the referenced jars, but it’s better than surprises when you’re on the go.

Top quality production releases

Two recent releases, 2.0.10 and 2.2.0 had bugs (MNG-4167 and MNG-4235 respectively) that made me wish I’d waited longer to deploy. 2.2.0’s bad checksums for uploaded artifacts was, ironically, only a problem with Ivy (which verifies on download).

Maven makes it so easy to keep dependencies current, and the Jira is invaluable for tracking bugs. For some projects, it’s acceptable to track development versions. For corporate deployment, a long-term supported version is a must, ideally with as few beta dependencies as possible. When it’s ready, a rock-solid guarantee that Maven 3.0 is ready to deploy would really help to build confidence, especially for anybody tempted in by a point-zero release.

POM modification

During the development lifecycle a POM will contain information that probably doesn’t need to leave the development department — source code repositories, publication servers and more. This gets rolled into the release as-is.

Some of the information can be moved out of the POM and into command-line arguments. There are also steps like this workaround for the clash between internal and external definitions of repository locations.

Whatever the solution, I’d like clean POM as part of the release.

I’ve also needed to modify POMs more heavily during a build, which involved more scripting around Maven than I liked. Which leads to...

Simpler configuration format

They know, they’re fixing it. Here’s an example of a manual conversion.

This isn’t just for manual editing — to generate and manipulate POMs a simpler format, or a stable API and object model, would be great.

---

If you’re not scared off, here’s a good case study (via Sonatype) of how Maven’s simple model helps to ensure everyone, from new starters to old hands, can build, test and develop with a codebase. There’s real value in a clean onboarding process, which is very much part of the Maven pitch.

I’m enjoying Maven

Tuesday, 5 May, 2009 (#)

Like most Java developers, I have an opinion about Apache Maven. So far, I really like it. I wouldn’t try to build modular software without it and, even with its faults, I hope something very like it becomes a de facto standard.

Maven invites you to define your project as a named, versioned component that depends on other components. Maven assumes that your project follows a set of conventions for layout and, in return, you get the essential tasks: transitive dependencies are brought in and the compile time, test and runtime components are kept distinct. It will generate a unit test report, with test coverage, along with Javadoc and a packaged jar. There’s no rocket science in there, but copy-and-pasted Ant scripting goes away.

Other tasks use the dependencies; building up a distribution with all the other jars is simple. Update to more recent versions, run it again. Metadata can be used to track license consistency for a large project.

For me, the motivating feature is componentisation. It becomes very easy to split a large project into modules, and to make sure the dependencies are correct and consistent. It’s easy to build the whole thing from source or to take a module and build it against snapshots of a larger more stable framework. I feel a lot more comfortable with a clean, repeatable from-source build, and Maven really helps with that.

Of course, if you’ve used Maven you’ll have a few criticisms. If you’ve used it even semi-seriously, that’ll be a long list. Jason van Zyl mentions the path-paving model of development, which seems very appropriate in this case. I feel confident that the problems I see are fixable without a fundamental change of model. But yes, if you’re evangelising, don’t waste time claiming it’s perfect. Almost all the criticism you’ll hear is legitimate but not a deal-breaker. People are very attached to putting their source in a particular directory, just like some people still steer clear of Python for its white space.

Maven creates a fairly large infrastructure burden if it’s embraced fully for larger commercial deployments. Sonatype’s business model seems to be based around increasing demand for that infrastructure and then selling a solution for it. I like that, pace the usual suspicion about conflicts of interest between the free and commercial products from a company (their position is well stated). There’s some healthy debate over the relative merits of the repository implementations. All I can say is; Nexus worked well enough for me that I didn’t go looking for an alternative. Well done on the OOBE.

Maven, Ivy, OSGi and Project Jigsaw all touch on similar territory, and there are many projects to blend one with another. An open-minded approach to see what works and share the best ideas can only lead to a better product.