If you're setting up a virgin command line environment and want to just check CONGO out of SVN, and build a war file, do these steps:
Procedure:
database.autoupgrade=true database.host=eventjdatastore.ck6kx2auo1hd.us-east-1.rds.amazonaws.com database.name=blah database.password=blah database.type=mysql database.user=blah
Troubleshooting
Alternate procedure to generate a snapshot war:
Alternate webrunner-invoked instance:
CONGO2? under eclipse (work in progress)
Releases:
Anything below this is from previous work on the build / dev process. Use with caution.
Quick start: run mvn package and pull the resulting WAR file from target/congo-VERSION.war.
If you have a running Tomcat installation on your local machine, you can use maven to immediately deploy the created WAR to it. Add the following to ~/.m2/settings.xml:
<settings>
<!-- ... -->
<servers>
<!-- ... -->
<server>
<id>congo.tomcat</id>
<username>manager</username>
<password>manager</password>
</server>
</servers>
<!-- ... -->
<profiles>
<!-- ... -->
<profile>
<id>congo</id>
<properties>
<!-- Use the 'congo.tomcat' credentials for maven-tomcat-plugin -->
<maven.tomcat.server>congo.tomcat</maven.tomcat.server>
<!-- Redeploy if tomcat:deploy runs when the app is already deployed. -->
<maven.tomcat.update>true</maven.tomcat.update>
</properties>
</profile>
</profiles>
<activeProfiles>
<!-- ... -->
<activeProfile>congo</activeProfile>
</activeProfiles>
<!-- ... -->
</settings>
(Replace the username and password with credentials that have access to Tomcat's /manager application, as appropriate.)
Then run mvn tomcat:deploy to deploy CONGO, or mvn tomcat:undeploy to remove CONGO from Tomcat.
For more information, see the plugin documentation for maven-tomcat-plugin.
Run mvn jetty:run. When you're done testing, interrupt the build with Ctrl-C to shut down Jetty.
Maven describes projects in terms of the artifacts they produce, not the steps involved in getting there. The build behaviour is specified in an XML configuration file at the root of the project named pom.xml, which contains the human-readable and maven-readable names of the project, its version number, the type of artifact being built, any dependencies for the project, and any special plugin configurations needed for the build.
The CONGO POM specifies that the result of the build is a WAR file, with the source, resources, and web content laid out in Maven's standard build structure:
src/main/resources is the package root for non-compiled source files, like Struts config files.
src/main/java is the package root for Java source files.
src/main/webapp is the root of the WAR structure and holds JSPs as well as the WEB-INF/web.xml descriptor.
Maven defines a set of standard phases (build steps), any of which will automatically trigger all the preceeding phases. Internally, phases are associated with goals provided by various plugins. There are two important lifecycles (lists of phases):
clean lifecycle removes all files created during the build. The standard configuration does this by deleting the target/ directory. It has one useful phase (also called clean).
default lifecycle builds the source tree into a single result artifact and, optionally, make that artifact available to other builds (locally or globally). It has several useful phases:
compile compiles code in the source tree and produces classfiles.
test runs unit tests (and indirectly causes them to be compiled).
package bundles up the compiled code and resources into the final artifact.
install copies the final artifact to a local repository in ~/.m2/repository/, making it available to other builds run on the same machine.
deploy copies the final artifact to a remote repository, making it available to builds run on other machines.
mvn deploy will compile, test, package, and install the project as well.
Lifecycle phases are run using the mvn phase [phase phase ...] command. You can also run specific plugin goals directly, using mvn pluginname:goalname.