Maven Settings

So there are so many settings that get set before running a Maven build that it gets crazy.  There was a Confluence wiki that I used as part of Codehause (before they closed their doors) that I referenced a bunch when I was doing hard-core Maven plugin development that was extremely helpful.  You see, there are a bunch of ways that you can get the maven properties, but each of them requires setting up something in your project or running some odd command – but all I want is a simple reference.  So, I looked at this confluence site (which can still be found here, at least for the short term future) and compiled a list of very useful properties that everyone should have at their fingertips.  That way, whether you are setting up a project or doing plugin development, you can hit this reference.

Understanding Where The Properties Come From

First though, I’d like to cover the several ways that these properties are set.  Some are clear, some are not so much.

Maven loads up the XML files into Java Objects, and provides them for Maven plugins and the developer to use.  These XML files include pom.xml files, parent pom.xml files, as well as the settings.xml (and occasionally security-settings.xml, but I won’t cover that too much here).  The hierarchy can be a bit hard to follow for the uninitiated, but remember that all properties are resolved and then inherited (IN THAT ORDER) and the inheritance works in the way that pom.xml > parent pom.xml > settings.xml.  Or, a better way to think of it is that the most specific one wins.  Also, just in case it wasn’t clear, this is all case-sensitive, so “MyProgram” and “myprogram” are two separate variables.

When you want to access a variable, you just use the Ant model of variable replacement, which is the following: “${var_name}”.  This will evaluate the var_name and resolve it as part of your maven build.

Continue reading

Using HK2 with Jersey (with auto-scanning!)


HK2 has been an interesting ride. For the most part, if anyone asks, I’m still going to suggest Spring for Dependency Injection, because the documentation is a thing of wonder. Plus, Spring Inversion of Control (IoC) and Aspect Oriented Programming (AOP) are the wheelhouse that makes all of the other Spring stuff possible.  However, there are some situations where using these technologies are requested/required, so it’s good to know how to use them.

Understanding Dependency Injection

Dependency Injection is a great way to decouple your code from the implementation.  For example, if you create an interface in your core program, and you can leave the implementation for creation in a different library.  How is that useful?  One example of this would be for database access.  If you create a simple interface, like the following:

Now, use this interface in some form of implementation. This should provide a simple passthrough implementation usage of the interface:

You can then make two different implementations that function very differently, and put them in separate jars.

The first could access a database, such as PostgreSQL:

The second implementation could be a MongoDB implementation:

Now for the interesting part… You want it to be able to change at runtime. So your customer can easily change and use PostgreSQL or MongoDB with ease. Heck, they can even add a Redis store with ease and without having to recompile a single line of code. It seems like magic, but it’s not. It’s just smart decoupling.

Continue reading

The New Hotness – Spring 4’s Spring Boot

The guys who make the Spring framework libraries are no slouches.  They know the ups and downs of their own framework, as well as Java as a whole.  They are also on top of all of the newer JVM technologies, such as Groovy, Scala, Gradle, Spock, etc.  Heck, if they weren’t making money hand over fist, I’d think they would be great core language developers.  The would progress the language to a point that I’d love using it again.

The reason I say all of this is because the developers of the Spring framework realized that there are a couple other frameworks out there (Ruby on Rails, Grails, Django, etc.) that favor convention over configuration.  Meaning, I don’t want to have to set up 50 XML files to configure a project just so that I can get it running as a simple web service.  It shouldn’t be that complicated.  Spring 4 has some answers for you.  Spring introduced Spring Boot, a group of annotations that will favor convention over configuration… at least until you need to change it to something more complicated. The way it acts, I think they may have backported some of the stuff they did for Grails right into Java. Continue reading

SOAP vs REST – Understanding the Underlying Differences

I’ve never used Simple Object Access Protocol (SOAP), because, since I’ve been a developer, I’ve always been involved in projects using Representative State Transfer (REST) services.  Turns out, this wasn’t as simple of a question as I’d hoped.  Also, it seems that it’s not an old protocol that nobody should use.  It actually has plenty of good uses and a bunch of solid tools too.
Continue reading

Painfully Obvious – Synchronizing Git and SVN

