tamaya-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From ple...@apache.org
Subject incubator-tamaya git commit: TAMAYA-7 Inline anchors must not contain spaces.
Date Sat, 29 Nov 2014 00:41:40 GMT
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 <plexus@apache.org>
Authored: Sat Nov 29 01:39:56 2014 +0100
Committer: Oliver B. Fischer <plexus@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
+--------------------------------------------


Mime
View raw message