Merge branch 'rel_2.2-RC3' into rel_2.2.x

data/release/workspaces/topp/taz_shapes/tasmania_cities/featuretype.xml

@@ -20,10 +20,10 @@
   AXIS[&quot;Latitude&quot;, NORTH]]</nativeCRS>
   <srs>EPSG:4326</srs>
   <nativeBoundingBox>
-    <minx>147.2910004483</minx>
-    <maxx>147.2910004483</maxx>
-    <miny>-42.851001816890005</miny>
-    <maxy>-42.851001816890005</maxy>
+    <minx>145.19754</minx>
+    <maxx>148.27298000000002</maxx>
+    <miny>-43.423512</miny>
+    <maxy>-40.852802</maxy>
     <crs>EPSG:4326</crs>
   </nativeBoundingBox>
   <latLonBoundingBox>
@@ -85,4 +85,4 @@
   </attributes>
   <maxFeatures>0</maxFeatures>
   <numDecimals>0</numDecimals>
-</featureType>
+</featureType>

doc/en/developer/source/conf.py

@@ -47,7 +47,7 @@
 # The short X.Y version.
 version = '2.2'
 # The full version, including alpha/beta/rc tags.
-release = '2.2-RC2'
+release = '2.2-RC3'
 # Users don't need to see the "SNAPSHOT" notation when it's there
 if release.find('SNAPSHOT') != -1:
    release = '2.2.x'

doc/en/developer/source/index.rst

@@ -14,6 +14,7 @@ Welcome to the GeoServer Developer Manual.  The manual is for those who want to
    eclipse-guide/index
    findbugs-guide/index
    programming-guide/index
+   release-schedule/index
    release-guide/index
    release-testing-checklist/index
    cite-test-guide/index

doc/en/developer/source/policies/community-modules.rst

@@ -119,7 +119,7 @@ The following outlines the steps to be taken in order to add a new community mod
              </profile>
            </profiles>
 
-   #. Edit ``web/pom.xml`` and add the following inside of the ``<profiles>``
+   #. Edit ``web/app/pom.xml`` and add the following inside of the ``<profiles>``
       element:
 
       .. code-block:: xml
@@ -250,7 +250,7 @@ Process
               <module>myCommunityModule</module>
             </modules>
 
-     #. Edit ``web/pom.xml`` and move the dependency on the community module 
+     #. Edit ``web/app/pom.xml`` and move the dependency on the community module 
         into the main dependencies section of the pom. Then remove the profile
 
    *Extensions*

doc/en/developer/source/release-schedule/index.rst

