Nexus system administration misunderstanding

The available repositories that can be added to the Group ("Public Repositories") is on the right (see below).  Intuitively, shouldn't they be on the left, and you move them over to the right?  By default, newly added Repositories show up in the right column ("Available Repositories").

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>

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.