So I was put into a funny position where we need to mirror our code to a customer’s Subversion (SVN) repository recently. Basically this is a customer requirement. We have been working in Git forever though, and the paradigm shift to move back to Subversion is just not acceptable once you get used to Git or any of the other DVCS options. It’s literally painful. Unfortunately, some customers dictate the rules. So, we were trying to figure out how to mirror the code in the best possible way. Let me walk you through my day and thought process. Please note, the end solution was not one that was perfect. Actually, the perfect solution doesn’t really exist, but this is the best we could do and hopefully it saves folks some time.

The scenario

Most of our changes were being kept in Git, with an occasional push to Subversion. But when in Subversion, we may have some integration issues and have to push back a couple of changes. If we can keep the history synchronized, awesome. If not, the merges just need to be reasonably painless. Continue reading

Making your Git Diff/Merge More Useful

OK, it is understood that you should try to keep your commits small in git, as well as other content versioning systems, but sometimes, you have to refactor or have a branch that won’t die.  Unfortunately, the merge process gets really painful.  Depending on what you are merging, this can sometimes be made much easier.  For example, if you are coding, the default line-by-line compare kinda sucks.  So I did a bit of research with my buddy, David Souther, to find out how to make this better.

Patience algorithm

The first algorithm is called the patience algorithm, which is documented visually here.  It’s basically searching for matching full lines to find points that haven’t changed.  This is useful, because if you are programming an API, this is likely to change less frequently than the code inside the API.

Histogram Algorithm

This is the one that jgit uses by default.  Eclipse, in turn uses the egit plugin, which uses jgit under the hood.  So basically, Eclipse uses this by default.  I attempt to stay out of the IDE as much as possible these days though, so I’d rather this be run on the command line.

Myers Algorithm

There is also a third, only sometimes useful one called Myers algorithm, which is a basic greedy algorithm.  It can sometimes be useful when you know that your code is in large runs in particular section.  More info here.

Testing it out

To test these out, anyone can do the following to see the default compare of a file and the last change in its history:


versus the following, which will run the patience algorithm:


Keeping the Change

You get the general idea.  Just adjust the algorithm with the “–histogram” or “–myers” flags.  If you want to keep a particular one, run “git config –global diff.algorithm patience”, which will save this as your default git diff algorithm.

Bash and Zsh Shortcuts

I’m not going to beat you up with the benefits of using zsh over that of bash. You really should know both, since bash is everywhere. Zsh is the newer version that is a powerhouse, though. So if you should decide to use this, I suggest checking out the program oh-my-zsh, which gets all of the common shell configurations set up for you and keeps it up to date.

But, what I really wanted to share was a good reference for bash/zsh shortcuts.  There are others out there, but they seem to be incomplete.  If I’ve missed anything, let me know and I’ll add it.

Command What it Does
Tab Auto-complete files and folder names
Ctrl + A Go to the beginning of the line you are currently typing on
Ctrl + E Go to the end of the line you are currently typing on
Ctrl + F or → Forward one character.
Ctrl + B or ← Backward one character.
Meta + F (in OSX this is ESC, F or ALT+ →) Move cursor forward one word on the current line
Meta + B (in OSX this is ESC, B or ALT+ ←) Move cursor backward one word on the current line
Ctrl + P or ↑ Previous command entered in history
Ctrl + N or ↓ Next command entered in history
Ctrl + L Clears the screen, similar to the clear command
Ctrl + U Clears the line before the cursor position. If you are at the end of the line, clears the entire line.
Ctrl + H Same as backspace
Ctrl + R Lets you search through previously used commands
Ctrl + C Kill whatever you are running
Ctrl + D Exit the current shell
Ctrl + Z Puts whatever you are running into a suspended background process. fg restores it.
Ctrl + W Delete the word before the cursor
Ctrl + K Kill the line after the cursor
Ctrl + Y Yank from the kill ring
Ctrl + _ Undo the last bash action (e.g. a yank or kill)
Ctrl + T Swap the last two characters before the cursor
Meta + T (in OSX this is ESC, T) Swap the last two words before the cursor


Update 7/22/2013 – My buddy David Souther liked this one so much he created a little worksheet from it and added some sed commands.  It’s great for a reference.  Check it out here!