Archive for June 2009
Oh, the joys of using maven. I had the great opportunity today to spend an extended amount of time on a task that should have required 10 seconds of typing and about 20 seconds of waiting. All I wanted to do was check out a new project from subversion and run "mvn eclipse:eclipse" so that I could import the project into Eclipse. Unfortunately, about a week ago, while doing a similar thing, I must have downloaded the latest version of the maven eclipse plugin (version 2.7) which decided that it was going to throw up all over itself.
The problem ended up being the inclusion of two elements in the pom that pointed to the same directory (src/main/resources). This is totally legal and very much necessary for the project in question. The first block uses filtering and includes a couple of files while the second resource block does not do filtering and excludes the files from the first block. It is basically a standard way to put all resources in one directory and filter some of them, while not filtering a certain set, for instance binary files like images which will react poorly to filtering. Regardless, the new version of the maven eclipse plugin couldn't handle this while its predecessor versions had no trouble with it. To be exact, the error that pops out is Request to merge when 'filtering' is not identical.
Now there are a couple of ways to handle this. One way would be to explicitly put the version of the plugin that I want into the pom of the project. This works, however I would need to do this in every project or put it into a parent level pom that all projects inherit from. Again, that works, but my main issue with this solution is that it now puts IDE specific information into our projects which really shouldn't care what the development environment is. And this error really only effects myself and the two other developers on the team that use Eclipse, not the four guys that use NetBeans or the one crazy mofo that uses emacs. Another solution would be to specify the plugin version number on the command line. This works as well, but my tiny monkey brain is well trained to type "mvn eclipse:eclipse' without thinking about it and I would never remember to get it right.
The solution that seems to make the most sense at this time is to use a plugin-registry.xml file, which prior to today I have never heard of. Thanks to the crazy emacs mofo mentioned earlier for pointing me in the direction of this link that describes how to set up the plugin-registry.xml file. If you want to skip reading through the info on the link, here is the cliff notes version...
Go to your settings.xml file and add "<usePluginRegistry>true</usePluginRegistry>" directly under the opening tag. Then create a file called plugin-registry.xml in the same directory as your settings.xml file. (NOTE: maven will auto create this file if you run any maven command at this point, but it is probably easier just to create it ourselves). In the plugin-registry.xml file, add the following content...
<?xml version="1.0" encoding="UTF-8"?><pluginRegistry>
This is basically telling maven that we currently want to use v2.6 and that v2.7 is rejected for all of eternity. When a new version gets released eventually, you will be prompted the next time you run an eclipse plugin goal and you can decide whether to use the latest version or not. Maven will automatically update the plugin-registry.xml file for you based on what you decide.
Maven is in the process of redesigning this functionality as the warning on the top of the earlier link states, but for now, it works pretty well.
Like all maven bugs, it sucks and takes you a bit to figure out, but going forward I have a quick and easy way to get around broken plugins. If anyone knows why they decided to break the eclipse plugin, I'd love to know.Tags: Maven, Eclipse
A Whole New Mind: Why Right-Brainers Will Rule the Future by Daniel H. Pink
The focus of this book is how left-brained (analytical) jobs are quickly being outsourced and how right-brained (creative) skills are the differentiator that will either help you keep your job or allow you to flourish in a new role within that job. Being in the software industry, this definitely rings true to me. I'm not good at my job if I just sit there and pound out lines of code like a good little code monkey. I'm good at my job if I can go to the next level, using creative thoughts to design complex systems or interfaces or put myself in the position of the end user and figure out what will make the best experience for them.
My father sent me this book. He is a former accountant/accounting firm president that is now in his second career as a practice management consultant. (See his website here, incidentally, the site is designed and maintained by yours truly). The successes that my father and the firm he worked at had was not because they could complete a perfect tax return, it was because they could think beyond that, taking in the full picture of their clients situation to offer then advice in other aspects of their financials and business growth and help them plan for the future. In fact, these days, you can easily outsource the initial processing of a tax return to India and get the results back in the morning. If your only skill is being able to process a tax return, watch out, it is likely cheaper to send that tax return half way around the world than it is to have you do it.
The book highlights six areas where right brained thinking matters most and offers exercises on how you can improve your right brain skills. My personal favorite is the chapter on Empathy. Empathy is the ability to put yourself in someone else's shoes and feel what they are feeling. As a software developer, this skill is becoming more and more important to me. I need to sit there and make decisions based on how the user will feel when they use the tools/programs that I develop. Will an extra click here matter? Does this page layout make sense? How does the user do their job and what will make them more efficient? These aren't things you learn in college (at least I didn't). These are things you have to work out and start thinking about differently. It isn't acceptable for software to just be functional, it has to be usable, and highly usable at that.
The other five chapters pull in additional important themes in right brain thinking. This is definitely a book that you should read if your job involves mostly left-brain thinking, or if you haven't figured out how to bring the right side of your brain along for the ride.Tags: Books
Recent PostsHandling Broken Maven Plugins
Book Review - A Whole New Mind
Portfolio Viewer on Computer World
Onwards and Upwards
Book Review: Made To Stick
ArchiveJune 2009 (2)
September 2008 (1)
June 2008 (1)
April 2008 (2)