Now, why would I write something as simple as a timestamp plugin? Well, I am the first to admit that adding timestamp in your build process is not exactly rocket science. But unfortunately most of the procedures to do just that made it seem more complicated than it should be. Either you jump through hoops trying to get a filter output back into your pom.xml, or you end up using a plugin that doesn’t have the ability to give you a customized date format (who the hell knows at first sight that the timestamp 1212931073482 means 8th june 2008 15:18h?!). So out of this frustration, the timestamp plugin was born. Have fun with it folks

Well, let me save you some time here. At first you might be looking for a function that matches strings. By looking into the w3c xpath function reference you’d find a function called contains(). ‘contains()‘ takes two parameters. And here the fun starts.

What the reference doesn’t tell you (ok I’m sure it does tell you somewhere), is how to fiddle your matches into the first contains() parameter, which incidentally is the text you want to scan. If your document looks something like this:

<mydocument>
   <food>Bavarian Donuts</food>
   <food>Cheesecake</food>
   <food>Oranges</food>
</mydocument>

Your first approach might look like this: /mydocument/food[contains(/mydocument/food,'Donuts')] Which, in a universe where everything makes perfect sense, would yield you one hit. However, this one just breaks your XPath processor, because contains() doesn’t accept multiple matches as the first parameter.

Instead you can do this: /mydocument/food[contains(.,'Donuts')]

The trick is that you use the '.' which is a shortcut for the current node function to reference the currently matched node as input to your contains() function. That’s all there’s to it.

Sure, you can still wire your static beans if you want to, but much more excitingly you can use component scanning to look for beans at runtime. No fiddling with XML at all.

Mark Fisher does a very good job of explaining the full impact of this in his InfoQ article on Spring 2.5. Also there is the much more comprehensive Introduction to 2.5 by Rod Johnson on TSS.com.

But what really caught my interest was Interface 21 CTO Adrian Colyer’s elaboration on Spring’s investment into the OSGi spec. If you listen to him you suddenly realize why exactly the runtime wiring became necessary. The upcoming Spring OSGi API takes the fact into account that Spring configuration at runtime is cool and all, but modularity gets ever more important. Coyler talks about all the interest the application server vendors have in OSGi and how big Web application projects may look like in the future.

In large applications we may see lots of dynamic service OSGi modules, wired together at runtime by Spring, that, as a whole, make up one or more applications. Spring takes into account that OSGi services may come and go at any given moment. Thus updating parts of the application (deploying a new service) instead of changing out a monolithic WAR file becomes a possibility. Exciting stuff. I will look into that some more.

Of course there is plenty of other cool stuff in 2.5, just check out the SpringSource blog or read the Changelog.