If you haven't yet heard of gosling, here's the scoop: gosling is a pure Java build system based on Apache's Ant. Instead of writing your build script in XML, you write it in pure Java. gosling will compile your Gosling.java file on the fly and then execute it. Since it's based on Ant, it should feel quite a bit like Ant from the command line. Under the covers, Ant's tasks have been refactored and cleaned up a bit (I know "clean" is subjective and inflammatory but I mean no disrespect) to make working with the tasks a little more "Java" and to remove some of the XMLness of the code. The discussion on TSS ranged from "woohoo!" to "a waste of time." Some people like the idea of using Java others would rather use ruby or groovy. Others take issue with the name "gosling." Many people, rightly, question the use of 1.6. So I'll try to take these issues point by point and at least explain, if not mollfiy, most concerns.
The big question mark is the use of Java 1.6. This was more accidental than anything else. I've had many discussions with different people about bad XML is for scripting or programming. When I saw that 1.6 was allowing programmatic access to the compiler at runtime without accessing com.sun.*, I thought, "why not try it with Java?" So my first step was to write a program that compiled itself. That was pretty easy so I moved on to building a complete build system. As work progressed, it looked more and more feasible so I kept at it. gosling is by no means a replacement for Ant yet. There are many more tasks and types to implement as well as more advanced features like dependency management ala maven. But it's a start and it's getting there quickly.
"Why Java?!?" I know Java isn't the best for "scripting" (however you may define that term) but Java developers know it. I find it easier to sit down to new Java code than a new XML scripting "language." Java is also easier to analyze and refactor than XML. It's also considerably easier to make macros or subroutines to be used. They're just Java methods. In Ant, you'd have to break out antcall and param and hope you've got everything because no IDE will check that for you. Groovy and Ruby are great languages, but they're just one more thing to learn to use a technology and I'm aiming to reduce that.
"Gosling's a horrible name!" Well, it's certainly not the "coolest" I suppose. But it's the first reasonable name I came up with that didn't need a pronunciation guide or advanced linguistic skills. Coming up with great project names that are unique (enough) is actually quite difficult. For me at least. It might change in the future. It's already changed once (from a really stupid Java-themed name). It's decent enough despite the James Gosling bit. I'd be lying if that wasn't part of the attraction but the main appeal for me is the Ugly Duckling connection. Some of what's there really isn't as pretty as I'd like but it's getting there.
So what's in the works? Here's a smattering of the ideas I'm working on or have been suggested to me. Some of these are just "what if?" kind of ideas and might not see the light of day. If you see something you like, please make an entry in the tracker.
- Dependency management
- Project Profiles. The idea is that rather than your build class extending Project directly, you'd extend, say, MavenProject that would have some of the features that Maven has: standard project layout, standard targets and packaging and the like. Since it's just Java the number of different profiles is virtually limitless.
- Build file generation based on an existing source base
- build.xml conversion to a gosling build class
- Removing the 1.6 dependency. Leveraging Ant's compilation support, I can get at the compiler in a reasonably platform independent fashion. It turns out, that it's much more complicated than 1.6's compiler API but then I suppose that's the whole point of the API. It's definitely worth removing the 1.6 dependency but it's not as much fun for sure. :)
- IDE plugins. I plan on making one for IDEA and I've had one hopefully at least half-serious offer for an eclipse plugin.
- IDE project updates. Somewhat tied to the dependency management, but this would update the project classpath settings based on a classpath defined in your build file.
That's the basic rundown of "why?" and "what now?" Hopefully it will explain some of the decisions made so far and give some insight into what's down the road. Any suggestions would be most welcome in the tracker.