HSTTWO-3578 make sure integration tests also run

HSTTWO-3579 make sure that requests that are a FORWARD and a JAAS authentication request are not handled by the HST

HSTTWO-3578: forward port of r58364: processing review feedback

CMS-9905: Update and align project pom parent and other dependency version references across all product projects

HSTTWO-3515 make sure only ' workspace node' is required and not 'pages' and 'sitemap' and that those are added when required

CMS-9899: prepare branch hst-3.2.x

HSTTWO-3538 make sure to return links in the content that start with a '/' always as is : you can only create a link in ckeditor that starts with a '/' if you use <other> and this is never a link to a document (they are always relative to current doc and never start with a slash). Also, more generically, we now check for ://  : If the link contains that, it is also external

HSTTWO-3574 Reintegrate rest api feature branch back into trunk

HSTTWO-1003: make explicit cms needs hst-api anyway

HSTTWO-3550 Reintegrate environment-settings branch into trunk

HSTTWO-3434 As found by Ate's review, replace 

if (cascadingInheritedPath.endsWith(hstConfigsInheritedRelPath)) {

with 

if (cascadingInheritedPath.endsWith(relPath)) {

Very good catch!!!

Furthermore added unit tests for it, and also as a result of the unit test fixed another problem : When X inherits hst:workspace/hst:pages from Y, and Y inherits hst:workspace/hst:pages from Z, then if Y does not have hst:workspace/hst:pages, the hst:workspace/hst:pages from Z should still be inherited

HSTTWO-3542: Incorporate generated addon-module xsd into source tree instead of regenerating it each build

CMS-9856: Update copyright year to 2016

HSTTWO-1003: Fix mount path in case a candidate mount has no matching context path.

HSTTWO-3522 reintroduce the CacheContentEventListener as deprecated just in case an end project uses the CacheContentEventListener by some spring component as well (unlikely because part of the hst-core but since I want to backport this fix to a patch version, can't harm to keep the CacheContentEventListener for now as deprecated available as well)

HSTTWO-3523 add two more ChannelException types to indicate that a channel action fails due to that the channel is already locked or that it is out of sync (for example when a user has channel settings open, and in the meantime another user opens also the channel settings, changes them, saves them and publishes them: At this point, the channel settings are not locked any more, but the properties for the first user are out of sync)

HSTTWO-3520 bump copyright year

HSTTWO-3519 since the channel mngr frontend needs to be able to get sometimes all channels regardless whether it has a preview config or not, and sometimes only when there is an explicit preview config, change the filtering on just 'preview' a bit to 'previewConfigRequired' : If false, the filtering is skipped. If true, only channels that have a preview are returned

HSTTWO-3516 make sure to not (re)set the CMS_REQUEST_RENDERING_MOUNT_ID in case the request is a container resource request (as a container resource always matches the hst:root mount and can incorrectly reset the CMS_REQUEST_RENDERING_MOUNT_ID as container resources (binaries) are rendered concurrently by the browser

HSTTWO-3447 do not show the '[edit menu] button if the menu is inherited from another channel

HSTTWO-3511 revert the pom version changes as result of the reintegrate

HSTTWO-3434 support cascading hst inheritance : From now on, an hst configuration setup as follows:
+ hst:hst
   + hst:configurations
      + common
      + corporate
          - hst:inheritsfrom = ../common
          + hst:sitemenus
          + hst:workspace
              + hst:sitemenus
      + subsite 
          - hst:inheritsfrom = ../corporate
          
makes sure that 'subsite' inherits from 'corporate' *and* from 'common'. Note that for the above setup, 'subsite' does not yet inherit the hst:workspace from 'corporate'. This can be achieve by:
      + subsite 
          - hst:inheritsfrom = ../corporate, ../corporate/hst:workspace
          
Note that if the configuration would had been:
+ hst:hst
   + hst:configurations
      + common
      + corporate
          - hst:inheritsfrom = ../common, ../common/hst:workspace
          + hst:sitemenus
          + hst:workspace
              + hst:sitemenus
      + subsite 
          - hst:inheritsfrom = ../corporate

in this case, subsite does not inherit the hst:workspace from 'corporate' but it does inherit the 'hst:workspace' from 'common' because 'corporate' inherits from ../common, ../common/hst:workspace.

Another detail: In case the setup is:

+ hst:hst
   + hst:configurations
      + common
      + corporate
          - hst:inheritsfrom = ../common, ../common/hst:workspace
          + hst:sitemenus
          + hst:workspace
              + hst:sitemenus
      + subsite 
          - hst:inheritsfrom = ../corporate, ../corporate/hst:workspace
          
then 'subsite' inherits in the following order the configuration:
1) corporate
2) common
3) common/hst:workspace  
4) corporate/hst:workspace
this is because the *first* inheritacance (../corporate) is first completely inherited. Also note that the above configuration is not very likely to really occur in practice. 
Note that if the configuration would had been:
+ hst:hst
   + hst:configurations
      + common
      + corporate
          - hst:inheritsfrom = ../common, ../common/hst:workspace
          + hst:sitemenus
          + hst:workspace
              + hst:sitemenus
      + subsite 
          - hst:inheritsfrom = ../corporate/hst:workspace, ../corporate