@@ -0,0 +1,136 @@
+.. _time_boxed_releases:
+
+Release Schedule
+================
+
+Starting with version 2.2 GeoServer releases follow a time boxed model in which releases occur 
+at regular predictable frequencies rather than at ad-hoc dates. In a time boxed the software is 
+released at predictable frequencies with whatever fixes, improvements, and feature are available
+at the time of release. This differs from the previous feature based model in which releases occur 
+when a certain number of key features have accumulated.
+
+To compensate for the inherent unpredictability of the release contents the model includes strict 
+rules about what type of development is appropriate during specific periods of a branches life 
+cycle. These rules include a suitably long hardening period for the unstable branch to mature and
+eventually become stable.
+
+Release branches
+----------------
+
+At any given time GeoServer is undergoing two to three main branches of development.
+
+#. The *stable* branch in which only bug fixing, and smaller scale feature development occurs on
+#. The *unstable* (master) branch in which more experimental and larger scale feature development occurs
+#. The *maintenance* branch which was the previously stable branch that is nearing end of life and sees
+   only the most stable development, typically mostly bug fixes.
+
+Release cycle
+-------------
+
+On the stable branches release follow a monthly cycle in a which a new minor release occurs once a 
+month. On the unstable branch releases follow a 6 month cycle in which a new major release occurs
+once every 6 months. The following diagram illustrates the cycle:
+
+.. image:: timeboxed.png 
+
+Things to note:
+
+* monthly releases on the stable branch
+* a four month open development period followed by two months hardening period on the unstable branch
+* beta releases are supposed to be released out of the unstable series on a monthly basis
+  across the switch between open development and hardening, followed by the first release candidate
+* release candidates are pushed out every two weeks until we reach a stable code base, which will be released
+  as the new major stable release
+* the first release candidate marks the branch off of a new trunk, on which open development starts again
+
+The time of the first release candidate marks the origin of a new stable branch in which the unstable branch 
+becomes the stable branch, and the stable branches becomes a maintenance branch.
+
+Every month, on the same day, a new release is issued from the stable branch using whatever revision of
+GeoServer/Geotools passed the last CITE tests. The release is meant to improve upon the previous release in 
+both functionality and stability, so unless the project steering committee determines reasons to block the release 
+it will happen regardless of what bug reports are in Jira. Pending resourcing, they can be fixed in the next release 
+that comes out one month later.
+
+At any given point in time there are two branches under the development, the stable branch and the master/unstable
+branch. Once every six months when the creation of a new stable branch occurs a third active maintenance branch 
+is created. This branch is kept up to date with the stable stable for a period of one-month after which the final
+release on that branch is created. That said there is nothing against a developer continuing to maintain the branch
+or creating release from it, it is just not expected.
+
+Development phases
+------------------
+
+The type of development that can occur on a branch is dictated by where the branch is in terms of its life cycle.
+
+Stable branch
+`````````````
+
+The type of acceptable development on the stable branch does not change much over its lifetime. It is meant 
+for bug fixes and new features that do not affect the GeoServer API or significantly affect the stability.
+A PSC vote (with eventual proposal) can be called in case a significant new feature or change needs 
+to be back ported to the stable branch overriding the above rules.
+
+If, for any reason, a release is delayed the next release will be rescheduled 30 days after the last release
+(that is, delaying the whole train of remaining releases).
+
+Unstable branch
+```````````````
+
+The type of development on the master/unstable branch changes over its lifetime from four months of open
+development to two months of stable/hardening development.
+
+Open development phase
+``````````````````````
+
+The open development phase starts when the new stable release is branched off, and ends when hardening
+starts, four months after the new stable release is made.
+
+During this phase developers are free to commit stability undermining changes (even significant ones). 
+Those changes still need to be voted as GSIP anyways to ensure, as usual, resourcing checks, API consistency 
+and community review.
+
+After three months from the release of the stable series a first beta will be released, 
+one month after that the second beta will be released and the branch will switch into hardening mode.
+
+Hardening phase
+```````````````
+
+The hardening phase starts when the second beta is released and continues through all release candidate (RC)
+releases. The first RC is released one month after the second beta, and then bi-weekly releases
+will be issued until no major issues will be reported by the user base, at which point the last RC
+will be turned into the new stable release.
+
+During hardening only bug-fixes and new non core plugins can be developed
+
+Commit rules
+------------
+
+The following are guidelines as to what types of commits can occur in any particular phase. While the PSC 
+reserves the right to vote and override the committing guidelines the following rules reflect the 
+current policies.
+
+The **hardening phase**, and by extension the stable and open phases, can receive any of the following 
+types of commits:
+
+* bug fixes
+* documentation improvements
+* new plugins contributed as community or extension modules (with a cautionary note that during 
+  hardening the attention should be concentrated as much as possible on getting the new release stable)
+
+In addition the **stable phase** can receive any of the following types of commits:
+
+* new minor core functionality (e.g. new output format)
+* new API that we can commit to for a long period of time (provided it's not a change to existing API unless the PSC votes otherwise). 
+  GeoServer is not a library, so defining API can be hard, but any class that can be used by pluggable 
+  extension points should be changed with care, especially so in a stable series
+
+In addition to the above the **stable phase** can receive the following types of changes provided there are no 
+reservations or concerns about them from the PSC. Such changes may be subject to voting:
+
+* promotion of extensions to core
+* core changes that are unlikely to affect the stability of the upcoming release 
+  (if the PSC is ok better land them right after a release to get as a large window for testing as possible)
+* back port of larger changes that have proven to be working well on trunk for an extended period of time
+
+During the **open development phase** all types of commits are fair game but of course large changes are still subject to proposals and reviews.

doc/en/docguide/source/conf.py

@@ -47,7 +47,7 @@
 # The short X.Y version.
 version = '2.2'
 # The full version, including alpha/beta/rc tags.
-release = '2.2-RC2'
+release = '2.2-RC3'
 # Users don't need to see the "SNAPSHOT" notation when it's there
 if release.find('SNAPSHOT') != -1:
    release = '2.2.x'

doc/en/themes/geoserver/static/default.css

@@ -359,6 +359,7 @@ border-bottom: 0 none transparent;
 
 #content img {
 margin-bottom: 10px;
+max-width:99%;
 }
 
 #content .figure img {

doc/en/user/source/community/index.rst

@@ -16,7 +16,6 @@ officially part of the GeoServer releases. They are however built along with the
    :maxdepth: 1 
 
    authkey/index
-   controlflow/index
    css/index
    dxf/index
    dds/index

doc/en/user/source/community/monitoring/configuration.rst

@@ -69,18 +69,34 @@ Monitor Database
 
 By default monitored request data is stored in an embedded H2 database located
 in the ``monitoring`` directory. This can be changed by editing the 
-``db.properties`` file::
+``db.properties`` and ``hibernate.properties`` file::
 
    # default configuration is for h2 
    driver=org.h2.Driver
    url=jdbc:h2:file:${GEOSERVER_DATA_DIR}/monitoring/monitoring
 
-For example to store request data in an external PostgreSQL database::
+For example to store request data in an external PostgreSQL database, set ``db.properties`` to::
 
    driver=org.postgresql.Driver 
    url=jdbc:postgresql://192.168.1.124:5432/monitoring
    username=bob
    password=foobar
+
+and ``hibernate.properties`` to::
+
+   hibernate.use_sql_comments=true
+   databasePlatform=org.hibernate.dialect.PostgreSQLDialect
+   generateDdl=true
+   hibernate.format_sql=true
+   showSql=false
+   hibernate.generate_statistics=true
+   hibernate.session_factory_name=SessionFactory
+   hibernate.hbm2ddl.auto=update
+   hibernate.bytecode.use_reflection_optimizer=true
+   database=POSTGRESQL
+   hibernate.show_sql=false
+
+The maximum size of the request body that is logged is set in the ``monitor.properties`` and ``mappings.hbm.xml`` files. If the setting in ``monitor.properties`` is higher than that in ``mappings.hbm.xml`` any long requests will fail to be logged entirely.  You can set it to be unbounded if your database supports it.
 
 Request Filters
 ---------------

doc/en/user/source/community/monitoring/http.rst

@@ -25,6 +25,21 @@ Request information can be returned in CSV format, for easier post-processing::
 
   GET http://localhost:8080/geoserver/rest/monitor/requests.csv
 
+Request bodies containing newlines are handled with quoted text.  If your CSV reader doesn't handle quoted newlines, it will not work correctly.
+
+All requests as PKZip
+^^^^^^^^^^^^^^^^^^^^^
+A PKZip archive containing the CSV file above, with all the request bodies and errors as separate files::
+
+  GET http://localhost:8080/geoserver/rest/monitor/requests.zip
+
+All requests as MS Excel
+^^^^^^^^^^^^^^^^^^^^^^^^
+A Microsoft Excel spreadsheet containing the same information as the CSV file::
+
+  GET http://localhost:8080/geoserver/rest/monitor/requests.xls
+
+
 Requests during a time period
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 Requests can be filtered by date and time range::
@@ -66,6 +81,8 @@ and ``format`` specifies the representation of the returned result as one of:
 
 * ``html`` - an HTML table.
 * ``csv`` - a Comma Separated Values table.
+* ``zip`` - PKZip archive containing CSV as above, plus plain text of errors and request body.
+* ``xls`` - Microsoft Excel spreadsheet.
 
 .. note::
 
@@ -75,6 +92,8 @@ and ``format`` specifies the representation of the returned result as one of:
 
     * ``text/html``
     * ``application/csv``
+    * ``application/zip``
+    * ``application/vnd.ms-excel``
 
    See the `HTTP specification <http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html>`_
    for more information about the ``Accept`` header.
@@ -187,9 +206,9 @@ Specifies which request attribute to sort by, and optionally specifies the sort
    * - ``order=<attribute>[;<ASC|DESC>]``
      - requests.html?order=path
    * - 
-     - requests.html?order=startTime:DESC
+     - requests.html?order=startTime;DESC
    * - 
-     - requests.html?order=totalTime:ASC
+     - requests.html?order=totalTime;ASC
 
 
 

doc/en/user/source/conf.py

@@ -25,7 +25,7 @@
 # coming with Sphinx (named 'sphinx.ext.*') or your custom ones.
 extensions = ['sphinx.ext.todo']
 
-todo_include_todos = True
+#todo_include_todos = True
 
 # Add any paths that contain templates here, relative to this directory.
 #templates_path = ['../../theme/_templates']
@@ -39,15 +39,15 @@
 # General substitutions.
 project = u'GeoServer'
 manual = u'User Manual'
-copyright = u'2011 GeoServer'
+copyright = u'GeoServer'
 
 # The default replacements for |version| and |release|, also used in various
 # other places throughout the built documents.
 #
 # The short X.Y version.
 version = '2.2'
 # The full version, including alpha/beta/rc tags.
-release = '2.2-RC2'
+release = '2.2-RC3'
 # Users don't need to see the "SNAPSHOT" notation when it's there
 if release.find('SNAPSHOT') != -1:
    release = '2.2.x'

doc/en/user/source/datadirectory/migrating.rst

@@ -100,6 +100,7 @@ In order to restore the GeoServer 2.1 configuration:
        geoserver.jceks
        masterpw.xml
        masterpw.digest
+       masterpw.info
        auth/
        filter/
        masterpw/

doc/en/user/source/extensions/index.rst

@@ -13,6 +13,7 @@ see the :ref:`data_vector`, :ref:`data_raster`, and :ref:`data_database` section
 .. toctree::
    :maxdepth: 2
 
+   controlflow/index
    excel
    geosearch
    imagemap