I had the pleasure of presenting two talks at Øredev this week. For those of you that asked, here are the slides and the code samples:
Comments and feedback in both positive and constructive criticism formats are greatly valued. Drop me a line via email or twitter.
This week, I made a four day journey to the very forested state of North Carolina. Joey knew a Coloradoan was coming and turned on the statewide AC to bring it down to a comfortable 72 degrees Fahrenheit when I landed. The food was great, the people were super, and the technology was awesome.
I had an open invitation to come out and visit the team at Relevance, which I’d been waiting to cash in. The Research Triangle NFJS Symposium finally made that visit possible.
I had a great time meeting the entire Relevance team, working with Stu Halloway on automating the Clojure release scripts through some Bash scripting, Git calls and Maven Ant Tasks.
At lunch, I gave a live demo of my workflow with the DevonThink Pro product, including capturing and aggregating multiple RSS streams alongside archived emails and snippets from web pages.
In the afternoon, I had the fun assignment of working with Aaron Bedra on an implementation of JCE symmetric AES encryption on a Clojure project. He followed up a day later on “Relevance Open Source Friday” by beginning to move the implementations over to a standard library for upcoming public consumption.
I had the pleasure of presenting Encryption, Open Source Debugging on the JVM (over 50 deliveries of that one now), Hadoop, Maven 3 and Git to the engaged audience in Raleigh on Friday and Saturday. The during-presentation questions were spot on, and even when the topics got heady, the students just leaned forward in their chairs and kept on making insightful inquiries. Attendees of that nature are pure candy to a passionate presenter like myself. I especially want to thank Darin Pope, Billy Dupre, David Bloom, David Deininger, Sri Sankaran, Asif Rashid, and Ed Savage for providing much-desired feedback on Twitter.
I know I’ll be back for the NFJS show next year, but I’ll make all efforts to put in a few more visits prior to that. A city with a technology culture of this strength demands that I do. Thanks for having me and perhaps I’ll see some of you at the Rich Web Experience in December on the beaches of sunny Florida.
For the folks that attended my talks this weekend, here are some constantly updated supplemental materials to resources that are paired with the slides:
I’m excited to announce that I’m presenting several informative talks in Europe and Scandinavia this Fall.
First up is JavaZone in Oslo, Norway. I can’t believe this classy and large of a show is put on by a user group (in a sports arena). Clearly, it has a great committee and a great director at the helm. This is where I first met the likes of Ola Bini of JRuby and Kohsuke Kawaguchi of Hudson fame. If you are in reach of Norway, this is a must-see developer event with presenters gathered from all over the world.
Next up is the exciting Øredev in Malmö, Sweden. I’ve heard from my colleagues at No Fluff Just Stuff that this is a stellar event. The quality of materials Øredev has sent out to speakers has been amazing thus far, and literally table-discussion worthy for inclusion in our Presentation Patterns book. I’m going to be in every one of Evan Doll’s iOS sessions.
Finally, I’m presenting a nitro-enhanced version of Encryption on the JVM at Devoxx in Antwerpen, Belgium. Another conference (like the awesome Jazoon) in a movieplex? Anytime! No worrying about the size of code samples on the screen, that’s for sure. Is a 30 meter screen big enough for you? I hear that Devoxx is the JavaOne of Europe. The lineup of speakers is phenomenal. I will be in a chair for every session besides mine.
If you are in Europe, or are of a traveling persuasion like I am, any one of these three venues would be a big enhancement to your knowledge and relevancy in the JVM development world in 2011. I hope to meet many of you I’ve only spoken with digitally before. I’ve already received dozens of “see you there messages.” Add your name to that list.
I’m pleased to announce that MuleSoft and I have collaborated to freshen the world’s two most commonly used Maven Web Application Archetypes, the maven-archetype-webapp and the wicket-archetype-quickstart.
These two archetypes had fallen out of date, both in terms of using the new Archetype 2.0 style metadata, as well as in the dependencies on the third-party libraries such as JUnit. Due to limited volunteer developer time, when the Maven Archetype developers moved from the 1.0 to the 2.0 branch many of the existing archetypes did not successfully make the transition. Thus, the public was having to make do by using old versions of these archetypes.
Given MuleSoft’s and my keen interest in the Apache Tomcat ecosystem, including the enterprise-strength Tcat product, we set out to bring these two aging archetypes up to date. We found that easiest to do under the very open MuleForge repository & GitHub source code hosting for the near term, but we will be submitting a patch to get these improvements back into the core archetypes at Apache too.
A week into the effort, the “update” turned into a complete “rewrite” of the archetypes to reap all the benefits of the Maven Archetype Plugin’s version 2.0 features.
The metadata has dramatically changed between the Maven Archetype 1.0 and 2.0 versions of the plugin. Previously, the file named archetype.xml lived in the src/main/resources/META-INF/ directory, then it was relocated to src/main/resources/META-INF/maven, and finally, in full modern 2.0 form, has been additionally renamed to src/main/resources/META-INF/maven/archetype-metadata.xml.
Similarly, variables inside source files were updated to use the ${} notation, with legacy elements like $package updated to ${package}.
The poms for the archetypes were updated from the old archetype plugin type to use the new 2.0 lifecycle extensions
The resultant archetype code is hosted at GitHub for easy viewing, consumption, technical review and forking. We’d love to get your input and improvements!
These two archetypes now represent the most pristine use of the Maven Archetype Plugin v2.0 format.
We didn’t want to stop at just updating the archetypes though. We wanted to make them better. So one of the most obvious ways to do that was through adding integration tests. I can’t tell you how often I get asked for a good example of leveraging the Maven pre-integration-test and post-integration-test lifecycle events. Up until now, I’ve been relatively empty handed to respond to this request, but finally we have some reference examples.
These lifecycles are now bound to the redeployment and undeployment of the web application artifact (WAR) and the execution of a JWebUnit integration test that exercises and validates the home page on each of the JSP and Wicket flavors of web application.
We’ve built a wiki page showcasing the usage of this archetype which we also invite you to review and improve. In short, you can inform Maven of the new archetype catalog via a quick execution of:
mvn archetype:generate -DarchetypeCatalog=http://dist.muleforge.org/maven2/
Lastly, for those of you that prefer a video walkthrough of the usage of these two archetypes, check out our screencast demo that takes you from start to finish of working with these valuable new tools in the Maven, Tomcat, Tcat, and web application development ecosystems.
Like all good developers, we are always looking towards the next iteration, just as the current ones are drawing to successful close. In the next release of these archetypes, or perhaps in supplemental sibling instances, we’re exploring:
In closing, we want to thank the Tomcat community for founding such a great product and the Maven community for planting the seeds of these new archetypes. Java web application development is at its current fevered pitch, thanks, in large part, to these excellent tools and their communities.
A little late night hacking and I was able to get encrypted passwords to work in the Maven SCM plugin with Maven 2.2 based on the prodding of Kurt Tometich, an NFJS attendee, and his JIRA bug# SCM-495. Previously, this encryption feature only worked for Wagon providers (the connectors for uploading artifacts), not for SCM providers, contrary to some blog comments.
It was quite the effort. After a few minutes, I found the code in DefaultMaven.java that performed the decryption. Now, I thought, “just implement a similar call in AbstractScmMojo.java right?” I harbor a bit of angst for the fact that the JIRA isn’t Fisheye-connected to the source code repository, so finding the files changed for a given defect is much harder than it should be.
The Maven Mojo Developer Cookbook did offer a bit of insight (though syntactically off a bit on the container.getLookupRealm()) on how to get a handle to the container and look up the security provider, DefaultSecDispatcher.java.
SecDispatcher sd = null;
try {
sd = (SecDispatcher)container.lookup( SecDispatcher.ROLE, "maven" );
}
There was even the fabled “java.lang.ClassCastException: org.sonatype.plexus.components.sec.dispatcher.DefaultSecDispatcher cannot be cast to org.sonatype.plexus.components.sec.dispatcher.DefaultSecDispatcher” at one point. Oh nuts. Not the classloader scoping issue, please…
The trick on the classloader is that the DefaultSecDispatcher class is available via a dependency to plexus-sec-dispatcher, but also included (repackaged) in the Maven core distribution maven-2.2.0-uber.jar. So the SCM provider project’s dependency on plexus-sec-dispatcher has to be scoped as <provided> for compilation of the maven-scm-plugin.
Lots of learning about the Maven code base occurred. The only interesting finding was how, instead of putting the decryption on the accessor (getter) of password from the settings data structure, it is put in each place it is attempted to be used (e.g. the Wagon “dispatcher”, and now the SCM “dispatcher”). I’ll bring up a refactoring of that with the Maven IRC folks…
In the spirit of automating anything I’ve done more than twice manually, here’s an incredibly simple yet useful little script to recursively search a tree of JARs for a class file. I most often use this against a local Maven repository.
#!/bin/sh
#Example Usages:
# findjars com/ambientideas/SuperWidget
# findjars AnotherWidget
CLASSNAMETOFIND=&quot;$1&quot;
echo &quot;Searching all JARs recursively...&quot;
for eachjar in `find . -iname &quot;*.jar&quot;`
do
#echo &quot;Searching in $eachjar ...&quot;
jar tvf $eachjar | grep $CLASSNAMETOFIND &gt; /dev/null
if [ $? == 0 ]
then
echo &quot;******* Located &quot;$CLASSNAMETOFIND&quot; in $eachjar *******&quot;
fi
done
I’m very pleased to announce that my DZone Maven RefCard was released this week ahead of schedule, and JavaLobby did a little introductory interview for the launch. A handful of folks contributed to the early alpha reviews and I want to acknowledge their inputs: Ken Sipe, Tim O’Brien, Chris Maki, Tim Berglund, and Jason van Zyl.
The timing was great, as I did a Mastering Maven talk at the San Diego Java Users Group (SDJUG) on Tuesday night. A handful of the attendees came with printed copies of the RefCard in hand!
I’m always looking for ways to contribute to the Maven community, and this was by far the most fun I’ve had building materials to promote this unique Convention over Configuration build tool.
Git, the oft-referred to as “Linux, Rubyists, and Cool Kids source code control system”, is gaining ground so fast that there’s not enough room in this post to mention all the traction and good press it is achieving. Yet, a common comment I hear over lunches and cubicle walls is
“Git doesn’t have good support on Windows yet.“
I politely disagree.
While the methods for putting Git on Windows have a slight variance from that of putting it on Mac or Linux, I have seen no real compatibility issues in my near daily use of it on all three aforementioned platforms. Is there still room for it to get better on Windows though? Definitely!
The next lament I hear is
“If only there were a Tortise-like UI for Git.“
Let me also put that to rest and direct you to the TortiseGit homepage. While TortiseGit is still a work in progress, I’ve seen a handful of folks already putting it to productive daily use. And if you don’t like TortiseGit, then try GitSafe. And if you are using IntelliJ, support is built right into v8.1, Eclipse has eGit as an official Eclipse project now, and NetBeans has an issue open and some ongoing work for support which, awesomely consumes parts of eGit (JGit Libs) from Eclipse.
And just to share the “Peanutbutter in my Chocolate” favorite story of the week, Maven is moving to Git in many directions at once:
If you have yet to explore or fully leverage the power of Git or Maven, now is a critical juncture of market acceptance for these tools, and accordingly, a perfect time to explore their benefits. For the latest news on Git, Maven, iPhone development, and Open Source, join the conversation over at Twitter.
Maven 3.0, a mostly-backwards compatible, but significantly improved and extensible version of Maven is developing very quickly. Jason van Zyl hosted a Maven Meetup at their offices in Mountain View in March of this year. Lots of deep information about Maven 2.0 and 3.0 was shared, and videos of some of the sessions are now starting to be posted to the Vimeo web site. The Maven 3.0 video is especially insightful:
Jason van Zyl on Maven 3 from Sonatype on Vimeo.
Here are the takeaway points, highly distilled to 140 proof, for those without time to watch the video:
If you want to get access to the Maven 3.0 code, you can view the list of SVN checkout URLs here (or here for the hardcore Git lovers), or just view the source in your browser here. If you want early access to the binaries, you can download them from Apache.
If you are running a Continuous Integration server such as Hudson, you’ll want to consider routing your SureFire outputs to the console so that they’ll appear in the build-report logs. If you leave SureFire at its default, it will output each test’s success or failure to an individual test XML and TXT file, but those are likely not in an exposed directory on your CI server. If instead, you route the output to the console, it will get reported in your failure emails that your CI server is capable of sending.
Just pass the useFile=false parameter on the command line or set it in the plugin config section of your pom.xml.
mvn test -Dsurefire.useFile=false
Before:
-------------------------------------------------------
T E S T S
-------------------------------------------------------
Running com.ambientideas.AppTest
Hello World! This is a JUnit test!
Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.045 sec <<< FAILURE!Results :Failed tests:testApp(com.ambientideas.AppTest)Tests run: 1, Failures: 1, Errors: 0, Skipped: 0
After:
-------------------------------------------------------
T E S T S
-------------------------------------------------------
Running com.ambientideas.AppTest
Hello World! This is a JUnit test!
Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.045 sec <<< FAILURE!
testApp(com.ambientideas.AppTest) Time elapsed: 0.014 sec <<< FAILURE!
junit.framework.AssertionFailedError
at junit.framework.Assert.fail(Assert.java:47)
at junit.framework.Assert.assertTrue(Assert.java:20)
at junit.framework.Assert.assertTrue(Assert.java:27)
at com.ambientideas.AppTest.testApp(AppTest.java:37)
Results :Failed tests:testApp(com.ambientideas.AppTest)Tests run: 1, Failures: 1, Errors: 0, Skipped: 0