then the order of inheritance would had been:
1) corporate/hst:workspace   
2) corporate
3) common
4) common/hst:workspace
The order of inheritance is important when it comes to 'shielding' configuration nodes in case of same node names 
        
All the above scenarios have been added in unit tests

HSTTWO-3454 accounted for review suggestion by Michiel and added unit tests for validating different scenarios. Also maed sure that without hst request context, the includeQueryString boolean is honoured

HSTTWO-3501 have the option to call 'findDocumentPathsRecursive' with a Predicate function that can skip the recursion scanning of some hst component configurations

HSTTWO-3464: Reintegrate Menu Editor Improvements feature.

:HSTTWO-3465 forward port : switch the default

:HSTTWO-3465 forward port : switch the default

HSTTWO-3452 make method that creates link inside rich text protected

HSTTWO-3400 merging hdc-in-all branch

HSTTWO-3444 make sure that when the nt:resource gets replaced, ftl also gets reloaded. Note that the fix is in SpringComponentManager-freemarker.xml. The changes in WebFilesTemplateEventListener are just making the code a bit more resilient (it might be that before a unlikely path like /webfiles/site/ftl/my.stange.ftl.path would result in an index out of bounds exc

CMS-16: Bump internal dependency properties to use the current (snapshot) 10.2 versions

CMS-9583: prepare branch hst-3.1.x

CMS-16: Bump internal dependency properties to use the current (snapshot) versions

HSTTWO-3385 merge hst-inheritance branch back into trunk

HSTTWO-3432 fix the unit test assumptions: They incorrectly asserted that hst:workspace nodes could also be inherited which should not be the case

HSTTWO-1003: keep bc with 10.0

HSTTWO-1003 trivial code impr

HSTTWO-3423  trivial improvement - moving the FULLY_QUALIFIED_URL_PREFIXES to PathUtils

HSTTWO-3423 trivial impr: use method without null arg

HSTTWO-1003 clean up imports

HSTTWO-3420: implementing mechanism to globally set content rewriter using Spring configuration

HSTTWO-3417 prepare branch hst-3.1.0-translations-1

HSTTWO-3402: removing unnecessary exclusions, setting HST root pom to use 27.3-SNAPSHOT as parent

HSTTWO-3406:rollback changes from release preparation of site-toolkit-3.1.0.menueditor-improvements

CMS-9528:rollback changes from release preparation of site-toolkit-3.1.0.menueditor-improvements

HSTTWO-3405 check in unit test that should pass after the improvement in code has been done

HSTTWO-3401 remove unneeded geronimo-annotation dependency.

HSTTWO-3397 add getHstSiteMapItem() to HstLink interface : It is a valuable getter for end project developers to know to which sitemap item a hst link actually maps, *and* the HstLinkImpl had all the bits and bytes for retrieving the sitemap item already implemented

HSTTWO-3386 better name

HSTTWO-3386 fix the unit test expectation wrt the switched default