Friday, February 25, 2011

getting svn and git svn to work long paths on windows

It appears that no latest stable SVN client (1.6.15 latest today) work well when working with projects with long paths (i.e. > ~ 250 characters). Noone on the team had problems as they used TortoiseSVN, but I insist on checkout out from the command line, and I also want to use git svn.

Now there's a work-around, but it seems relatively unknown. Yes you read well: use absolute paths instead of relative paths. That's it. Basically do:

$ svn co http://server/project/trunk c:\Projects\project.git

For git svn, from the git batch command line:

$ git svn clone [options] http://server/project/trunk /c/Projects/project.git

It also appears that svn client 1.7, out Q1 2011, will also fix that. But I couldn't confirm it from the roadmap.

Saturday, February 12, 2011

Ignoring JUnit tests at runtime

Sometimes I want to ignore particular test failures. In fact I don't want the tests to run at all because I know they will fail. Not that they are broken, but because they depend on part of the infrastructure that isn't available right now.

E.g. in the web-validators project, I wanted to have the ability to ignore the integration tests (which test remote validation services integration) when the remote sites aren't reachable.

I could also have used Assume, but somewhat I am not completely satisfied with that solution. The Assume calls go in the test code and

  • can't be used at a class level

  • aren't as good from a self-documenting perspective

  • don't have access to method information, e.g. other annotations

  • will execute my test code anyway, which can cause slow-downs, etc (time outs generally take a bit of time to trigger)

I could also have grouped my network dependent tests in a special suite or using a Category, but then I have to enable or disable it myself (i.e. make suites that match my grouping).

I prefer tests that enable themselves automatically.

So I came up with this solution: I have created a new Runner, and a new version of the Ignore annotation called RuntimeIgnore to which I specify optional extra argument(s): the name of a class to instantiate and execute to check whether an ignore condition is satisfied.

The disadvantage of the current patch is that I still have to have my own Runner. I don't like that too much (because to combine multiple enhancements you might have to combine runners) so I submitted an enhancement to JUnit as I merged that approach into the existing JUnit 4 Runner and @Ignore annotation.
Note: the patch isn't fully complete (cleanups, documentation left aside), it's more like a RFC. Feel free to comment.

How could you use this ? Instead of doing something like:

@Test thisTestShouldOnlyRunOnLinux() {
// my test code

and then enable your group of tests using Suites.


@Test thisTestShouldOnlyRunOnLinux() {
if (notOnLinux()) {
// my test code

You can do:

@Test thisTestShouldOnlyRunOnLinux() {
// my test code

The same apply to classes, e.g.

class MyLinuxTests {
@Test ...
@Test ...

You can also take advantage of DRY principles on Convention over Configuration doing

@Test onLinux_aTest() {
// my test code for Linux

@Test onWindows_aTest() {
// my test code for Windows

( in case you haven't followed the above code will not run in code taken from the JUnit official repository ! )

Update 1: after a comment from a JUnit commiter on my pull request/RFC, I made a slightly different version of the patch that doesn't require any change made to JUnit. By using MethodRules intead of a custom Runner, I am achieving almost the same thing. See the change here.

Saturday, February 5, 2011

Sonatype's Hudson's bright future - answer

So Sonatype's Jason Van Zyl posted about Hudson's future. I wonder if that response is related to Hudson-Dev's email thread "The Future of Hudson".

While I agree with some of the things Oracle and Sonatype are doing, I strongly disagree with the wording of this post and some of the comments.

  • "mostly dependent on a single individual for core changes" (aka hudson dependance on KK). There are 115 different contributors in core according to git (for jenkins, but that shouldn't be a big difference in hudson). yes he made the main decisions at start, but there are now more than 350 hosted plugins. From that perspective, his decisions sounded right

  • criticizing jelly ? I agree that it's not the best choice for a project starting today. But it's not that bad. And have you looked at how much code jelly represents in the plugins ? If I look at the official plugins from middle July 2010: 420k lines java, 44k jelly. That's 10%, a huge problem, right? And it's not because jelly didn't make sense for maven that it didn't for hudson. Actually it makes much more sense in hudson than in maven.

  • lack of documentation: most projects lack it. Even Maven

  • "too many forked dependencies". Think of them as patched dependencies, not forks. Who hasn't done that in the enterprise world? You know how hard it is to get a commit upstream sometimes. And it's easy to know why they were forked. Check the release logs for the deps. Or ask !

  • provenance: commits come with issue number and/or link to online discussion / report in the mailing list. Code comes from commits. Do you mean it could have been copied from another project without appropriate copyright ? This can happen anywhere. And it's solved the same way everywhere: by rewriting the code. Nothing dramatic.

  • licensing issues: yes you're right. BTW, mentionning Saas really sounds like attacking Cloudbees...

  • automation tests. Yeah ! All for it. There are 800+ tests right now in test harness. It's not that bad then. And you know how hard it is to come up with a good coverage right ? Maven 2.0.x took a long time to stabilize... As for providing tests for all plugins, it's hard. In maven it's easier because most are not hosted by Apache itself (think codehaus, etc)

  • "maven 3.0 support" in your worklog sounds like hudson/jenkins doesn't support it. How does that run then ? You might want improving it, or providing an alternative. Fine. But don't do as there's no support for maven 3.0 today in hudson/jenkins.

I could go on but I don't want to be too picky.

To summarize. Technical debt ? Oh yeah. Old dependencies? Double that. What kind of old projects doesn't have that ? How many times did you rewrite maven already ? You know it's hard to get it right the first time.

The reason I wanted to answer Sonatype's post was that line.

"Working with the community, Oracle and Sonatype [...]"

I think (and I may be wrong) that you've been working with a subset of the community. You didn't seem to publish your RFEs on the wiki on in Jira when the hudson developers asked (did you?).

You probably worked with Oracle and some of its customers, perhaps getting paid for your company's work. Nothing wrong about that in itself. Even great!

But please don't say 'the community'...

Anyway, the wording aside, I can't wait to see your contributions. I am sure they will help to make Hudson (and indirectly Jenkins) a better product.

Wednesday, February 2, 2011

The Future of Hudson

Unsubscribe @ hudson

Looks like quite a few people think that unssubcribing the developper mailing list is the way to put "the saga behind".

Hudson vs CruiseControl, presentation from 2008

(Note: Because it's historical, I will still keep the hudson name in that post, but that content of course also applies to Jenkins.)

Looks like Google Docs doesn't allow viewing my Open Office presentations. I digged that old Hudson vs CC presentation I made in 2008. You may find some interesting notes in particular:

  • Slide 13: some stats on hudson source

  • Slide 14: some stats on hudson releases where I plotted releases from 1.04 to 1.210 (pretty impressive rate at the time !)

  • Slides 15&16: Hudson success factors

  • Slides 17: Benefits

  • Slides 18: 4 things to do:

    1. Try it

    2. Like it

    3. Use it

    4. Contribute