Linux config files available on github

I pushed several of my common linux config files that I often find myself sharing with others via email to github. I'd say it's currently specific to Java developers that are using maven2. I lean heavily on alias's defined in my .bashrc file which lives under my home directory. Hopefully others will fork this project and I can merge forked changes back into my project.

Not only did I want to provide an easy way to share among co-workers, but I also wanted to be able to port to other machines or even when I need to rebuild my work laptop. Also, I just want to get more comfortable with a DVCS workflow. Thanks to Ron Alleva's post (Using Git and Subversion in 5 Easy Steps) about getting setup with using git as the client to svn, I am all set at work to start using git.

Please check it out at https://github.com/jlorenzen/linux-config-files/tree

git clone git://github.com/jlorenzen/linux-config-files.git

Currently it includes:

1. .bashrc - Contains my alias's
2. .synergy.config - Config file I stole from Joe Kueser which lets me control a windows machine with the keyboard and mouse connected to my linux laptop (see synergy).
3. .vimrc - Simple vim settings. Nothing special yet
4. idea.sh - Simple IntelliJ Idea startup script for linux
5. idea.vmoptions - Modified vmoptions for IntelliJ Idea
6. start-hudson.sh - Example of a generic linux startup script
7. stop-hudson.sh - Example of a generic linux stop script

For those looking to create a github account (and for my future reference) I struggled on how to sync up my local master with the master on github. Thankfully history was around to remind me.

git push origin master

This was after I did the one step (I think) to add the origin:

git remote add origin git@github.com:jlorenzen/linux-config-files.git

Minor issue with Ubuntu Desktop

Linux and Ubuntu are awesome. I switched from developing on Windows XP to Ubuntu Desktop in late 2007 (7.04 or Feisty Fawn). I will never again develop on an windows machine. Hopefully I won't ever work for a company that requires a windows platform, but at that point I would rather buy my own work computer or setup Ubuntu in a virtual instance. I really appreciate Rob Madole and Brian O'Neill for showing my the right path. I remember Brian's frustration anytime he was forced to pair with me on my windows machine. Now I am like that with my co-workers.

Even though Ubuntu is great, I still have one minor compliant. Well it's really 3 things combined: Extended Monitor support, Compiz, and Gnome-Do. I am addicted to all 3, but trying to get all 3 to work together seems impossible.

Extended Monitor Support
The big problem here is going back and forth between work and home. At work I want to use my monitor, but at home I use just the laptop monitor. In the past I ran nvidia-settings when I wanted go back and forth. This has been improved with some help from Ron Alleva by using the xrandr command. He gave me some alias's to run when I wanted to switch. When I first installed 8.10, I used those alias's, but it seems lately its being auto-detected because when I plug my monitor in at work, ubuntu recognizes it and I don't have to run anything. Nor do I have to run anything now when I get home. So it would seem I have a good handle on this now, but when using an extended monitor other things don't work.

Compiz
I love compiz mainly for one thing: transparency in my terminal. I'm sure I have set a million other settings before, but enabling the Normal Visual Effects under the System > Preferences > Appearance setting is usually one of the first things I do. I believe this setting uses Compiz. With this setting enabled, my terminal window is transparent enough that I can see other applications in the background, like firefox or pidgin which I typically have behind terminal without having to switch back and forth. Unfortunately, it seems I can't have this setting enabled when I have an extended monitor.

Gnome-Do
Man I love it. I am hoping to eventually get to a point to where I have an entirely clean desktop like this. My favourite is the docky option seen here which is similar to Mac's Spotlight. Gnome-Do works just fine with an extended monitor, but docky requires compiz to be running in Normal mode and if you recall compiz doesn't work for me when using an extra monitor.

This is probably a pretty minor compliant verses all the ones I had against Windows, so I don't expect any new patches coming out of Canonical. In an ideal world, my extra monitor would just be automatically detected, compiz would work, and therefore gnome-do docky would work.

Maven Global Excludes

To my knowledge, maven2 currently does not have the ability to globally exclude dependencies. Instead there is the tedius way of excluding a transitive dependency inline with the direct dependency (see Conflict Resolution) For complex multi-module projects, this can be difficult to manage and having the ability to exclude a dependency globally could be very useful. Seems like others share the same feelings (MNG-3196). Unfortunately, for maven2 users this is targeted for maven3. So until then, here is a tip on how to globally exclude dependencies in your project (provided by my co-worker Ron Alleva).

To globally exclude a dependency all you need to do is set the dependencies scope value to provided. This supports excluding transitive dependencies, which is really what you want.

So for example, let's assume I have a WAR project that depends on commons-logging-1.1, which according to "mvn dependency:tree" has a transitive dependency on avalon-framework-4.1.3.

[INFO] +- commons-logging:commons-logging:jar:1.1:compile
[INFO] |  +- logkit:logkit:jar:1.0.1:compile
[INFO] |  \- avalon-framework:avalon-framework:jar:4.1.3:compile

Assuming I want to exclude avalon-framework from my WAR, I would add the following to my projects POM with a scope of provided. This works across all transitive dependencies and allows you to specify it once.

<dependencies>
  <dependency>
      <artifactId>avalon-framework</artifactId>
      <groupId>avalon-framework</groupId>
      <version>4.1.3</version>
      <scope>provided</scope>
  </dependency>
</dependencies>

This even works when specifying it in the parent POM, which would prevent projects from having to declare this in all child POMs.