Nicolas Fränkel

This week, I was faced with what seemed an near-insuperable problem. I was called by one of my dev: as soon as he upgraded his Eclipse (or more precisely, our own already-configured Eclipse), he couldn’t deploy to Tomcat through WTP. Here are the steps I took to resolve the problem and more general thoughts about upgrading and tooling. The log displayed a ClassNotFoundException, one involving Spring. So, the first step is to look under the hood. Provided you used the default configuration

In a previous post, I wrote about how to create skinny WAR with Maven the DRY way: it was not the DRYier way to do it, as was demonstrated to me this week by my colleague Olivier Chapiteau (credit where credit is due). His solution is far more elegant; it is reproduced in the post for reference’s sake.

Spams are a blogger worst enemy. For me, things went worse gradually, until last month, when I had to face about 10 spam comments per day on average, even though I had the WP-SpamFree plugin installed. When spams were fewer, this was not a problem since I had to moderate comments beforehand: users saw nothing. On my part, however, that meant some precious time managing comments and with the number of spam raising, I couldn’t do it anymore. My first reflex was to turn authentication on: yo

It seems a trend has caught on and accelerated recently: every organization worth his salt in the Java ecosystem feels the need to create its own language that runs on the Java Virtual Machine. Side by side with legacy languages like Jython and JRuby, and along more promoted ones like Scala, Red Hat announced Ceylon and now it’s JetBrain’s turn with Kotlin. However, the real question is not whether we need them (the answer is a simple 'no' since we created software without them), but

Last week, I was ticked off by the behavior of a colleague: he complained the duplicated code panel in Sonar was not explicite enough. When I remarked he could give feedback to the Sonar team, he replied he had other things to do! As for me, I use OpenSource projects since a while back: Struts was my first, but now there are the whole Apache frameworks (Log4J, CXF and Commons just to name a few), Spring, Hibernate, Vaadin of course but also tools like Maven, Hudson/Jenkins, Sonar and the list g

One thing I’m doing very often and always searching on the Internet is how to obtain a self-signed SSL certificate and install it in both my client browsers and my local Tomcat. Sure enough there are enough resources available online, but since it’s a bore to go looking for the right one (yes, some do not work), I figured let’s do it right once and document it so that it will always be there.

Code review is part of my job, and you cannot know the crap I’ve seen. Like someone pointed out, it’s also sometimes the crap I’ve written 🙂 In all cases, however, it’s because some developers do not have deep knowledge of how things work: most learnt something (in university or from a senior developer) years ago and don’t challenge this information regularly though technology evolve. Others just google the problem at hand and copy-paste the first snippet in their

Every build systems worth his salt acknowledges Maven dependencies repository. Even those vehemently opposed to the way Maven does things, like Gradle, still uses repo1. Wait, repo1? If there was only repo1. But nowadays, every project publishes its artifacts in its own repository. For some providers, like SpringSource and JBoss, I think it may be for marketing reasons. But whatever the reasons are, it only makes the job of the enterprise repository manager harder, since he has to reference all