Recent Changes - Search:

CONGO

PmWiki

edit SideBar

V2 /

BuildWithMaven

V2.BuildWithMaven History

Hide minor edits - Show changes to output

Changed line 18 from:
* Make sure you have an /opt/congo/congo/congo.properties file with the basics:
to:
* Make sure you have an /opt/congo/congo/congo.properties file with the basics:\\
Changed lines 18-19 from:
* Make sure you have an /opt/congo/congo/congo.properties file with the basics:\\
 
database.autoupgrade=true
to:
* Make sure you have an /opt/congo/congo/congo.properties file with the basics:
[@database.autoupgrade=true
Changed line 24 from:
 database.user=blah
to:
 database.user=blah@]
Changed line 18 from:
* Make sure you have an /opt/congo/congo/congo.properties file with the basics:
to:
* Make sure you have an /opt/congo/congo/congo.properties file with the basics:\\
Added lines 18-24:
* Make sure you have an /opt/congo/congo/congo.properties file with the basics:
 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
Added lines 29-31:

Alternate webrunner-invoked instance:
* java -Dpropertiesfile=someotherpropertyfile  -Dcongo.jdbcurl=jdbc:mysql://localhost/yoinksandaway -jar target/dependency/webapp-runner.jar target/*.war
Deleted lines 26-27:

Changed line 34 from:
* Use http://hudson.stonekeep.com/.
to:
* See [[Releases]]
Added lines 22-27:

Troubleshooting
* Under OSX, you need to directly specify which JVM version to use:\\
 export JAVA_VERSION=1.6

Added lines 29-31:
Releases:
* Use http://hudson.stonekeep.com/.

Deleted line 116:
* There are no @@<distributionManagement>@@ or @@<scm>@@ sections in the POM, which limits the amount of automation available. With both of those, it's possible to run a release process that mostly Works using just Maven, with very little manual intervention beyond picking version numbers and SCM tags.
Changed line 11 from:
** svn checkout http://svn.stonekeep.com/svn/congo/branches/congo-2.0.0.2 
to:
** svn checkout http://svn.stonekeep.com/svn/congo/v2/trunk
Added lines 23-24:
Alternate procedure to generate  a snapshot war:
* mvn clean org.mortbay.jetty:maven-jetty-plugin:run-war
Changed lines 16-17 from:
dbs@shell:~/work/congo-2.0.0.2/target$ ls -l *.war\\
-rw-r--r-- 1 dbs dbs 10604224 Jul 10 01:27 congo-2.0.0.2-SNAPSHOT.war\\
to:
 dbs@shell:~/work/congo-2.0.0.2/target$ ls -l *.war\\
-rw-r--r-- 1 dbs dbs 10604224 Jul 10 01:27 congo-2.0.0.2-SNAPSHOT.war
Changed lines 19-22 from:
mvn org.mortbay.jetty:maven-jetty-plugin:run
to:
 mvn org.mortbay.jetty:maven-jetty-plugin:run
* (optionally) - a good thing to do is to supply a 'clean' target as well - that makes sure everything is really built from scratch:\\
 mvn org.mortbay.jetty:maven-jetty-plugin:run

Added lines 23-26:

----
'''Anything below this is from previous work on the build / dev process.  Use with caution.'''
----
Added lines 20-22:

CONGO2 under eclipse (''work in progress'')
* for local use, replace 'mvn install' with 'mvn eclipse:eclipse; mvn install' for local, and set up eclipse
Added lines 18-19:
* Start up a jetty instance, running the new war file:\\
mvn org.mortbay.jetty:maven-jetty-plugin:run
Changed lines 16-17 from:
 dbs@shell:~/work/congo-2.0.0.2/target$ ls -l *.war
 -rw-r--r-- 1 dbs dbs 10604224 Jul 10 01:27 congo-2.0.0.2-SNAPSHOT.war
