Key to OO design

I use to agonize how to organize code into classes, that is, how granular to make classes, should this class know how to entirely do X operation, what variables to expose and how to expose them, try to see how various class design patterns might fit (or not). 

In the last 3 years, class design has suddenly become a lot easier by focusing on test-driven design, how to make sure my classes can be tested in unit tests.  Everyone wants a well-designed class with well-designed methods to consume, and a well-designed class is also easier to test and verify as working properly.  But does a class that is designed with being testable in mind make for a well-designed class?  In my experience, strikingly yes.

If so, what supports test-driven design?  Dependency injection like implemented by the Spring framework supports test-driven design because together with interface-focused design, mock implementations can be substituted for real implementations in unit tests.  This alternative way of looking at how to "compose" together classes to do something useful has revolutionized my class design habits, buried bad practices and further made me a believer in test-driven design/development.  In general, I still don't write automated test cases first but I do sometimes (a third of the time?) begin with them now.

Converting legacy Java project to Mavenized project

For the majority of Eclipse-based projects, the most time-consuming part of converting to Maven is (a) determining which JAR files are actually used (compile and run-time), (b) determining their Maven GAV coordinates, (c) hosting the JAR files that are not stored in any public repositories.  Here are the steps I am currently following:

1. Some currently included JAR files may not actually be used.  These steps weed out those extraneous JAR files
2. From the existing files in the lib directory, determine which of them are actually needed by eyeballing.  You should have a pretty good idea of the major dependencies (e.g. core Spring, web service libraries).  Add these dependencies to POM; get GAV coordinates using something like determine-maven-dependencies-tool, a custom Groovy script I wrote that is now on Google Code
3. What are remaining compilation errors?  Look for the specific JARs in which missing classes live, using a tool like JarScan). Add these dependencies
4. What to do about JARs that are not found in publicly available Maven repositories?  
1. If found in non-standard repository, add repository to your Nexus server
2. If not found in any repository, upload JAR to your own Nexus server.  
1. Is it one already in your Nexus repository?  Verify by calculating sha1 hash of JAR contents:  File Checksum Integrity Verifier utility
2. What GAV coordinates to use for these unique JARs?  This is a question I am still seeking convention/guidance on.

Changing default directory

Sometimes it is necessary to change the default directory of an application, e.g. when there are limitations to Profile Storage Space on your Windows machine.

Application	Configuration location	Details
Maven	<user directory>/.m2/settings.xml	Change where local repository is stored, e.g. <localRepository>C:\_LOCALdata\m2\repository</localRepository>
Jetty		You can change where WAR files are extracted to, e.g. by simply creating a directory named "work" in your Jetty distribution
Nexus	<Nexus web app directory>/webapp/WEB-INF/plexus.properties	Edit file and change the property "nexus-work"
Hudson	<Jetty directory>/etc/jetty.xml	According to Administering Hudson, you can add a HUDSON_HOME environment variable and re-start Jetty, but this didn't work for me.  However the second option did work, add e.g.:     <Call class="java.lang.System" name="setProperty">         <Arg>HUDSON_HOME</Arg>         <Arg>C:/_LOCALdata/SERVICES/hudson-home</Arg>     </Call>

Maven build lifecycle

How long can you use Maven without understanding the Maven build lifecycle?  Notes from Introduction to the Build Lifecycle for someone who has already used Maven for awhile:

• Three built-in lifecycles: default, clean and site
• Different build phases for each lifecycle
• A goal represents a specific task, may be bound to zero or more build phases. A goal not bound to any build phase could be executed outside of the build lifecycle by direct invocation
• goal = Ant task (roughly) = an action during the build
• There is both a clean lifecycle and a clean phase 
• If a build phase has no goals bound to it, that build phase will not execute
• Each packaging (e.g. jar, war, etc.) contains a list of goals to bind to a particular phase
• Plugins can provide/offer multiple goals for execution
• If more than one goal is bound to a particular phase, the order used is that those from the packaging are executed first, followed by those configured in the POM

Can't add web project to Tomcat in STS

Trying to add a web project to a Tomcat instance.  The project has the Dynamic Web Module project facet enabled (Properties > Project Facets).  Still get this message:

Reason:

Grails project facet is not supported.  Need to use tc Server within STS.