The container 'Maven Dependencies' references non existing library

If you copy an Eclipse-Maven project from one computer to another, you may get a Build Path Problem resembling:  "The container 'Maven Dependencies' references non existing library 'XXXXXXXXXXXX'".  This is obviously due to a difference in the location of the local Maven repository from one computer to the other. 

To fix this, right-click on the project > Maven > Disable Dependency Management.  Once Eclipse has finished rebuilding the project, right-click on the project > Maven > Enable Dependency Management.  This error should now be gone.  

Maven error "Cannot find wagon which supports the requested protocol: ftp" and Hudson

It is important to understand that Hudson comes bundled with Maven but you can also configure Hudson to use an external installation of Maven (Manage Hudson > Configure System > Maven 3 section).  When you add a Maven build step to your Job, you have the option to use the bundled Maven or your external installation.  However, the default is the bundled Maven. 

This can cause problems if you need additional classes required by your Maven plugins that are not automatically downloaded, e.g. FTP support for the Deploy Plugin or Wagon Plugin (http://mojo.codehaus.org/wagon-maven-plugin/).  That is, if you have dropped the required JAR into the "lib" sub-folder of your external Maven installation but the Job is configured to use the bundled Maven, you will continue to get "Cannot find wagon which supports the requested protocol: ftp" (in this case).

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

Third-party JARs and Nexus

The Nexus documentation (start here and Uploading Artifacts) is quite good for what to do to deal with third-party JARs and basically JARs that don't reside in any repository out in the rest of the world (obsolete versions or proprietary).  However, if you aren't careful, the Nexus user interface can be misleading.  For the Artifact Upload interface, it can be easy to select the POM file and select the JAR artifact, but neglect to press the Add Artifact button.

Nexus will then simply upload the POM file but not the JAR file.  At this point, the clean-up of the mess begins.

Your Maven build will fail, not being able to locate the JAR file.  If you attempt to re-do the step, but this time, pressing the Add Artifact button, you will get the following error:

You need to clean up the repository of the Nexus server, which you can do by going to the Browse Storage tab > navigating to the appropriate section by GAV > right-click > Delete. 

 However, if you attempt another build, Maven will fail again.  If you look at the build log, you will see something like:

Failure to find ... in http://.../nexus/content/groups/public was cached in the local repository, resolution will not be reattempted until the update interval of nexus has elapsed or updates are forced

The next step is to go to the Local repository where the Maven build ran and clean it up.  Navigate in the file system by GAV and you will find files named similarly to:

some-artifact-0.1.jar.lastUpdated

some-artifact-0.1.pom.lastUpdated

Delete these, re-run the Maven build.  It should find your artifacts now.

Getting Groovy test cases to run with Maven

Groovy is excellent for writing test cases because of its brevity and meta-programming capabilities.  For example, a class that I was using to do integration testing called System.exit in its main method.  With Groovy I could re-define its main method so that I could continue running the rest of my test code:

        Launcher.metaClass.'static'.main = { String[] args ->
            delegate.programArguments = args
            delegate.init()
            delegate.run()
            // No more System.exit!
        }

However, to get Groovy test cases to run inside Maven (and outside of Eclipse) requires some tweaks.  First of all, you have to make Maven aware that there are Groovy test cases to execute, or else it won't even find them  The section "Configuring Maven2 to compile and run your Groovy tests" in the article Writing unit tests using Groovy is mostly correct but it is out-of-date.  If you use its Maven coordinates verbatim, you will have errors in your Maven output.

Error:  Execution default of goal org.codehaus.mojo.groovy:groovy-maven-plugin:1.0-beta-3:testCompile failed: An API incompatibility was encountered while executing org.codehaus.mojo.groovy:groovy-maven-plugin:1.0-beta-3:testCompile: java.lang.NoSuchMethodError: org.codehaus.plexus.PlexusContainer.hasChildContainer(Ljava/lang/String;)Z
This can be corrected by changing the coordinates of the Groovy Maven plugin to:              
<groupId>org.codehaus.mojo</groupId>
<artifactId>groovy-maven-plugin</artifactId>
<version>1.3</version>

Error:  Failed to execute goal org.codehaus.mojo:groovy-maven-plugin:1.3:testCompile ... Unknown type: METHOD_DEF
This can be caused by anonymous inner classes in the code.  Groovy for Java Programmers gives some suggestions for how to re-format your code so that Groovy can properly parse it and recognize an anonymous inner class definition, however these suggestions didn't work for me.  Anonymous inner class are a convenience so one can re-write the code to eliminate them.

Error:  initializationError(...): [Lorg/codehaus/groovy/runtime/callsite/CallSite;
You may only see one line in the Maven output which is not particularly helpful.  However, you can look at the detailed test output.  In Hudson, it would be at a location under HUDSON_HOME similar to jobs\<your job>\workspace\target\surefire-reports\  Looking here, you may see an error java.lang.NoClassDefFoundError: [Lorg/codehaus/groovy/runtime/callsite/CallSite;
To fix this, update your Groovy Maven run-time coordinates to:

<groupId>org.codehaus.groovy.maven.runtime</groupId>
<artifactId>gmaven-runtime-1.6</artifactId>
<version>1.0</version>
<scope>test</scope>

After all this, you should finally see your Groovy test executed in the Maven output.

Maven install:install-file output is misleading?

Using Apache Maven 3.0.3 (r1075438), Maven will report "BUILD SUCCESS" even when the file argument points to a non-existent file (e.g. mvn install:install-file -Dfile=C:\temp\jmockit.jar ...).  Naturally, this can lead to some confusion when your source code still refuses to compile.

Maven project has errors in Eclipse (no changes were made)

Possible fixes:

1. More common:  If Project > Build Automatically is checked off, do a Project > Clean on the problematic project.  Usually this fixes the issue.
2. If compile errors persist, especially indicating dependencies that should be resolved by Maven, Project > Update All Maven Dependencies.  This may be needed if the local repository was moved; Eclipse may need to be refreshed of this.  
• Speaking of which, after moving the Maven local repository, simply update the path in the settings.xml file in the .m2 directory in your home directory (e.g. C:\Documents and Settings\alan.leung\.m2 or ~/.m2 on *nix)

Unable to find resource 'xxxxxxxxxxxx:xxxxx:maven-plugin:x.x.x' in repository central

Although one may think to correct this by adding a <repository> specification in the POM file, a closer look at the error messages, including "A required plugin was not found: Plugin could not be found - check that the goal name is correct: Unable to download the artifact from any repository" may give another clue.  For plugins, a <pluginRepository> specification is required.

Deploy to own Maven repository using SSH

• Maven command:  mvn deploy:deploy-file -DgroupId=<groupId> -DartifactId=<artifactId> -Dversion=<version> -Dpackaging=<e.g. jar or war, etc.> -Dfile=<path to file>-Durl=<e.g. scpexe://your hostname/full file system path to repo on server> -DrepositoryId=<id of repo in settings.xml>
• References:  Deployment of artifacts in an external SSH command and Deploy Plugin

Strategies to creating a new web application project

A seemingly trivial task, starting a new web app project in Eclipse, requires specific steps when working with an assortment of technologies like Maven and Subversion.

1. File > New > Other > Dynamic Web Project 
2. To conform with Maven's WAR project structure, in the following dialog, specify /src/main/webapp for the Content Directory:

3. Once the project is created, right-click on project > Maven > Enable Dependency Management. 
4. The project can be associated with a pre-existing Subversion folder by Team > Share Project and on this dialog, enter the path of the Subversion folder at "Use specified folder name":
 
5. I might have been on crack when I performed the steps below ... they are not necessary and are retained only for reference purposes:
   
6. If you generally set-up a project in Subversion with the typical folders of branches, tags, trunk, create these first and then with Subclipse check-out the trunk as your working copy (change the project name from trunk to something appropriate).  If you start your project in Eclipse and then attempt to Team > Share Project, Eclipse dialogs seem to force you to create a new Subversion location under trunk rather than committing to trunk directly
7. Create Maven web app project, commit, re-check-out using Eclipse New Project Wizard 
1. Use a Maven archetype to create the skeleton of your web app project in the SVN working copy.  You can do this from the command-line (refresh workspace once done) or using m2eclipse via File > New > Other > Maven project.  However this step does not create an Eclipse project that is recognized by WTP's Tomcat
2. Commit Maven project
3. Then delete project from workspace including contents on disk (this is OK since everything is already committed to Subversion)
4. Re-check-out using Eclipse's New Project Wizard, choosing Dynamic Web Project for the wizard type.  Along the way, there is a dialog box that asks for "Content directory":  From here you cannot specify the webapp directory in Maven's specific structure so just ignore for now
5. Once the project is checked-out, edit the file .settings/org.eclipse.wst.common.component.xml  There is a line that will probably read <wb-resource deploy-path="/" source-path="/WebContent"/>.  Change that to <wb-resource deploy-path="/" source-path="/src/main/webapp"/>
6. Your project should now be Add-able to WTP's Tomcat and content in /src/main/webapp should be viewable in the web browser