to:
dbs@shell:~/work/congo-2.0.0.2/target$ ls -l *.war\\
-rw-r--r-- 1 dbs dbs 10604224 Jul 10 01:27 congo-2.0.0.2-SNAPSHOT.war\\
Added lines 15-18:
* If all goes well, you'll have a clean compile.  The built war file is in the ./target/ subdir:\\
 dbs@shell:~/work/congo-2.0.0.2/target$ ls -l *.war
 -rw-r--r-- 1 dbs dbs 10604224 Jul 10 01:27 congo-2.0.0.2-SNAPSHOT.war

Deleted lines 9-10:
* Tell Maven to pull down the initial .m2 repository :
** mvn install (note this takes a while)
Changed lines 12-14 from:
* cd to the congo top level dir
to:
* cd to the CONGO top level dir
* Tell Maven to rebuild the entire CONGO environment, including all dependencies:
** mvn install (note this takes a while)
Added lines 10-11:
* Tell Maven to pull down the initial .m2 repository :
** mvn install (note this takes a while)
Changed lines 10-11 from:
* Check out a working copy of CONGO:
**
  svn checkout http://svn.stonekeep.com/svn/congo/trunk
to:
* Check out a working copy of CONGO (this is the URL as of 7/9/2009) :
**
svn checkout http://svn.stonekeep.com/svn/congo/branches/congo-2.0.0.2 
Added lines 7-9:
* Create a working development directory (i usually use 'work')
* Download Maven from http://maven.apache.org/ and unpack it as a subdirectory of 'work'
* Add the maven/bin/ dir to your path
Changed lines 1-3 from:
!Building CONGO 2 with Maven

!!I just want to build CONGO!
to:
!!CONGO + Maven quick start
Changed lines 9-10 from:
* Check out a working copy of CONGO (see whateverthelinkisforSVNaccess)
to:
* Check out a working copy of CONGO:
**
  svn checkout http://svn.stonekeep.com/svn/congo/trunk
Changed lines 6-9 from:
* Prerequisites:
** A working JDK
** Command line access

to:
Added line 8:
* Make sure you have all the DeveloperRequirements in place.
Added lines 4-12:

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:
* Prerequisites:
** A working JDK
** Command line access

