incubator-tamaya git commit: TAMAYA-7 Inline anchors must not contain spaces.

[pl...@apache.org]

Repository: incubator-tamaya
Updated Branches:
  refs/heads/master 495e006ae -> 51a4ee16c


TAMAYA-7 Inline anchors must not contain spaces.


Project: http://git-wip-us.apache.org/repos/asf/incubator-tamaya/repo
Commit: http://git-wip-us.apache.org/repos/asf/incubator-tamaya/commit/51a4ee16
Tree: http://git-wip-us.apache.org/repos/asf/incubator-tamaya/tree/51a4ee16
Diff: http://git-wip-us.apache.org/repos/asf/incubator-tamaya/diff/51a4ee16

Branch: refs/heads/master
Commit: 51a4ee16ca002eb606b3cbfcd599de37e1a3ddbc
Parents: 495e006
Author: Oliver B. Fischer <pl...@apache.org>
Authored: Sat Nov 29 01:39:56 2014 +0100
Committer: Oliver B. Fischer <pl...@apache.org>
Committed: Sat Nov 29 01:39:56 2014 +0100

----------------------------------------------------------------------
 docs/design/0_UseCases.adoc     | 22 +++++++++++-----------
 docs/design/2_CoreConcepts.adoc |  8 ++++----
 2 files changed, 15 insertions(+), 15 deletions(-)
----------------------------------------------------------------------


http://git-wip-us.apache.org/repos/asf/incubator-tamaya/blob/51a4ee16/docs/design/0_UseCases.adoc
----------------------------------------------------------------------
diff --git a/docs/design/0_UseCases.adoc b/docs/design/0_UseCases.adoc
index 5a95b4e..a7719ab 100644
--- a/docs/design/0_UseCases.adoc
+++ b/docs/design/0_UseCases.adoc
@@ -1,10 +1,10 @@
 <<<
-[[Use Cases]]
+[[UseCases]]
 == Use Cases
 
 This section describes some, but not all, of the use cases that should be covered with this JSR.
 
-[[UC Simple Configuration]]
+[[UCSimpleConfiguration]]
 === Simple Property Based Configuration
 
 In this most simple usage scenario an application is created that is preconfigured by some property files contained in the
@@ -17,7 +17,7 @@ Typical example are small command line tools.
 
 -> It must be possible that command line arguments can override defaults configured.
 
-[[UC Advanced Property Based Configuration]]
+[[UCAdvancedPropertyBasedConfiguration]]
 === Advanced Property Based Configuration
 
 Enhancing the previous scenario, we might as well consider the current environment. Saying that our overriding mechanisms
@@ -39,7 +39,7 @@ system should be able to support these formats.
 
 -> It must be possible to define customized configuration formats.
 
-[[UC Modularized Configuration]]
+[[UCModularizedConfiguration]]
 === Modularized Configuration
 
 When systems grow they must be modularized to keep control. Whereas that sounds not really fancy, it leads to additional things
@@ -55,7 +55,7 @@ Consequently
 -> Module configuration requires partial isolation or other mechanisms to ensure only configuration aspects
    that are allowed to be overriden can be overriden.
 
-[[UC Dynamic Provisioning]]
+[[UCDynamicProvisioning]]
 === Dynamic Provisioning
 
 In Cloud Computing, especially the PaaS and SaaS areas a typical use case would be that an application (or server)
@@ -84,7 +84,7 @@ Consequently:
 -> Similarly a management API should be defined, which allows to inspect the configuration in place, e.g. using
    JMX or REST services.
 
-[[UC Java EE]]
+[[UCJavaEE]]
 === Java EE
 
 Considering Java EE different aspects should be considered:
@@ -124,7 +124,7 @@ may override ear or system configuration.
 
 -> JNDI can be used for configuration as well.
 
-[[UC MultiTenancy]]
+[[UCMultiTenancy]]
 === Scenario MultiTenancy
 In multi tenancy setups a hierarchical/graph model of contexts for configurations is required. For example there might
 be some kind of layering as follows:
@@ -142,7 +142,7 @@ Configurations made in the tenant or user layer override the default app configu
 -> The current environment must be capable of mapping tenant, user and other aspects, so a corresponding configuration
    (or layer) can be derived.
 
-[[UC Java API]]
+[[UCJavaAPI]]
 === Accessing Configuration
 
 So far we described much how configuration must be organized and managed, but we got not concrete, how it is accessed.
@@ -218,7 +218,7 @@ Configuration config = Configuration.of(Configuration.class);
 ----------------------------------------------------
 
 
-[[UC Testing]]
+[[UCTesting]]
 === Testing
 When testing a Java solution, it must be possible to easily control the configuration provided, so isolated
 component tests can be written effectively. Also it should be possible to control/isolate the configuration level for
@@ -228,7 +228,7 @@ each test case.
 
 -> API for controlling the configuration provided, required for according implementations in the testing frameworks.
 
-[[UC Staging]]
+[[UCStaging]]
 === Staging
 Different companies go through different staging levels during the development of software components. Currently only
 rarely the EE frameworks support staging aspects, nevertheless no broader, well modelled staging concept is defined.
@@ -240,7 +240,7 @@ Especially with sub-stages inheritance of stage related configuration is common
 -> Enable additional stages to be added, so also custom stages can be supported.
 
 
-[[UC CotsIntegration]]
+[[UCCotsIntegration]]
 === Custom of the Shelf (COTS) Integration
 When buying software from an external software company it is often very cumbersome to integrate, adapt and customize
 third party software to the internal operational requirements. Especially, when software is delivered as ear modules

http://git-wip-us.apache.org/repos/asf/incubator-tamaya/blob/51a4ee16/docs/design/2_CoreConcepts.adoc
----------------------------------------------------------------------
diff --git a/docs/design/2_CoreConcepts.adoc b/docs/design/2_CoreConcepts.adoc
index b790a5f..c7eb766 100644
--- a/docs/design/2_CoreConcepts.adoc
+++ b/docs/design/2_CoreConcepts.adoc
@@ -1,5 +1,5 @@
 <<<
-[[Core Concepts]]
+[[CoreConcepts]]
 == {name} Core Concepts
 Though {name} is a very powerful and flexible solution there are basically only a few simple core concepts required that build
 the base of all the other mechanisms:
@@ -16,7 +16,7 @@ These parts are explained in the following sections. It is recommended that user
 All subsequent parts are building upon this concepts and may be more difficult to understand without having read
 this section.
 
-[[API KeyValues]]
+[[APIKeyValues]]
 === Key/Value Pairs
 
 Basically configuration is a very generic concept. Therefore it should be modelled in a generic way. The most simple
@@ -132,7 +132,7 @@ Nevertheless most of these advantages can be mitigated easily, hereby still keep
 ** The keys of configuration can have additional syntax/semantics. E.g. when adding dor-separating path semantics
 *** trees/maps can also simply be mapped:
 
-[API Property Providers]
+[APIPropertyProviders]
 === Property Providers
 ==== Basic Model
 
@@ -504,4 +504,4 @@ System.out.println(env.getEnvironmentContext()); // root
 System.out.println(env.getEnvironmentId());      // system
 env = env.getParentEnvironment();
 // env is null now!
---------------------------------------------
\ No newline at end of file
+--------------------------------------------