Technically, for development I suggest using Spring Roo http://www.springsource.org/roo which is basically an intelligent shell that let's you quickly configure spring projects.
- Less manual configuration required, the roo shell is doing a lot of the heavy lifting automatically in behind
- Roo adds no runtime dependencies, the result is still a pure Spring app
- Roo comes with a plugin / add-on functionality, which is based on OSGI bundles
- Roo is completely integrated into Spring toolsuite (a customized version of Eclipse http://www.springsource.com/developer/sts with specific spring support)
Spring toolsuite? Edit
I cannot find out how to add this to my existing Eclipse setup. Do I have to have two different versions of Eclipse sitting around?
Most of us have Eclipse 3.6, and not everything installs. There's a thread at the SpringSource forum that addresses the problem. It took a few tries, but I think I got the necessary parts installed. I had to track down the AspectJ package first; it's not in the standard search path, so you have to go to the Eclipse AspectJ page and follow those instructions first. I think the big things are are missing are the mylyn tools and the error analysis tools, but I don't see any real need for those.
Grampajohn 23:24, November 10, 2010 (UTC)
OSGi bundles? Edit
I've read up a bit on OSGi bundles, and so far it seems to me that they solve a number of problems we don't have. Could someone please make a cogent argument that explains why we should adopt OSGi bundles rather than simple jar files? My major concern is the "separate classloader" feature, which is going to cause all sorts of unnecessary confusion and overhead.
Grampajohn 22:49, November 10, 2010 (UTC)
Please see discussion thread about it on the developer page at http://power-tac-developers.975333.n3.nabble.com/OSGi-bundles-tp1926136p1926136.html
Future of bazaar Edit
I've been doing some reading on version control systems, and I'm becoming very concerned that bazaar may be seriously losing mind-share (and therefore maintenance, new features, IDE integrations, etc.) to git and Mercurial, even within Canonical. We are starting a project that we hope will have a 10-year active life, and so far our commitment to bazaar is limited. If we are eventually going to have to switch, it would be far better to do it now than a year or two years from now. Your thoughts are solicited. Grampajohn 17:39, November 18, 2010 (UTC)
I'd be fine switching over to github (http://www.github.com). This would give us an integrated ad free wiki as well. See also http://power-tac-developers.975333.n3.nabble.com/Re-the-future-of-bazaar-tp1929311p1929311.html
Carstenblock 08:27, November 19, 2010 (UTC)
There's also the option of setting up svn/trac (with limited wiki) on our own servers, but I agree that git(hub) seems to be the best solution.
Ddauer 12:55, November 19, 2010 (UTC)
github it is. I like this solution. We now have an account (Thank you, David) at https://firstname.lastname@example.org/powertac/server.git. David or I will initialize the repo shortly, and we will add repos for the other sub-projects.
Grampajohn 17:26, November 19, 2010 (UTC)