Procedure:
* Check out a working copy of CONGO (see whateverthelinkisforSVNaccess)
* cd to the congo top level dir
September 27, 2008, at 09:20 PM by ojacobson - Removed done TODO
Deleted lines 84-85:
* @@maven-eclipse-plugin@@, the plugin responsible for generating Eclipse projects from Maven configurations, can generate WTP configuration along with the rest of the project config, eliminating the need to store IDE-specific configuration in the source repository. I think this is a large win and would like to migrate, as it makes the build much more IDE-agnostic.
** This has been done, needs docco on this page or on MavenWithEclipse or something.
September 27, 2008, at 08:20 PM by ojacobson - "JSPs" is not a wiki link
Changed lines 68-69 from:
* @@src/main/webapp@@ is the root of the WAR structure and holds JSPs as well as the @@WEB-INF/web.xml@@ descriptor.
to:
* @@src/main/webapp@@ is the root of the WAR structure and holds [=JSPs=] as well as the @@WEB-INF/web.xml@@ descriptor.
September 27, 2008, at 08:11 PM by ojacobson - How to run - Tomcat and Jetty versions.
Added lines 7-63:
!!!Running CONGO 2 under Tomcat, from Maven

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 [[http://mojo.codehaus.org/tomcat-maven-plugin/plugin-info.html|plugin documentation]] for @@maven-tomcat-plugin@@.

!!!Running CONGO under Jetty

Run @@mvn jetty:run@@.  When you're done testing, interrupt the build with Ctrl-C to shut down Jetty.

!!I want to understand what I'm doing!

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. 

Deleted lines 69-72:
!!I want to understand what I'm doing!

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.  In the case of CONGO, the output is a WAR file (congo-VERSION.war).

September 27, 2008, at 04:06 PM by ojacobson - Some preliminary doc cleanup for latest build updates.
Changed lines 7-8 from:
The CONGO POM specifies that the result of the build is a WAR file, that the Java source is stored in the @@src/@@ directory, and that the non-Java resources that go into the webapp are in @@[=WebContent=]/@@.  It also excludes some areas that are only relevant for Eclipse WTP builds, including @@[=WebContent=]/WEB-INF/lib@@ area (the WAR's @@lib@@ is populated by Maven's dependency resolution, instead) and @@[=WebContent=]/META-INF@@ (the manifest is generated by the WAR plugin when it builds the webapp, instead).
to:
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.
Changed lines 15-16 from:
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.  In the case of CONGO, the output is a WAR file (congo-VERSION.war) built from the @@src/@@ and @@[=WebContent=]/@@ directories.
to:
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.  In the case of CONGO, the output is a WAR file (congo-VERSION.war).
Deleted line 31:
* Migrating the source to Maven's "stock" layout will make it much easier to use random other plugins with the build without configuring each one to be aware of the unusual source and resource paths.  I'm thinking particularly of mortbay.org's Jetty plugin, which (for well-written webapps) can be used to run the app straight out of the build directory in Jetty.
Added line 33:
** This has been done, needs docco on this page or on MavenWithEclipse or something.
September 15, 2008, at 03:03 AM by ojacobson - Revised the way maven is introduced.
Changed lines 11-19 from:
Maven describes projects in terms of the artifacts they produce, not the steps involved in getting there.  In the case of CONGO, the output is a WAR file (congo-VERSION.war) built from the @@src/@@ and @@[=WebContent=]/@@ directories. Maven defines a set of standard pahses (build steps), any of which will automatically trigger all the preceeding phases.  Internally, phases are associated with goals provided by various pluginsThere are two important lifecycles:

* The @@clean@@ lifecycle, which has one useful phase
(also called @@clean@@), which is intended to remove all the files created during a build from the work area. The standard configuration does this by deleting the @@target/@@ directory.
* The @@default@@ lifecycle, which is intended to convert 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@@, which compiles code in the source tree and produces classfiles.
**
@@test@@, which runs unit tests (and indirectly causes them to be compiled).
** @@package@@, which bundles up the compiled code and resources into the final artifact
.
** @@install@@, which copies the final artifact to a local repository in @@~/.m2/repository/@@, making it available to other builds run on the same machine.
** @@deploy@@, which copies the final artifact to a '''remote''' repository, making it available to builds run on other machines.
to:
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 buildIn the case of CONGO, the output is a WAR file (congo-VERSION.war) built from the @@src/@@ and @@[=WebContent=]/@@ directories.

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):

* The @@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@@).
* The @@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.
Deleted lines 25-26:
The build behaviour is specified in an XML configuration file at the root of a project named @@pom.xml@@, which specifies the human-readable and maven-readable names of the project, its version number, the type of artifact produced, any dependencies required for the project to be built, and any special plugin configurations needed for the build.
September 15, 2008, at 02:47 AM by ojacobson - Revised the exposition of default build phases.
Changed lines 14-17 from:
* The @@default@@ lifecycle, which has a number of useful phases (below), which is intended to convert the source tree into a single result artifact and, optionally, make that artifact available to other builds (locally or globally).

