Comments for Petter Måhlén's Blog

Comment on Don’t use @Test(expected = …) by Petter Måhlén

Petter Måhlén — Thu, 09 Feb 2012 08:48:31 +0000

I like that syntax, it’s cleaner than the one you get with the JUnit ExpectedException, I think.

Comment on Don’t use @Test(expected = …) by Kristofer

Kristofer — Wed, 08 Feb 2012 19:33:05 +0000

Another option is using something like assertThrows in mockachino.

You get neat syntax like this:

Mockachino.assertThrows(IndexOutOfBoundsException.class).on(list).get(0);

instead of using try-catch.

It’s part of my mocking framework, but nothing in it actually uses mocks.

Here’s some example usage:
http://code.google.com/p/mockachino/source/browse/trunk/test/blackbox/se/mockachino/AssertTest.java

The feature itself is really simple, in case you want to duplicate it or extend it (optionally verify exception mesage for instance):
http://code.google.com/p/mockachino/source/browse/trunk/src/se/mockachino/assertion/AssertThrows.java?spec=svn128&r=128

Comment on Don’t use @Test(expected = …) by Petter Måhlén

Petter Måhlén — Tue, 07 Feb 2012 19:59:23 +0000

I was not aware of that – that looks like a more concise way of getting the same functionality that I do through the try/catch idiom. Great tip!

Comment on Don’t use @Test(expected = …) by Dominic Mitchell

Dominic Mitchell — Tue, 07 Feb 2012 14:04:00 +0000

Have you seen the ExpectedException class in newer junit versions? It’s a more refined version of @Test(expected=”").

https://github.com/KentBeck/junit/blob/master/src/main/java/org/junit/rules/ExpectedException.java

Comment on Code sharing: Use Maven by Petter Måhlén

Petter Måhlén — Mon, 23 Jan 2012 14:35:49 +0000

Hi,

We are in fact using the ‘remove if released’ feature. I haven’t spent any serious time trying to figure out whether it works or not, but my interpretation of the Nexus documentation is that it should work even if you separate release and snapshot repositories: “This tells the task to ignore the above settings if an artifact with the same group/artifact/version is detected in a release repository”. A quick glance in our Nexus repo seems to bear that out as well – snapshots relating to released versions appear to be deleted for the one project I checked.

Comment on Code sharing: Use Maven by Alexey Yudichev

Alexey Yudichev — Mon, 23 Jan 2012 14:00:33 +0000

Hi, I’ve noticed you use separate repositories for internal releases and snapshots. Doesn’t this prevent you from using “Remove Snapshots From Repository / remove if released” in Nexus as snapsot repository never knows about releases?

Branch merge conflicts is also an annoying thing for us. We use mvn release:update-versions after almost every merge before committing.

Comment on Code Sharing: Use Git by Git workflow for multiple teams | DIGG LINK

Git workflow for multiple teams | DIGG LINK — Tue, 27 Dec 2011 03:30:47 +0000

[...] this article presents a nice [...]

Comment on Git and Maven by Andy Schlaikjer

Andy Schlaikjer — Wed, 23 Feb 2011 05:55:20 +0000

(I guess you have to manually clean out local repositories to do that, and that could go wrong too)

See Sonatype OSS maven repo usage guidelines for example usage of staging repositories.

Comment on Bygg – Ideas for a Better Maven by Petter Måhlén

Petter Måhlén — Thu, 17 Feb 2011 09:57:03 +0000

Great points – I totally agree about the problems. I kind of don’t want to agree about the solution (make it hard/impossible to go outside the framework), but I’m not sure I have a better alternative. I used to work with games, and games are great examples of software, in that when you want to nudge users in a certain direction (say east), you need to make it fun to go east. If you make it boring/hard/painful to go west, north and south and hope that that will push people east, what happens is people go north, don’t like it and abandon the game. So ideally, rather than making it painful to pull jars in from ~/.myjars, it should be a pure pleasure to solve the problem (I guess some kind of conditional selection of a different configuration/classpath) within the framework. But how do you do that? Especially when you don’t know exactly what kind of things users might want to do programmatically?

I’m still thinking that the dangers allowing programmatic builds are less than the benefits of using an actual language to do build configurations. I could well be wrong. :)

Comment on Bygg – Ideas for a Better Maven by happygiraffe

happygiraffe — Thu, 17 Feb 2011 09:30:32 +0000

(Sorry for the late arrival to this post). I’m rather cautious about introducing a fully fledged language into the build system. It makes it so easy to generate a non-hermetic build, leading to great trouble down the road. e.g.

- Some builds conditionally pull in jars from ~/.myjars if they’re running on the developer’s workstation.
- It’s very difficult to reason about the build system without executing the code within. When that code is essentially arbitrary it could be doing anything, up to and including for(;;) {}. You get great tools for writing build files, but no support for tools to interact with them in a fashion other than building (e.g. automated dependency analysis).

Problems like these exist to some extent in other systems (make, ant). They’re the sort of thing that the communities spend a long time discussing, and deprecating via “Best Practices.”

One of the reasons I like Maven is how much you can’t do with it. :)