My big fat greek subversion repository

Literally hundreds of modules looks like this:

On a daily basis, I touch a dozen different modules. It’s just easier to checkout the root of the project instead of each project separately. However, I get all of the “branches” and “tags” directories too. And there are hundreds of versions for many of these modules. And the list of modules, and their tags, is always growing. My “svn update” was beginning to take way too long.

Here is what I do:

find . -name branches -exec svn update --set-depth empty {} \;
find . -name tags -exec svn update --set-depth empty {} \;

I get at least 100 seconds back each week!

Oh, and if you happen to have a real directory called “tags” in your code that you would like to keep seeing updates on do this:

svn update --set-depth infinity mydirectory\WEB-INF\tags

Maven Dependency Management using exclusion vs. provided

I’m currently working on a project and noticed that there are a lot of libraries marked with a scope of provided like so:

<dependency>
<groupId>somegroup</groupId>
<artifactId>someartifact</artifactId>
<version>0.1</version>
<scope>provided</scope>
</dependency>

But, when I look at the target container, I see no such library.

Upon further investigation, I realize that this scope was being used to exclude the library from the deployed artifact.  It might have been a loose dependency on another library.  Instead of using and exclusions list, to tell *me* that they just didn’t want it in the artifact, they used the provided scope to tell me that it’s already in the container.

Dear developers using maven, please choose to exclude unwanted dependencies rather than giving them a “provided” scope and sending those that follow you down this same rabbit hole.

I would prefer to see this:

<dependency>
<groupId>somegroup<groupId>
<artifactId>someartifact.thatdependson.someartifact</artifactId>
<exclusions>
<exclusion>
<groupId>somegroup</groupId>
<artifactId>someartifact</artifactId>
</exclusion>
</exclusions>
</dependency>

Thanks!

VirtualBox Scare – VERR_SUPLIB_WORLD_WRITABLE

I’ve been really enjoying VirtualBox for a few months now.  Today, when I tried to open my images, I got a really scary error.  I thought that all of my work was gone.  I tried to open the other images I had, all of them failed with the same error.

VERR_SUPLIB_WORLD_WRITABLE

I’m using OSX, I did a fair bit of googling, the solution that worked for me:

chmod o-w /Applications