Showing posts with label OS X. Show all posts
Showing posts with label OS X. Show all posts

Wednesday, June 19, 2013

Maven / Ant Alerts in OS X

The Case of the Forgotten Builds (Mac Edition)

You can see my previous post on Maven / Ant Alerts in Ubuntu for the Linux version

There are a few projects I work with that have long builds. I have a bad habit of alt-tabbing away from the build and promptly forgetting that I even started it only to come back 15 minutes later and not remembering if/when/why I built the project. What I need is a way for these tools to get my attention when they are done.

growlnotify To the Rescue!

Growl, a popular notifications app for OS X has a nice command line utility called growlnotify. Download an install it from that link and then with a short bash function and a few aliases we can have nice notifications for any command line we want!

The OS X Terminal as of 10.7 also responds to the "bel" escape character if it is in the background. For each bel that occurs while the Terminal is in the background a numeric badge appears and the counter it shows increments. The Terminal app icon also bounces a few times.

The combination of Growl and the Terminal bel provide a nice notification system that your command is done.

1. Install Growl and growlnotify

2. Edit ~/.bash_aliases:

cmdstatus()
{
    CMD=$1
    shift
 
    $CMD $@
    RETCODE=$?
    BUILD_DIR=${PWD##*/}
    BUILD_CMD=`basename $CMD`
    if [ $RETCODE -eq 0 ]
    then
        printf '\a'
        growlnotify -s -d $BUILD_CMD -n $BUILD_CMD -m "$BUILD_DIR: $BUILD_CMD successful
$(date)"
    else
        printf '\a\a'
        growlnotify -s -d $BUILD_CMD -n $BUILD_CMD -m "$BUILD_DIR: $BUILD_CMD failed
$(date)"
    fi
    return $RETCODE
}
alias ant="cmdstatus ant"
alias mvn="cmdstatus mvn"

3. Restart Your Terminal

Now you get nice success/failure messages out of your ant and mvn commands. The original commands return code is correctly preserved and this cmdstatus wrapper can be easily added to any other command you want via a simple alias line.





Saturday, June 7, 2008

Apple's JDK6 Broke My Scripting!

uPortal 3 uses the new (JDK5+) Java scripting APIs via Cernunnos, the scripting language used in the data import/export scripts. This has been working great and is a huge step forward for the uPortal project. I've been building uPortal 3 on my Apple computer since development started and it has been working great.


Until I installed the Apple JDK6 Update.


Now I've been itching for JDK6 on my Mac for a while. I have little interest in the OS integration Apple does with the JDKs since I don't use it to develop code for OS X. I develop server-side web applications, all I need is the base JDK. So finally, around a year after Sun released JDK6, Apple gets their version out. I eagerly install the update, Eclipse still works, Tomcat starts and uP3 runs, we're all happy.

A few days later I grab the latest updates from the uPortal trunk and go to re-build and re-initialize the portal's database. It fails importing the data .... didn't this just work at the office? Didn't this just work here a few days ago?

Wondering if this is a new issue or not I grab the 3.0.0 release package and run initportal, it fails there too! All my attempts to run any of the Cernunnos scripts fail with the following stack trace:



So the next question is what the heck does uP3 depend on that is compiled to the JDK6 .class file format? Of course the UnsupportedClassVersionError is useless since it doesn't tell you what class file is bad or where it is loading it from!

The next step is adding the -verbose:class option to the Ant script that runs the Cernunnos scripts. This makes the JVM print out each class and the file it is loaded from, thats a lot of text but the only way to track this down. Re-running the script with the verbose option yields the culprit:

apple.applescript.AppleScriptEngineFactory

What the heck? Apple includes a scripting library for JDK6 only in the classpath for JDK5? They do this by default after installing their JDK6 update? This is not cool. The class is in the /System/Library/Java/Extensions/AppleScriptEngine.jar file which is added in the system's JDK extensions folder, apparently ALL Apple JDKs load ALL the jars from this directory. That makes it a bad place for a .jar that isn't compatible with all the JDKs on the system.

The solution I ended up coming up with is to move the AppleScriptEngine.jar into the JDK6 extensions directory:



This move fixed the problem and all is happy (mostly) in the land of Java on the Mac.