I have to apologize for going so long without saying much on the subject. We're in that mad rush to the finish line trying to finish up a release while the business types are busily moving that finish line farther and farther back. But enough with the sob stories, eh? Most of my online friends already know this but I've decided to drop development on gosling. I have entirely too many irons in the fire and something has to give and this, unfortunately, one of a number of victims of this downsizing. For anyone interested in taking up this project, I'll happily transfer ownership.

It's been way too long since I've blogged but I do have an update that might be of interest. I finally carved out enough time to get support built in to gosling for using dependency resolution using maven repositories. At the moment that is accessed through the Dependencies class. The call is a pretty simple call to make but it does require that you pass in a Dependency object and a FileSet to add the dependency path to. I'm going to add convenience methods on Project to access all this so that you needn't worry about the plumbing. It's still largely experimental but the unit test passes and that's a good sign. My ultimate hope is that this mechanism can be used to add plugins to your build without having to download them manually. Adding things to $ANT_HOME/lib has always irked me and just seems a little clunky. Maven manages this pretty well as far as I can tell so it shouldn't be too bad.
So what's next for gosling? I want to finish building out the most common tasks for building systems. For example, I use uptodate quite a bit in various ant settings. I also need to work on support for publishing artifacts via gosling to maven repositories. I would also like to clean up APIs a little.Â There's still more XML-oriented cruft in there than I'd like.Â I'm getting close enough to usability that I might just stamp it 1.0 once things like this are rounded out. Once 1.0 is done the biggest item on my plate is what I'm calling at the moment "profiles."

This isn't anything terribly exotic but the one profile that seems to be most asked about would be a maven-like profile where project structure is defaulted and enforced along with a build lifecycle that users of this profile would just hook into. This could also mean more focused profiles such as web application oriented profiles or ones more geared to full JEE development.Â Since it's just Java, this will largely be done through inheritance and likely will use event notifications. I still have to work through that particular design.
So that's what's on tap for gosling. I just pushed version 0.3 out to https://gosling.dev.java.net.Â If you haven't tried gosling out yet, please do give it a try and provide some feedback on the lists.

In one of the most heart wrenching svn commits I've ever made, I removed the 1.6 dependency from gosling. ;) As I outline here, most of this started out as an excuse to play with 1.6. But that dependency, will limit gosling's adoption for the next few years so I decided to remove it. I'm not doing any 1.6 based projects either so the likelihood of using my own tool was pretty limited.
And that's a shame, because that API makes it very, very clean. The ant approach is not very clean or fun to read through but that's what I'm using at the moment. Once the open sourcing of 1.6 is done, I'll look into backporting that API if the licensing permits that. It's just too convenient.

So now that that's out of the way, I can focus on things like building a formal binary distribution and rounding out the available task list. I'll start entering tickets into the tracker for those curious enough to follow along. I'd really like to get to the dependency resolution but I think some of these basic tasks should take precedence.

If you've held off from trying gosling because of the 1.6 requirement, now you don't have to. I'd love to hear what you think.