The most relevant phases in the @@default@@ lifecycle are the
@@'''compile'''@@, @@'''test'''@@, @@'''package'''@@, @@'''install'''@@, and @@'''deploy'''@@ phases (which occur in that order: running @@mvn deploy@@ will also run the @@compile@@, @@test@@, @@package@@, and @@install@@ phases).  Each phase does roughly what it says on the tin, with the exception of the @@install@@ phase (which copies the resulting artifact from the build directory to your local maven repository - a special area in @@~/.m2/repository/@@ by default where artifacts can be found by other builds running on the same system) and the @@deploy@@ phase (which copies the resulting artifact to a '''remote''' repository, making it available to builds running on other systems).
to:
* The @@default@@ lifecycle, which is intended to convert 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@@, which compiles code in the source tree and produces classfiles.
**
@@test@@, which runs unit tests (and indirectly causes them to be compiled).
**
@@package@@, which bundles up the compiled code and resources into the final artifact.
** @@install@@, which copies the final artifact to a local repository in
@@~/.m2/repository/@@, making it available to other builds run on the same machine.
** @@deploy@@, which copies the final artifact to
a '''remote''' repository, making it available to builds run on other machines.
->Each of these phases triggers
the preceeding phases: @@mvn deploy@@ will compile, test, package, and install the project as well.
September 15, 2008, at 02:39 AM by ojacobson - That should've been one list, not two.
Deleted line 13:
September 15, 2008, at 12:29 AM by ojacobson - Diction, justification.
Changed line 26 from:
* The maven-war-plugin and maven-eclipse-plugins can generate WTP configuration along with the rest of the eclipse project config (as @@mvn eclipse:eclipse@@), eliminating the need to store IDE-specific configuration in the source repository. I think this is a large win and would like to migrate.
to:
* @@maven-eclipse-plugin@@, the plugin responsible for generating Eclipse projects from Maven configurations, can generate WTP configuration along with the rest of the project config, eliminating the need to store IDE-specific configuration in the source repository. I think this is a large win and would like to migrate, as it makes the build much more IDE-agnostic.
September 15, 2008, at 12:25 AM by ojacobson - Minor diction issues.
Changed lines 7-8 from:
The CONGO POM specifies that the result of the build is a WAR file, that the Java source is stored in the @@src/@@ directory, and that the non-Java resources that go into the webapp are in @@[=WebContent=]/@@.  It also excludes some areas that are relevant for Eclipse WTP builds, including @@WEB-INF/lib@@ area (populated by Maven's dependency resolution, instead) and @@META-INF@@ (populated by the WAR plugin when it builds the webapp).
to:
The CONGO POM specifies that the result of the build is a WAR file, that the Java source is stored in the @@src/@@ directory, and that the non-Java resources that go into the webapp are in @@[=WebContent=]/@@.  It also excludes some areas that are only relevant for Eclipse WTP builds, including @@[=WebContent=]/WEB-INF/lib@@ area (the WAR's @@lib@@ is populated by Maven's dependency resolution, instead) and @@[=WebContent=]/META-INF@@ (the manifest is generated by the WAR plugin when it builds the webapp, instead).
September 15, 2008, at 12:13 AM by ojacobson - De-wikified a few things that shouldn't be links
Changed lines 7-8 from:
The CONGO POM specifies that the result of the build is a WAR file, that the Java source is stored in the @@src/@@ directory, and that the non-Java resources that go into the webapp are in @@WebContent/@@.  It also excludes some areas that are relevant for Eclipse WTP builds, including @@WEB-INF/lib@@ area (populated by Maven's dependency resolution, instead) and @@META-INF@@ (populated by the WAR plugin when it builds the webapp).
to:
The CONGO POM specifies that the result of the build is a WAR file, that the Java source is stored in the @@src/@@ directory, and that the non-Java resources that go into the webapp are in @@[=WebContent=]/@@.  It also excludes some areas that are relevant for Eclipse WTP builds, including @@WEB-INF/lib@@ area (populated by Maven's dependency resolution, instead) and @@META-INF@@ (populated by the WAR plugin when it builds the webapp).
Changed lines 11-12 from:
Maven describes projects in terms of the artifacts they produce, not the steps involved in getting there.  In the case of CONGO, the output is a WAR file (congo-VERSION.war) built from the @@src/@@ and @@WebContent/@@ directories. Maven defines a set of standard pahses (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:
to:
Maven describes projects in terms of the artifacts they produce, not the steps involved in getting there.  In the case of CONGO, the output is a WAR file (congo-VERSION.war) built from the @@src/@@ and @@[=WebContent=]/@@ directories. Maven defines a set of standard pahses (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:
Changed lines 23-24 from:
!!TODOs for the build
to:
!![=TODOs=] for the build
Changed line 28 from:
* One of the stated goals for CONGO is to be able to ship WAR templates or pre-built WARs without exposing the source code.  It may be worthwhile to break the build down into a JAR phase, which builds the Java pieces, and a WAR phase, which stitches the resulting JAR from the JAR phase into the WAR, rather than compiling source directly during the WAR build.
to:
* One of the stated goals for CONGO is to be able to ship WAR templates or pre-built [=WARs=] without exposing the source code.  It may be worthwhile to break the build down into a JAR phase, which builds the Java pieces, and a WAR phase, which stitches the resulting JAR from the JAR phase into the WAR, rather than compiling source directly during the WAR build.
September 15, 2008, at 12:10 AM by ojacobson - Added note about WTP and the eclipse plugin.
Added line 26:
* The maven-war-plugin and maven-eclipse-plugins can generate WTP configuration along with the rest of the eclipse project config (as @@mvn eclipse:eclipse@@), eliminating the need to store IDE-specific configuration in the source repository. I think this is a large win and would like to migrate.
September 14, 2008, at 10:17 PM by ojacobson - Summarized the maven build system
Added lines 1-28:
!Building CONGO 2 with Maven

!!I just want to build CONGO!

Quick start: run @@mvn package@@ and pull the resulting WAR file from @@target/congo-VERSION.war@@.

The CONGO POM specifies that the result of the build is a WAR file, that the Java source is stored in the @@src/@@ directory, and that the non-Java resources that go into the webapp are in @@WebContent/@@.  It also excludes some areas that are relevant for Eclipse WTP builds, including @@WEB-INF/lib@@ area (populated by Maven's dependency resolution, instead) and @@META-INF@@ (populated by the WAR plugin when it builds the webapp).

!!I want to understand what I'm doing!

Maven describes projects in terms of the artifacts they produce, not the steps involved in getting there.  In the case of CONGO, the output is a WAR file (congo-VERSION.war) built from the @@src/@@ and @@WebContent/@@ directories. Maven defines a set of standard pahses (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:

* The @@clean@@ lifecycle, which has one useful phase (also called @@clean@@), which is intended to remove all the files created during a build from the work area. The standard configuration does this by deleting the @@target/@@ directory.

* The @@default@@ lifecycle, which has a number of useful phases (below), which is intended to convert the source tree into a single result artifact and, optionally, make that artifact available to other builds (locally or globally).

The most relevant phases in the @@default@@ lifecycle are the @@'''compile'''@@, @@'''test'''@@, @@'''package'''@@, @@'''install'''@@, and @@'''deploy'''@@ phases (which occur in that order: running @@mvn deploy@@ will also run the @@compile@@, @@test@@, @@package@@, and @@install@@ phases).  Each phase does roughly what it says on the tin, with the exception of the @@install@@ phase (which copies the resulting artifact from the build directory to your local maven repository - a special area in @@~/.m2/repository/@@ by default where artifacts can be found by other builds running on the same system) and the @@deploy@@ phase (which copies the resulting artifact to a '''remote''' repository, making it available to builds running on other systems).

Lifecycle phases are run using the @@mvn ''phase'' [''phase'' ''phase'' ...]@@ command. You can also run specific plugin goals directly, using @@mvn ''pluginname'':''goalname''@@.

The build behaviour is specified in an XML configuration file at the root of a project named @@pom.xml@@, which specifies the human-readable and maven-readable names of the project, its version number, the type of artifact produced, any dependencies required for the project to be built, and any special plugin configurations needed for the build.

!!TODOs for the build

* Migrating the source to Maven's "stock" layout will make it much easier to use random other plugins with the build without configuring each one to be aware of the unusual source and resource paths.  I'm thinking particularly of mortbay.org's Jetty plugin, which (for well-written webapps) can be used to run the app straight out of the build directory in Jetty.
* There are no @@<distributionManagement>@@ or @@<scm>@@ sections in the POM, which limits the amount of automation available. With both of those, it's possible to run a release process that mostly Works using just Maven, with very little manual intervention beyond picking version numbers and SCM tags.
* One of the stated goals for CONGO is to be able to ship WAR templates or pre-built WARs without exposing the source code.  It may be worthwhile to break the build down into a JAR phase, which builds the Java pieces, and a WAR phase, which stitches the resulting JAR from the JAR phase into the WAR, rather than compiling source directly during the WAR build.
* Solve world hunger.
Edit - History - Print - Recent Changes - Search
Page last modified on January 16, 2017, at 07:05 PM