The CodeMash 2009 Conference in beautiful Sandusky, Ohio was just announced.
Last year was a blast. In addition to the copious amounts of Rock Band that was played, and waterslides that were slid on, I presented a session on Continuous Integration. This year, I plan to propose a session around deployment and artifact management. Sounds exciting, right?
See you there!
Last weekend was the Agile Coach Camp here in Ann Arbor. There were a lot of very interesting folks there, and as always happens in such situations, plenty of learning happened.
On the first evening, we had Lightning Talks, during which I presented an idea that had been brewing in my head for a while. It seems a little silly at first but I think it has some merit.
Basically what it comes down to is that I want to wear shorts and sandals to work. Things may be different on the west coast, but here in the midwest, jeans are about as casual as you can go without raising quite a few eyebrows.
The fact is that if you’re not in front of customers on a day-to-day basis, it really shouldn’t matter what you wear. You and your employer should strive to make you as comfortable as possible, thereby making you more productive.
My proposal is for the Agile community to unite and suggest to clients during Agile Transformations, that a key element to reaching Agile Nirvana is to free their staff of the corporate dress code.
Now, I’m the first to say that there need to be limits, but I think we can trust teams to exercise enough self control and common sense to make it work.
Who’s with me?
I had to move a Subversion repository from a really slow crappy server to a shiny new one today. Luckily I found a blog entry that made it super easy.
I’m always having to remember/lookup what I should put in my Eclipse settings file (eclipse.ini), and I’ve run into many a colleague frustrated with OutOfMemoryError & PermGen messages.
I also have a rather large list of installed plugins, so I’ve recently upped the max memory numbers which has provided me with some more speed & stability.
So, without further ado, here is my current eclipse.ini file:
-showsplash org.eclipse.platform --launcher.XXMaxPermSize 256m -vmargs -Xms256m -Xmx1024m -XX:MaxPermSize=324m
The second XX:MaxPermSize will prevent all those nasty PermGen errors.
Note that I’m currently using a machine with 4GB RAM. You should be able to safely cut down the sizes on machines with less.
I just released my first Hudson plugin called Naginator, which allows Hudson to automatically re-queue a build after it fails. (The name was suggested by my colleague Mike Gantz)
Check it out!
Although a single, independent module deployment worked fine, I couldn’t get my multi-module deploy working properly via the webdav wagon.
I’m talking about the simple mvn deploy command (versus mvn deploy:deploy-file), which must work if you ever expect to be able to do a mvn release:perform.
The error that I was seeing was:
Error deploying artifact: Unsupported Protocol: 'dav': Cannot find wagon which supports the requested protocol: dav Component descriptor cannot be found in the component repository: org.apache.maven.wagon.Wagondav.
In the comments section of the Maven User Guide, there is blurb saying to put a bunch of libraries in the $M2_HOME/lib directory. While it seems odd, it fixed my problem. The comments are for wagon 1.0-beta-1. Here is the minimal list of JAR files that I needed to get it going for wagon 1.0-beta-2 (NOTE — You must use the older 2.0.2 version of httpclient):
http://repo1.maven.org/maven2/commons-httpclient/commons-httpclient/2.0.2/commons-httpclient-2.0.2.jar http://repo1.maven.org/maven2/commons-logging/commons-logging/1.1.1/commons-logging-1.1.1.jar http://repo1.maven.org/maven2/org/codehaus/plexus/plexus-utils/1.5.1/plexus-utils-1.5.1.jar http://repo1.maven.org/maven2/slide/slide-webdavlib/2.1/slide-webdavlib-2.1.jar http://repo1.maven.org/maven2/org/apache/maven/wagon/wagon-webdav/1.0-beta-2/wagon-webdav-1.0-beta-2.jar
(Update 2008-04-10): Maven 2.0.9 has just been released, which includes the webdav wagon by default, and does not require any of this configuration — yay!)
If you don’t want read my fascinating commentary, you can skip directly to the solution.
Whenever I’m working with Spring, I tend to go through the following pattern:
This was the pattern that I went through with a colleague at my client over the past week or so as we were trying to implement set up FitNesse to call a Spring service.
My first thought — surely FitNesse has a way to do this already. Well lookee here … the FitNesse SuiteFixture seems to fit the bill: “Each suite can provide different configuration information, such as selecting a DB or Spring configurations”. Whoops, did I mention that there are no example, and a google search reveals just about nothing.
Next — The spring-fitnesse project seemed to hold some promise… I bailed out when I read the instructions: “Compile the library: Modify ant.properties to match your installation. Then start ant.” Why don’t they just distrubute a compiled library? Maybe we’ll come back to this if nothing else pans out. <nose-in-air>Plus, I’m a maven guy now, so dropping back into ant seems so last year.</nose-in-air>
Over to this blog posting: The Magic Ingredient for FitNesse, Spring … Could this be it? It’s kind of solving a different (more advanced) problem than we were having, namely getting each FIT test to run in a transaction, and rollback any data changes at the end of the test. We didn’t have this need yet, so modifying the actual Fit Server code seemed like overkill.
Finally, we ran across How to wire your FitNesse fixtures with Spring. This seemed to hold the ticket, but something just didn’t jive. I left a question in the comments (which has since been answered, and may indeed also solve the problem), and continued the quest.
By this time, it was clear that the problem was that the FIT fixtures were invoking my POJO Spring service bean outside of the Spring container, and thus none of the Dependency Injection, etc. was taking place. Going back to the Spring docs (see step 6 above 
), it became clear that we were overly complicating matters, and that all we needed to do was have the fixture instantiate the Spring container and then get a Bean from it. Thus, the Fixture code ended up as:
public boolean isValid() {
BeanFactory beanFactory =
new ClassPathXmlApplicationContext("classpath:/spring/applicationContext.xml")
.getAutowireCapableBeanFactory();
loginService = (LoginService)beanFactory.getBean("loginService");
loginService.validateUser(username, password);
}
Obviously, a lot of refactoring can go on here, including moving this setup stuff into a base class, making the bean factory static, etc. — this gets us going however!
I just had an experience that scored another point for the TDD camp.
Over the past few months, I’ve been implementing a web service for a B2B process from my current client. After looking at Spring-WS, XFire and CXF, I was pretty much forced into using XFire due to being restricted to JDK 1.4 by my client’s infrastructure. Spring-WS didn’t support JDK 1.4 at the time, and CXF requires J2SE 5.0 at a minimum.
I built the application using a Test Driven approach and ended up with a nice design with about 94% code coverage.
Last friday, I started working on a requirement that would require some features absent from XFire. I revisited Spring-WS, which seemed to have what I needed — plus, it now supported JDK 1.4! Yahoo! To make a short story, well, shorter … I replaced XFire with Spring-WS within about 2 hours. It was extremely simple to swap out, run my test suite and confirm that everything *just worked*.
btw — Spring-WS is a really nice framework. Very simple to understand and use, and (obviously) fits in with the Spring paradigm quite nicely.
Wow — I need these in a bad way. Now if only they could make them look just *slightly* less dorky.
I’ve been using the M2Eclipse plugin for quite a while now via the update site located at http://m2eclipse.codehaus.org/update. It’s served me pretty well, even though there were a few annoying bugs w.r.t. compiling in JDK1.4, etc. Eclipse would notify me of updates every so often, which I would loyally install, but I never noticed it getting significantly better.
Anyway, while helping some new developers get set up with Eclipse/Maven, I pointed them over to the installation website, only to find out that the update site has been changed to http://m2eclipse.sonatype.org/update! Those sneaky developers. 
One would expect at least a redirect from the other update site.
I’m happy to say that the plugin from the updated site seems to work significantly better than previous versions, so a shout out to Sonatype, who I assume is behind the development.
Subscribe via Email
Subscribe in a reader
