tamaya-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From pottlin...@apache.org
Subject [1/4] incubator-tamaya git commit: TAMAYA-209: Remove old stuff from main repo.
Date Mon, 19 Dec 2016 21:38:53 GMT
Repository: incubator-tamaya
Updated Branches:
  refs/heads/master f6cce93bf -> 63124d1fa


http://git-wip-us.apache.org/repos/asf/incubator-tamaya/blob/63124d1f/src/site/asciidoc/extensions/mod_spring.adoc
----------------------------------------------------------------------
diff --git a/src/site/asciidoc/extensions/mod_spring.adoc b/src/site/asciidoc/extensions/mod_spring.adoc
deleted file mode 100644
index 5f6d65e..0000000
--- a/src/site/asciidoc/extensions/mod_spring.adoc
+++ /dev/null
@@ -1,148 +0,0 @@
-// Licensed to the Apache Software Foundation (ASF) under one
-// or more contributor license agreements.  See the NOTICE file
-// distributed with this work for additional information
-// regarding copyright ownership.  The ASF licenses this file
-// to you under the Apache License, Version 2.0 (the
-// "License"); you may not use this file except in compliance
-// with the License.  You may obtain a copy of the License at
-//
-//   http://www.apache.org/licenses/LICENSE-2.0
-//
-// Unless required by applicable law or agreed to in writing,
-// software distributed under the License is distributed on an
-// "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
-// KIND, either express or implied.  See the License for the
-// specific language governing permissions and limitations
-// under the License.
-
-= Apache Tamaya -- Extension: Spring Integration
-
-toc::[]
-
-
-[[Remote]]
-== Tamaya Spring Integration (Extension Module)
-=== Overview
-
-Apache Tamaya currently provides two implementations also full integration for Spring:
-
-* A Spring +@Configuration+ implementation that also provides a Tamaya based version of
-  +org.springframework.context.support.PropertySourcesPlaceholderConfigurer+.
-* +org.apache.tamaya.integration.spring.TamayaEnvironment+ is the Tamaya based implementation of the Spring
-  +Environment+ interface.
-* +TamayaSpringPropertySource+ implements an additional Spring +PropertySource+.
-* Finally +org.apache.tamaya.integration.spring.SpringConfigInjectionPostProcessor+ implements a Bean +PostProcessor+,
-  which adds all the full fledged Tamaya configuration capabilities to Spring.
-
-
-=== Compatibility
-
-Both modules are based on Java 7, so they will not run on Java 7 and beyond. The extension shown here works similarly
-with Spring Framework as well as Spring Boot.
-
-
-=== Installation
-
-To benefit from Tamaya Spring integration you only must one of the following dependencies to your module:
-
-[source, xml]
------------------------------------------------
-<dependency>
-  <groupId>org.apache.tamaya.ext</groupId>
-  <artifactId>tamaya-spring</artifactId>
-  <version>{tamayaVersion}</version>
-</dependency>
------------------------------------------------
-
-
-=== Registering Tamaya Spring Configuration
-
-Basically to activate the Tamaya Spring support the most simple thing is to a enable the Tamaya package for being
-scanned for Spring components, e.g.
-
-[source, xml]
---------------------------------------------------------
-<beans xmlns="http://www.springframework.org/schema/beans"
-       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
-       xmlns:context="http://www.springframework.org/schema/context"
-       xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context.xsd">
-
-    <context:annotation-config />
-    <context:component-scan base-package="org.apache.tamaya.integration.spring"/>
-
-    ...
-
-</beans>
---------------------------------------------------------
-
-NOTE: Of course you can also use the newer +@ComponentScan+ annotation as described by the Spring documentation.
-
-
-Similarly if you dont want to use component scanning you can configure things using plain old XML. Simply add the
-following lines somewhere into one of your application context configuration files.
-
-[source, xml]
---------------------------------------------------------
-<bean id="tamayaInjectionProcessor" name="tamayaInjectionProcessor" class="org.apache.tamaya.integration.spring.SpringConfigInjectionPostProcessor"/>
-<bean id="tamayaConfigProvider" name="tamayaConfigProvider" class="org.apache.tamaya.integration.spring.TamayaSpringConfig"/>
---------------------------------------------------------
-
-=== Configuring your Context
-
-Done so enables you to use Tamaya as a backend for property resolution, e.g. +propertyValue+ as illustrated below
-is resolved from the current Tamaya configuration.
-
-[source, xml]
---------------------------------------------------------
-<bean id="configuredBean" name="configuredBean" class="org.apache.tamaya.integration.spring.ConfiguredSpringBean">
-    <property name="message" value="${propertyValue}"/>
-</bean>
---------------------------------------------------------
-
-=== Configuring your Beans
-
-Similarly you can inject any kind of configuration as supported by Tamaya into your Spring managed beans:
-
-[source, java]
---------------------------------------------------------
-**
- * Created by Anatole on 25.09.2015.
- */
-@ConfigDefaultSections
-public class ConfiguredSpringBean {
-
-    private String message;
-
-    @Autowired
-    private Environment env;
-
-    @Config("java.version")
-    private String javaVersion;
-
-    @Config
-    @ConfigDefault("23")
-    private int testNumber;
-
-    public String getJavaVersion(){
-        return javaVersion;
-    }
-
-    public int getTestNumber(){
-        return testNumber;
-    }
-
-    public Environment getEnv(){
-        return env;
-    }
-
-    public void setMessage(String message){
-        this.message = message;
-    }
-
-    public String getMessage() {
-        return message;
-    }
-}
---------------------------------------------------------
-
-Summarizing you get all the nice features of Tamaya out of the box running with your Spring code.
\ No newline at end of file

http://git-wip-us.apache.org/repos/asf/incubator-tamaya/blob/63124d1f/src/site/asciidoc/extensions/mod_usagetracker.adoc
----------------------------------------------------------------------
diff --git a/src/site/asciidoc/extensions/mod_usagetracker.adoc b/src/site/asciidoc/extensions/mod_usagetracker.adoc
deleted file mode 100644
index 41d4871..0000000
--- a/src/site/asciidoc/extensions/mod_usagetracker.adoc
+++ /dev/null
@@ -1,169 +0,0 @@
-// Licensed to the Apache Software Foundation (ASF) under one
-// or more contributor license agreements.  See the NOTICE file
-// distributed with this work for additional information
-// regarding copyright ownership.  The ASF licenses this file
-// to you under the Apache License, Version 2.0 (the
-// "License"); you may not use this file except in compliance
-// with the License.  You may obtain a copy of the License at
-//
-//   http://www.apache.org/licenses/LICENSE-2.0
-//
-// Unless required by applicable law or agreed to in writing,
-// software distributed under the License is distributed on an
-// "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
-// KIND, either express or implied.  See the License for the
-// specific language governing permissions and limitations
-// under the License.
-
-= Apache Tamaya -- Extension: Usage Tracking
-
-toc::[]
-
-
-[[Core]]
-== Tamaya Usage Tracking (Extension Module)
-=== Overview
-
-Tamaya Usage Tracking allows to record and count the configuration access and consumer locations in your local
-VM.
-
-=== Compatibility
-
-The module is based on Java 7, so it can be used with Java 7 and beyond.
-
-=== Installation
-
-To benefit from configuration mutability support you only must add the corresponding dependency to your module:
-
-[source, xml]
------------------------------------------------
-<dependency>
-  <groupId>org.apache.tamaya.ext</groupId>
-  <artifactId>tamaya-usagetracker</artifactId>
-  <version>{tamayaVersion}</version>
-</dependency>
------------------------------------------------
-
-
-=== Tracking Configuration Access
-
-The model module also allows tracking which code accesses configuration properties or configuration parameters.
-It checks the stacktrace to evaluate the calling code location, hereby any unwanted packages can be implicitly
-ommitted from the stacktrace. Also the maximal length of the stacktrace retained can be constraint in length.
-The usages are recorded as +Usage+ instances. Hereby for each parameter accessed a corresponding +Usage+
-instance is created. It can be accessed by calling +Usage ConfigUsageStats.getUsage(String key)+. Usage
-statistics for calling +Configuration.getProperties()+ can be obtained calling +Usage getUsageAllProps();+.
-
-Usage tracking is disabled by default. It can be enabled by calling +ConfigUsageStats.enableUsageTracking(true);+.
-+ConfigUsageStats.isUsageTrackingEnabled()+ returns the current tracking status.
-
-The +Usage+ class itself provides access to further fainer grained usage data (+AccessDetail+) containing:
-
-* the access point (+fqn.ClassName#method(line: xxx)+).
-* the number of accesses
-* the first an last access
-* the values read
-* the access stacktrace (filtered by ignored packages).
-
-[source,java]
------------------------------------------------------------
-public final class Usage {
-    [...]
-    public String getKey();
-    public void clearMetrics();
-    public int getReferenceCount();
-    public int getUsageCount();
-    public Collection<AccessDetail> getAccessDetails(Class type);
-    public Collection<AccessDetail> getAccessDetails(Package pack);
-    public Collection<AccessDetail> getAccessDetails(String lookupExpression);
-    public Collection<AccessDetail> getAccessDetails();
-    public void trackUsage(String value);
-    public void trackUsage(String value, int maxTraceLength);
-
-
-    public static final class AccessDetail {
-        [...]
-        public void clearStats();
-        public long trackAccess(String value);
-        public long getAccessCount();
-        public String getAccessPoint();
-        public long getFirstAccessTS();
-        public long getLastAccessTS();
-        public String[] getStackTrace();
-        public Map<Long, String> getTrackedValues();
-    }
-
-}
------------------------------------------------------------
-
-With +ConfigUsageStats.clearUsageStats()+ the collected statistics can be reset at any time. Summarizing the main
-singleton for configuration statistics is defined as follows:
-
-[source,java]
------------------------------------------------------------
-public final class ConfigUsageStats{
-    public static Set<String> getIgnoredUsagePackages();
-    public static void addIgnoredUsagePackages(String... packageName);
-    public static void enableUsageTracking(boolean enabled);
-    public static Usage getUsage(String key);
-    public static Collection<Usage> getUsages();
-    public static void clearUsageStats();
-    public static Usage getUsageAllProperties();
-    public static boolean isUsageTrackingEnabled();
-    public static String getUsageInfo();
-}
------------------------------------------------------------
-
-==== Customizing the Stacktrage for Usage Reporting
-
-The stacktrace tracked by the system can be customized in several ways:
-
-* +ConfigUsageStats.addIgnoredPackageNames(String...)+ allows to add additional ignored package names.
-* With +Usage.setMaxTraceLength(int)+ the maximal size of the stacktraces logged can be set. Setting a
-  negative value will disable stacktrace logging completelely.
-
-
-=== Accessing Usage Statistics
-
-Bascially usage statistics are available in two forms:
-
-* The +Usage/AccessDetail+ object tree can be accessed programmatically from the +ConfigUsageStats+
-  singleton.
-* With +ConfigUsageStats.getUsageInfo()+ also a textual representation of the usage statistics
-  can be obtained, as illustrated below (a snipped from the current test output):
-
-[source,listing]
------------------------------------------------------------
-Apache Tamaya Configuration Usage Metrics
-=========================================
-DATE: Sat Apr 30 21:51:09 CEST 2016
-
-220    <<all>>:
-  - 220   <unknown/filtered/internal>                       , first=Sat Apr 30 21:51:09 CEST 2016, last=Sat Apr 30 21:51:09 CEST 2016
-3      java.version:
-  - 2     test.model.TestConfigAccessor#readProperty(line:43), first=Sat Apr 30 21:51:09 CEST 2016, last=Sat Apr 30 21:51:09 CEST 2016
-  - 1     <unknown/filtered/internal>                       , first=Sat Apr 30 21:51:09 CEST 2016, last=Sat Apr 30 21:51:09 CEST 2016
-
------------------------------------------------------------
-
-
-=== Auto-Documentation of Classes with Configuration Injection
-
-A special feature of this module is that it observes +ConfigEvent+ published through Tamaya'as event channel
-(+tamaya-events+ module). If no metaconfiguration model is found the model manager by default automatically creates
-models for all injected instances on the fly. In the case of CDI integration this happens typically during deployment
-time, since CDI initializes during deployment time. Other runtime platforms, such as OSGI, may have rather different
-behaviour. Nevertheless this means that after your system has been started you should have access to a complete
-set of +ConfigModel+ instances that automatically document all the classes in your system that consume configuration
-(through injection).
-
-
-== UsageTracker Module SPI
-
-=== The ConfigUsageStatsSpi
-
-The methods for managing and tracking of configuration changes are similarly delegated to an
-implementation of the +org.apache.tamaya.model.spi.ConfigUsageStatsSpi+ SPI.
-By implementing this SPI and registerting it with the +ServiceContext+ the usage tracking
-logic can be adapted or replaced.
-

http://git-wip-us.apache.org/repos/asf/incubator-tamaya/blob/63124d1f/src/site/asciidoc/extensions/mod_validation.adoc
----------------------------------------------------------------------
diff --git a/src/site/asciidoc/extensions/mod_validation.adoc b/src/site/asciidoc/extensions/mod_validation.adoc
deleted file mode 100644
index 777a1d7..0000000
--- a/src/site/asciidoc/extensions/mod_validation.adoc
+++ /dev/null
@@ -1,111 +0,0 @@
-// Licensed to the Apache Software Foundation (ASF) under one
-// or more contributor license agreements.  See the NOTICE file
-// distributed with this work for additional information
-// regarding copyright ownership.  The ASF licenses this file
-// to you under the Apache License, Version 2.0 (the
-// "License"); you may not use this file except in compliance
-// with the License.  You may obtain a copy of the License at
-//
-//   http://www.apache.org/licenses/LICENSE-2.0
-//
-// Unless required by applicable law or agreed to in writing,
-// software distributed under the License is distributed on an
-// "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
-// KIND, either express or implied.  See the License for the
-// specific language governing permissions and limitations
-// under the License.
-
-= Apache Tamaya -- Extension: Configuration Validation
-
-toc::[]
-
-
-[[Remote]]
-== Tamaya Validation: Validating Configuration (Extension Module)
-=== Overview
-
-The Tamaya Validation extension adds support to validate a configuration against a set of rules
-defined in a Tamaya Metaconfiguration XML file.
-
-=== Compatibility
-
-The module is based on Java 7, so it will not run on Java 7 and beyond.
-
-
-=== Installation
-
-To benefit from Tamaya Metamodel feature you only must add the corresponding dependency to your module:
-
-[source, xml]
------------------------------------------------
-<dependency>
-  <groupId>org.apache.tamaya.ext</groupId>
-  <artifactId>tamaya-validation</artifactId>
-  <version>{tamayaVersion}</version>
-</dependency>
------------------------------------------------
-
-The component will extend Tamaya's +tamaya-metamodel+ module and adds an additional meta provider ruleset
-so validation rules can also be added to the default meta configuration XML file as separate sections.
-
-
-=== Usage
-
-This module expects meta-configuration to be located at the following locations. Hereby multiple files
-are supported:
-
-[source, text]
------------------------------------------------
--Dtamaya-validation=<an URL>    // any resolvable URL
-./tamaya-validation-*.xml         // file
-META-INF/tamaya-validation-*.xml  // classpath (multiple entries-possible)
------------------------------------------------
-
-=== The Validation XML Format
-
-The configuration validation is defined by simple configuration meta-data entries.
-
-[source, xml]
------------------------------------------------
-<configuration-validation>
-   ...
-   <provider>The Validation Provider</provider> <!-- optional -->
-   <section name="org.mycompany">
-       <section name="security" required="true">
-         <description>The description of ma area.</description>
-       </section>
-   </section>
-   <section name="minimal"/>
-   <section name="validated.sections" at-least="1">
-     <section name="customValidated" validator="myFQValidatorClassName"/>
-     <section name="withParams" >
-       <param name="int" type="int"/>
-       <param name="aText" expression="[a|b|c]" required="true"/>
-       <param name="aValidatedText" validator="myValidatorClass">
-         <description>This kind of params are more complex...</description>
-       </param>
-     </section>
-   </section>
-   <validator class="a,b,c,MyGlobalValidator"/>
-</configuration-validation>
------------------------------------------------
-
-==== The Example Explained
-
-* The *provider* entry is used for generating validation message, when a validation fails.
-* Section itself can be recursively defined, where each level can have it's own validations.
-* Sections added, but without validation rules are _defined_ section. Configuration outside of
-  defined sections can be flagged out using WARNING messages.
-* Sections can be _reuired_ and additionally also _validated_.
-* There is also the possibility to register global validators, which are called by the validation
-  logic once a configuration has been completely loaded.
-
-Similar to sections also parameters can be validated:
-
-* they can be marked as _required_
-* they can have a certain type, meaning they must be convertible to the given type
-* they can have an additional custom validator.
-* they can have an optional description for error analysis and error output.
-
-Similar to section parameters that are not defined, but encountered may be flagged out with
-a WARNING message.

http://git-wip-us.apache.org/repos/asf/incubator-tamaya/blob/63124d1f/src/site/asciidoc/extensions/mod_yaml.adoc
----------------------------------------------------------------------
diff --git a/src/site/asciidoc/extensions/mod_yaml.adoc b/src/site/asciidoc/extensions/mod_yaml.adoc
deleted file mode 100644
index 85c1871..0000000
--- a/src/site/asciidoc/extensions/mod_yaml.adoc
+++ /dev/null
@@ -1,127 +0,0 @@
-// Licensed to the Apache Software Foundation (ASF) under one
-// or more contributor license agreements.  See the NOTICE file
-// distributed with this work for additional information
-// regarding copyright ownership.  The ASF licenses this file
-// to you under the Apache License, Version 2.0 (the
-// "License"); you may not use this file except in compliance
-// with the License.  You may obtain a copy of the License at
-//
-//   http://www.apache.org/licenses/LICENSE-2.0
-//
-// Unless required by applicable law or agreed to in writing,
-// software distributed under the License is distributed on an
-// "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
-// KIND, either express or implied.  See the License for the
-// specific language governing permissions and limitations
-// under the License.
-
-= Apache Tamaya -- Extension: Builder
-
-toc::[]
-
-
-[[BuilderCore]]
-== Tamaya YAML (Extension Module)
-=== Overview
-
-The Tamaya YAML module provides support for reading configuration using the YAML format (yaml.org). YAML hereby
-use intendation for expressing hierarchy, which makes yaml configuration files very easily readable and compact.
-
-
-=== Compatibility
-
-The YAML module is based on Java 7, so it will not run on Java 7 and beyond.
-
-
-=== Installation
-
-To benefit from configuration builder support you only must add the corresponding dependency to your module:
-
-[source, xml]
------------------------------------------------
-<dependency>
-  <groupId>org.apache.tamaya.ext</groupId>
-  <artifactId>tamaya-yaml</artifactId>
-  <version>{tamayaVersion}</version>
-</dependency>
------------------------------------------------
-
-This extension also transitively requires the +tamaya.formats+ module.
-
-=== Reading configuration in YAML
-
-For reading YAML based onfiguration most easily a +YAMLFormat+ can be provided:
-
-[source, java]
------------------------------------------------
-ConfigurationData dataRead = ConfigurationFormats.readConfig(
-    getClassLoader().getResource("myFileConfig.yaml"), new YAMLFormat()));
------------------------------------------------
-
-=== Examples
-
-The YAML module adds instances of +ConfigurationFormat+ so YAML configuration can be read and mapped to the
-according property values. E.g. the following file is a simple and correct YAML configuration:
-
-[source,yaml]
-----------------------------------------------------------------
-invoice: 34843
-date   : 2001-01-23
-bill-to: &id001
-    given  : Chris
-    family : Dumars
-    address:
-        lines: |
-            458 Walkman Dr.
-            Suite #292
-        city    : Royal Oak
-        state   : MI
-        postal  : 48046
-ship-to: *id001
-product:
-    - sku         : BL394D
-      quantity    : 4
-      description : Basketball
-      price       : 450.00
-    - sku         : BL4438H
-      quantity    : 1
-      description : Super Hoop
-      price       : 2392.00
-tax  : 251.42
-total: 4443.52
-comments:
-    Late afternoon is best.
-    Backup contact is Nancy
-    Billsmer @ 338-4338.
-----------------------------------------------------------------
-
-Hereby the above file, by default is mapped as follows into +Map<String,String>+ typed properties:
-
-[source,listing]
-----------------------------------------------------------------
-invoice -> 34843
-date -> Tue Jan 23 01:00:00 CET 2001
-bill-to.family -> Dumars
-bill-to.given -> Chris
-bill-to.address.state -> MI
-bill-to.address.postal -> 48046
-bill-to.address.city -> Royal Oak
-bill-to.address.lines -> 458 Walkman Dr.
-Suite #292
-
-ship-to.given -> Chris
-ship-to.address.state -> MI
-ship-to.family -> Dumars
-ship-to.address.postal -> 48046
-ship-to.address.city -> Royal Oak
-ship-to.address.lines -> 458 Walkman Dr.
-Suite #292
-
-product -> {sku=BL394D, quantity=4, description=Basketball, price=450.0},{sku=BL4438H, quantity=1, description=Super Hoop, price=2392.0}
-_product.collection-type -> List
-
-tax -> 251.42
-total -> 4443.52
-comments -> Late afternoon is best. Backup contact is Nancy Billsmer @ 338-4338.
-----------------------------------------------------------------
-

http://git-wip-us.apache.org/repos/asf/incubator-tamaya/blob/63124d1f/src/site/asciidoc/history.adoc
----------------------------------------------------------------------
diff --git a/src/site/asciidoc/history.adoc b/src/site/asciidoc/history.adoc
deleted file mode 100644
index caa0169..0000000
--- a/src/site/asciidoc/history.adoc
+++ /dev/null
@@ -1,49 +0,0 @@
-// Licensed to the Apache Software Foundation (ASF) under one
-// or more contributor license agreements.  See the NOTICE file
-// distributed with this work for additional information
-// regarding copyright ownership.  The ASF licenses this file
-// to you under the Apache License, Version 2.0 (the
-// "License"); you may not use this file except in compliance
-// with the License.  You may obtain a copy of the License at
-// .
-//   http://www.apache.org/licenses/LICENSE-2.0
-// .
-// Unless required by applicable law or agreed to in writing,
-// software distributed under the License is distributed on an
-// "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
-// KIND, either express or implied.  See the License for the
-// specific language governing permissions and limitations
-// under the License.
-
-//:source-highlighter: coderay
-
-include::temp-properties-files-for-site/attributes.adoc[]
-:linkattrs: true
-
-== Apache Tamaya: Release History
-
-Overview off all released versions of Apache Tamaya.
-
-[width="70"]
-[cols="2,3,3,3", options="headers", frame="all"]
-|===
-| Version
-| Release date
-| Release Notes
-| Download
-
-| 0.2-incubating
-| 06.04.2016
-| http://www.apache.org/dist/incubator/tamaya/0.2-incubating/ReleaseNotes-0.2-incubating.html[Release Notes for 0.2 incubating^]
-| http://www.apache.org/dist/incubator/tamaya/0.2-incubating/[Download of 0.2 incubating^]
-
-
-| 0.1-incubating
-| 22.08.2015
-| http://www.apache.org/dist/incubator/tamaya/0.1-incubating/ReleaseNotes-0.1-incubating.html[Release Notes for 0.1 incubating^]
-| http://www.apache.org/dist/incubator/tamaya/0.1-incubating/[Download of 0.1 incubating^]
-
-|===
-
-
-

http://git-wip-us.apache.org/repos/asf/incubator-tamaya/blob/63124d1f/src/site/asciidoc/images/CoreDesign.png
----------------------------------------------------------------------
diff --git a/src/site/asciidoc/images/CoreDesign.png b/src/site/asciidoc/images/CoreDesign.png
deleted file mode 100644
index a84d8a6..0000000
Binary files a/src/site/asciidoc/images/CoreDesign.png and /dev/null differ

http://git-wip-us.apache.org/repos/asf/incubator-tamaya/blob/63124d1f/src/site/asciidoc/misc/PossibleContributions.adoc
----------------------------------------------------------------------
diff --git a/src/site/asciidoc/misc/PossibleContributions.adoc b/src/site/asciidoc/misc/PossibleContributions.adoc
deleted file mode 100644
index 23840c2..0000000
--- a/src/site/asciidoc/misc/PossibleContributions.adoc
+++ /dev/null
@@ -1,260 +0,0 @@
-// Licensed to the Apache Software Foundation (ASF) under one
-// or more contributor license agreements.  See the NOTICE file
-// distributed with this work for additional information
-// regarding copyright ownership.  The ASF licenses this file
-// to you under the Apache License, Version 2.0 (the
-// "License"); you may not use this file except in compliance
-// with the License.  You may obtain a copy of the License at
-// .
-//   http://www.apache.org/licenses/LICENSE-2.0
-// .
-// Unless required by applicable law or agreed to in writing,
-// software distributed under the License is distributed on an
-// "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
-// KIND, either express or implied.  See the License for the
-// specific language governing permissions and limitations
-// under the License.
-
-include::temp-properties-files-for-site/attributes.adoc[]
-
-toc::[]
-
-= Apache Tamaya - Possible Tasks
-
-:numbered!:
------------------------------------------------------------
-Licensed to the Apache Software Foundation (ASF) under one
-or more contributor license agreements.  See the NOTICE file
-distributed with this work for additional information
-regarding copyright ownership.  The ASF licenses this file
-to you under the Apache License, Version 2.0 (the
-"License"); you may not use this file except in compliance
-with the License.  You may obtain a copy of the License at
-
-   http://www.apache.org/licenses/LICENSE-2.0
-
-Unless required by applicable law or agreed to in writing,
-software distributed under the License is distributed on an
-"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
-KIND, either express or implied.  See the License for the
-specific language governing permissions and limitations
-under the License.
------------------------------------------------------------
-
-:numbered:
-
-<<<
-
-== Introduction
-
-== What is Tamaya
-
-{name} is the Apache standard for flexible and powerful configuration. Objective is to provide flavors for
-Java SE, ME as well as to ship with powerful features for Java EE and Cloud Solutions. All functions provided
-is build on top of a small but very powerful, flexible and extendible API. This API is implemented by a core implementation,
-which then can be extended or adapted for use in different runtime scenarios, such as SE, ME, EE, Spring, OSGI
-and more. Similarly additional modules may be provided that help also existing solution to be plugged into
-{name}, so you can start right away using {name} without having to rebuild/change your existing application.
-
-
-=== Purpose of this Document
-
-The document should help to organize people and ideas around the Apache Tamaya Library. It list possible features,
-ideas and tasks that need to be done. Everybody can have a look at and see, where hos contribution and capabilities
-would fit best.
-
-
-== Main Features
-
-=== Metadata Model
-
-Currently +MetaInfo+ models metadata as a separate constuct. It has been shown that this leads to more complex
-handling when creating composites and makes the API overall more complex. The idea is to model metadata as simple
-key/value pairs, that are part of the provider/configuration data as well, but handled separately. Metadata hereby
-is identified by a starting '_' character in its key. For example refer to the following configuration properties:
-
-[source,listing]
-.Basic Properties
-----------------------------------------------------------------
-a.b.Foo=foo
-a.b.Bar=bar
-a.AnyOther=whatelse
-Something=none
-----------------------------------------------------------------
-
-Now we can model meta-data as follows:
-
-[source,listing]
-.Metadata Properties
-----------------------------------------------------------------
-[a.b].info=An area info
-[a.b.Foo].auth=role1,role2
-[a.b.Foo].encrypt=PGP
-[a.b.Foo].sensitive=true
-[].info=This is a test configuration example.
-----------------------------------------------------------------
-
-The above would model the following:
-
-* The area +a.b+ has the meta property +info+.
-* The entry +a.b.Foo+ has three meta properties +auth,encrypt+ and +sensitive+. These could be interpreted by a security
-  view and used to encrypt the values returned by the configuration instance, if not the current user has one of the
-  specified roles.
-* The last meta data defines an attribute +info+ for the whole provider/configuration (the root area).
-
-Given that the overall entries would be as follows:
-
-[source,listing]
-.Full Properties with Meta Properties
-----------------------------------------------------------------
-[a.b].info=An area info
-a.b.Foo=foo
-[a.b.Foo].auth=role1,role2
-[a.b.Foo].encrypt=PGP
-[a.b.Foo].sensitive=true
-a.b.Bar=bar
-[].info=This is a test configuration example.
-a.AnyOther=whatelse
-Something=none
-----------------------------------------------------------------
-
-The current +MetaInfo+ class could be adapted, so it is reading data from the underlying configuration/provider,
-instead of its own datastructure. This would make a later mapping of configuration and its metadata into DB table, JSON
-etc, much more easier.
-The providers on the other side may suppress any metadata from ordinary output, such
-as +toString()+, Similarly accessing metadata using the official config API (+get, getOrDefault, getAreas+ etc)
-should be disabled. The +MetaInfoBuilder+ must probably as well adapted or redesigned.
-
-
-
-=== Management Client
-
-A nice web-based client to manage configuration data would be nice as well. This also includes a UI for creating new
-configurations.
-
-=== Mapping Configuration to a Database
-
-A flexible mechanism should be implemented that allows the use of databases (SQL/JPA as well as non-SQL) for
-storing/retreiving/managing configuration:
-
-* JPA, Hibernate
-* MongoDB
-* ...
-
-
-=== Integration with Jigsaw
-
-Once Jigsaw is mature and in a usable (still early) stage, examples are to be created and tested, where OSGI is used as
-the basic runtime platform, e.g. Apache Felix, but as well others.
-
-== Distributed/Remote Configuration Support
-
-=== Configuration Distribution Policies
-
-Different configuration distribution policies should be defined any implemented, e.g. distributed cache, restful services,
-web services, EJB/RMI calls, asynchronous queues, publish/subsribe models, ...
-
-
-=== Preferences Support
-
-Write a +PreferencesFactory+ for +java.util.preferences+.
-
-
-== Third Party Integration
-
-=== Integration with Deltaspike Config
-
-Integration with Deltaspike Config should be implemented and discussed with Deltaspike guys.
-
-=== Integration with Spring
-
-A {name} module should be created that allows Spring to be used either as client or configuration provider.
-
-=== Integration with Jetty
-
-A {name} module should be created that allows a Jetty instance to be deployed and started that is (completely)
-configured based on configuration server.
-
-=== Integration with Tomcat
-
-A {name} module should be created that allows a Tomcat instance to be deployed and started that is (completely)
-configured based on configuration server.
-
-=== Configuration of Java EE
-
-In the Java EE area there would be several options:
-
-=== Configuration of Application Servers (administrative resources)
-
-It should be possible to start a application server instance remotely and configure all administrative resources and the
-deployments based on the configuration service, server to be considered maybe
-
-* Wildfly
-* IBM
-* Weblogic
-* Glassfish
-* Apache Geronimo
-
-==== Configuration of Bean Validation
-
-* Add configurable validators.
-* Configure bean validation based on configuration
-* ...
-
-=== JNDI Support
-
-Write a +JCA+ adapter to provide configuration data through JNDI.
-
-==== Configure JSF
-
-Use the JSF +XML Document+ event to completely configure JSF.
-
-==== Configure Web Services
-
-Provide a WebServiceProviderFactory that may be configured.
-
-==== Configure JPA
-
-Provide an implementation that allows configuration of persistence units. Talk with JPA EG people to see if we can
-get an SPI to hook in a stadardized way.
-
-==== Configure EJBs
-
-Provide an implementation that allows configuration of EJBs and MDBs:
-
-* Register beans
-* Unregister/disable beans
-* Intercept beans
-* Support Configuration Injection (in the worst case using a standard Interceptor, provide supporting artifacts to
-  help developers to achive this easily).
-* Talk with EE8 Umbrella EG (Bill Shanon, Linda DeMichels) on a feasible SPI for EE8, if possible join the EG.
-
-==== Configure ...
-
-Just think of any Java EE aspects that might be worth to be configured. If it can be done, e.g. by managing CDI managed
-resources, it might be easy. For others it is a good idea to discuss things with our matter of experts...
-
-== Special Goodies
-
-=== Maintenance Mode Servlet Filter
-
-Provide a servlet filter that is capable of switching to maintenance mode, based on configuration. Similarly also a forwarding
-servlet could be useful, wehere only request based on configuration are forwarded, other might be rejected or dropped
-as configured.
-
-=== Dynamic Camel Routes
-
-Provides dynamic (configurable) Camel routes, e.g. usable within ServiceMix or standalone.
-
-=== Dynamic CXF
-
-Provides dynamic (configurable) CXF adapters, e.g. usable within ServiceMix or standalone.
-
-=== Configurable Apache MQ
-
-Provides an implementation for configuring Apache MQ.
-
-=== Dynamic ...
-
-Interested to see what other ideas are around. Let us know!
-

http://git-wip-us.apache.org/repos/asf/incubator-tamaya/blob/63124d1f/src/site/asciidoc/quickstart.adoc
----------------------------------------------------------------------
diff --git a/src/site/asciidoc/quickstart.adoc b/src/site/asciidoc/quickstart.adoc
deleted file mode 100644
index c18a15e..0000000
--- a/src/site/asciidoc/quickstart.adoc
+++ /dev/null
@@ -1,206 +0,0 @@
-// Licensed to the Apache Software Foundation (ASF) under one
-// or more contributor license agreements.  See the NOTICE file
-// distributed with this work for additional information
-// regarding copyright ownership.  The ASF licenses this file
-// to you under the Apache License, Version 2.0 (the
-// "License"); you may not use this file except in compliance
-// with the License.  You may obtain a copy of the License at
-// .
-//   http://www.apache.org/licenses/LICENSE-2.0
-// .
-// Unless required by applicable law or agreed to in writing,
-// software distributed under the License is distributed on an
-// "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
-// KIND, either express or implied.  See the License for the
-// specific language governing permissions and limitations
-// under the License.
-
-include::temp-properties-files-for-site/attributes.adoc[]
-
-== Apache Tamaya: Quickstart
-
-
-The fastest way to start with Tamaya is just using the _Core_ implementation,
-implementing the **API** in small, minimalistic way. For that add the following
-Maven dependency to your project:
-
-
-[source,xml,subs="verbatim,attributes"]
-----
-<dependency>
-    <groupId>{tamaya_mvn_group_id}</groupId>
-    <artifactId>tamaya-core</artifactId>
-    <version>{tamaya_version_released}</version>
-</dependency>
-----
-
-Given that you can add your configuration properties to the following locations in your classpath:
-
-[source]
-----
-META-INF/javaconfiguration.properties
-----
-
-Additionally also system properties are taken into account, hereby overriding the default properties. Overall
-Tamaya by default defines the following configuration model per default (most significant first):
-
-. System Properties
-. `META-INF/javaconfiguration.properties`
-
-There many modules that extend the capabilities of Tamaya.
-These modules doe not depend on core, so alternative
-implementations of the Tamaya API should work similarly.
-
-
-=== Multiple configuration files
-
-By default you can provide multiple `javaconfig.properties` files, e.g. as part
-of multiple jars loaded into your system. The system internally creates one
-`PropertySource` for each file found on the classpath. All `PropertySource`
-instances created are ordered by their ordinal value (an int).
-
-Tamaya Core defines the following default ordinals (used, if no custom ordinal is defined):
-
-[width=70]
-[cols="3,1", option="headers"]
-|===
-| Source                            | Ordinal
-| System Properties                 | 400
-| Environment Variables             | 300
-| Java Configuration Properties     | 100
-|===
-
-That means that the value of a configuration variable `x` overhanded via `-Dx=yes` has
-a higher precedence then the entry for configuration variable `x` specified in a `javaconfig.properties`
-as `x=no`.
-
-These ordinal values can be either hardcoded, or be dynamically
-configurable as key within each configuration resource. The ladder can be done by defining a special
-Tamaya ordinal value as follows:
-
-
-[source]
-----
-# override default Tamaya ordinal for property files
-tamaya.ordinal=123
-----
-
-This assigns an ordinal of 123 to each entry in that configuration resource.
-
-=== Using additional features of Tamaya
-
-There many modules that extend the capabilities of
-Tamaya. These modules doe not depend on core, so alternative
-implementations of the Tamaya API should work similarly. Following a
-small extract of most important modules available (or available soon):
-
-==== Dynamic Resolution and Value Placeholders
-
-[source,xml,subs="verbatim,attributes"]
-----
-<dependency>
-  <artifactId>org.apache.tamaya.ext</id>
-  <artifactId>tamaya-resolver</artifactId>
-  <version>{tamaya_version_development}</version>
-</dependency>
-----
-
-// @todo Auf Modulliste verweisen für vollständigen Überblick
-With that it is possible to define values with Unix styled placeholders that are
-resolved on configuration access, e.g.
-`mykey=my${dynamicValue}´. For further details refer to the module documentation.
-This module also provides a `Resolver` singleton:
-
-[source,java]
-----
-String myExpression = ...;
-String resolved = Resolver.evaluateExpression(myExpression);
-----
-
-
-==== Ant-styled Path Resolution of Resources
-
-[source,xml,subs="verbatim,attributes"]
-----
-<dependency>
-  <artifactId>org.apache.tamaya.ext</id>
-  <artifactId>tamaya-resolution</artifactId>
-  <version>{tamaya_version_development}</version>
-</dependency>
-----
-
-This module provides a `Resolver` singleton that allows to
-resolve configuration resources using a ant-styled resource
-description, e.g.
-
-
-[source,xml,subs="verbatim,attributes"]
-----
-Collection<URL> urls = ResourceResolver.getResources("META-INF/cfg/**/*.properties");
-----
-
-For further details refer to the module documentation.
-
-
-==== Configuration Injection
-
-[source,xml,subs="verbatim,attributes"]
-----
-<dependency>
-  <artifactId>org.apache.tamaya.ext</id>
-  <artifactId>tamaya-inject</artifactId>
-  <version>{tamaya_version_development}</version>
-</dependency>
-----
-
-With this extension you can let Tamaya inject configuration into instances of
-annotated classes or let Tamaya implement a configuration template.
-
-Corresponding configuration:
-
-[source,xml,subs="verbatim,attributes"]
-----
-public class MyType {
-   @ConfiguredProperty("name")
-   private String typeName;
-
-   public String getName() {
-      return name;
-   }
-}
-
-MyType type = new MyType();
-ConfigurationInjector.configure(type);
-----
-
-Or the same as template:
-
-[source,xml,subs="verbatim,attributes"]
-----
-public interface MyTypeTemplate {
-   @ConfiguredProperty("name")
-   public String getName();
-}
-
-MyTypeTemplate type = ConfigurationInjector.createTemplate(MyTypeTemplate.class);
-----
-
-Currently the following resolvers are available:
-
-[width="60"]
-[cols="1,4"]
-|===
-| Conf
-| Cross-reference to another configuration entry
-
-| URL
-| Referencing a resource addressable by an URL.
-
-| File
-| Reference to a  file, replacing the expression with the file's text value.
-
-| Resource
-| Reference to classpath resource, replacing the expression with the resource's text value.
-
-|===
-

http://git-wip-us.apache.org/repos/asf/incubator-tamaya/blob/63124d1f/src/site/asciidoc/release-guide.adoc
----------------------------------------------------------------------
diff --git a/src/site/asciidoc/release-guide.adoc b/src/site/asciidoc/release-guide.adoc
deleted file mode 100644
index 4d2f7de..0000000
--- a/src/site/asciidoc/release-guide.adoc
+++ /dev/null
@@ -1,274 +0,0 @@
-// Licensed to the Apache Software Foundation (ASF) under one
-// or more contributor license agreements.  See the NOTICE file
-// distributed with this work for additional information
-// regarding copyright ownership.  The ASF licenses this file
-// to you under the Apache License, Version 2.0 (the
-// "License"); you may not use this file except in compliance
-// with the License.  You may obtain a copy of the License at
-// .
-//   http://www.apache.org/licenses/LICENSE-2.0
-// .
-// Unless required by applicable law or agreed to in writing,
-// software distributed under the License is distributed on an
-// "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
-// KIND, either express or implied.  See the License for the
-// specific language governing permissions and limitations
-// under the License.
-
-include::temp-properties-files-for-site/attributes.adoc[]
-
-:sectnums: yes
-
-= Apache Tamaya: Release Guide
-
-Performing a release requires several steps. This document describes each step, so everybody in the committer's
-team should be able to perform the release procedure.
-
-
-== Tell the others you would proceed with the release procedure
-
-[listing,text]
-----
-first steps for the next release
-
-Hi @ all,
-
-If there are no objections, I'll start with the first steps for
-the next release (review, documentation,...).
-It would be great to start with the release procedure next week.
-
-Best regards,
-[name]
-----
-
-== Check everything is ready
-
-* Check the jenkins builds.
-* Ensure all JIRA-tickets targeting the release are resolved. If not, get in contact with the ticket
-  owner/assignee to check
-  ** if the ticket can be postponed for the next release
-  ** how long it takes to resolve it and if one can help.
-
-
-== Prepare the release
-
-* Create release notes and commit them to `tamaya/readme/` (format `ReleaseNotes-[version].html`)
-* Create a release branch in git and switch to this branch:
-
-
-=== Using the Release Plugin
-
-For performing the release you can use the maven release plugin:
-
-[listing,text]
-----
-$ git checkout -b vote-tamaya-[release version]
-$ export MAVEN_OPTS="-Xmx512m -XX:MaxPermSize=200m"
-$ mvn release:prepare -DdryRun=true -DperformRelease=true
-# optionally pass GPG params for signing with: -Darguments="-Dgpg.keyname=1336D3E6 -Dgpg.passphrase=XXXXXX"
-# copy prepared workspace (to continue faster if an upload fails in the next step)
-----
-
-* If something fails you may switch to the master branch, fix whatever is needed and rebase your release branch to
-  accommodate the latest changes done.
-* On success you can check the release packages from `dist/target`.
-* If everything looks good you can proceed with the release:
-
-[listing,text]
-----
-$ export MAVEN_OPTS="-Xmx512m -XX:MaxPermSize=200m"
-$ mvn release:prepare -DperformRelease=true
-$ mvn release:perform -DperformRelease=true
-----
-
-=== Preparing the release without the Release Plugin
-
-The release plugin is great, but in some cases it breaks even, when release:prepare -DdryRun=true was successful.
-Preparing the release vote without the release plugin is stright forward:
-
-* As described checkout a release branch of the current head
-* Then us maven and git commands to prepare the release:
-
-[listing,text]
-----
-$ git checkout -b vote-tamaya-[release version]
-$ export MAVEN_OPTS="-Xmx512m -XX:MaxPermSize=200m"
-$ mvn versions:set versions:commit -DnewVersion=[release version] -DperformRelease=true
-# build the release locally and sign it with your certs
-$ mvn clean install -DperformRelease=true -Dgpg.keyname=1336D3E6 -Dgpg.passphrase=XXXXXX
-----
-
-* Check if everything is in place and correct, when finished you can tag and deploy the release...
-
-[listing,text]
-----
-$ mvn deploy -DperformRelease=true -Dgpg.keyname=1336D3E6 -Dgpg.passphrase=XXXXXX
-----
-
-* check the created commits including user-name and email
-* login to https://repository.apache.org/[^] and go to "Staging Repositories"
-* check the contents of the newly created tamaya staging repository
-* _close_ the repository to let Nexus do its validations
-* On success:
-* push the release-branch to the git repo
-
-[listing,text]
-----
-$ git add -A
-$ git commit -m "Release Prepare: Set release version."
-$ git tag vote01-[release-version]
-$ git push --tags
-----
-
-Finally open the next development version:
-
-[listing,text]
-----
-# example: newVersion=0.3-incubating-SNAPSHOT
-$ mvn version:set versions:commit -DnewVersion=[development-version]
-$ git add -A
-$ git commit -m "Release Prepare: Open new development version."
-----
-
-
-
-* Add the distribution artifacts to the dev repositories:
-
-[listing,text]
-----
-$ svn co https://dist.apache.org/repos/dist/dev/incubator/tamaya/
-$ mkdir [version]
-$ set RELEASE_HOME='pwd'/[version]
-$ cd PROJECT_ROOT
-$ cp DISCLAIMER $RELEASE_HOME
-$ cp NOTICE $RELEASE_HOME
-$ cp LICENCE $RELEASE_HOME
-$ cp rat.txt $RELEASE_HOME
-# Copy everything from
-#  $STAGING_REPO/distribution/0.2-incubating/tamaya-distribution-[version]-distribution-* into $RELEASE_HOME
-$ svn add [version]
-$ svn commit --username <apacheId>
-----
-
-* Check contents on https://dist.apache.org/repos/dist/dev/incubator/tamaya/[version]
-
-
-== Start the vote
-
-[listing,text]
-----
-[VOTE] Release of Apache Tamaya [version]
-
-Hi,
-
-I was running the needed tasks to get the [version] release of Apache Tamaya out.
-The artifacts are deployed to Nexus [1] (and [2]) and releases [4].
-
-The tag is available at [3] and will renamed once the vote passed.
-
-Please take a look at the artifacts and vote!
-
-Please note:
-This vote is a "majority approval" with a minimum of three +1 votes (see [5]).
-
-------------------------------------------------
-[ ] +1 for community members who have reviewed the bits
-[ ] +0
-[ ] -1 for fatal flaws that should cause these bits not to be released, and why..............
-------------------------------------------------
-
-Thanks,
-[name]
-
-[1] https://repository.apache.org/content/repositories/...
-[2] https://repository.apache.org/content/repositories/org/apache/tamaya/tamaya-distribution/[version]/tamaya-[version]-source-release.zip
-    https://repository.apache.org/content/repositories/org/apache/tamaya/tamaya-distribution/[version]/tamaya-[version]-bin-release.zip
-[3] https://git1-us-west.apache.org/repos/asf?p=incubator-tamaya.git;a=commit;h=2910da468fce16210e6dd77d8ba23ddbdd434efe
-[4] https://dist.apache.org/repos/dist/dev/incubator/tamaya/[release-version]
-[5] http://www.apache.org/foundation/voting.html#ReleaseVotes
-----
-
-* Announce the Vote
-  ** Create a short link to the release at http://s.apache.org (format Tamaya_[version])
-  ** Tweet about the vote via _@TamayaConf_
-
-* After 72 hours close the vote write a reult email, e.g.
-
-[listing,text]
-----
-[Result] (was: Re: [VOTE] Release of Apache Tamaya [version])
-
-Thank you for voting!
-
-X binding +1 votes (pmc):
-[list]
-
-Y non-binding +1 votes:
-[list]
-
-Z -1 votes
-[list]
-----
-
-* After the vote on the PPMC has been finished and is successful, repeat the voting process on the
-  incubator mailing list.
-
-
-== Perform the release
-
-If the binding majority approved the vote on both lists continue:
-
-* Login to https://repository.apache.org/ and _release_ the repository
-* Rename the vote branch:
-
-[listing,text]
-----
-$ git branch -m vote01-tamaya-[release-version] tamaya-[release-version]
-----
-
-* Add a release tag:
-
-----
-$ git tag -a tamaya-[release-version]
-----
-
-* Merge master with the new prepared version:
-
-[listing,text]
-----
-$ git checkout master
-$ git merge tamaya-[release-version]
-$ git push origin tamaya-[release-version]
-$ git push origin master
-----
-
-* Close the release and corresponding tickets at JIRA
-
-* Wait some minutes and check http://repo2.maven.org/maven2/org/apache/tamaya[^]
-
-* Upload the distribution Artifacts
-
-[listing,text]
-----
-$ svn co https://dist.apache.org/repos/dist/release/incubator/tamaya/
-$ mkdir [version]
-# add and commit the artifacts (*source-release.zip, *bin-release.zip + asc, md5, sha1)
-# use the artifacts from:
-# http://repo1.maven.org/maven2/org/apache/tamaya/tamaya-distribution/[version]/
-----
-
-
-== Updating the Tamaya Project Site
-
-Basically the new site should be directly deployable, just execute
-
-[listing,text]
-----
-$ mvn site site:deploy
-----
-
-
-== Announce the new version
-
-Announce the new version on @TamayaConf and other social media channels.
-Also drop a short mail on the amiling list.

http://git-wip-us.apache.org/repos/asf/incubator-tamaya/blob/63124d1f/src/site/asciidoc/source.adoc
----------------------------------------------------------------------
diff --git a/src/site/asciidoc/source.adoc b/src/site/asciidoc/source.adoc
deleted file mode 100644
index fb1361a..0000000
--- a/src/site/asciidoc/source.adoc
+++ /dev/null
@@ -1,39 +0,0 @@
-// Licensed to the Apache Software Foundation (ASF) under one
-// or more contributor license agreements.  See the NOTICE file
-// distributed with this work for additional information
-// regarding copyright ownership.  The ASF licenses this file
-// to you under the Apache License, Version 2.0 (the
-// "License"); you may not use this file except in compliance
-// with the License.  You may obtain a copy of the License at
-// .
-//   http://www.apache.org/licenses/LICENSE-2.0
-// .
-// Unless required by applicable law or agreed to in writing,
-// software distributed under the License is distributed on an
-// "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
-// KIND, either express or implied.  See the License for the
-// specific language governing permissions and limitations
-// under the License.
-
-include::temp-properties-files-for-site/attributes.adoc[]
-
-:sectnums: yes
-
-= Apache Tamaya: Sources
-
-== Source Code Repositories
-
-The current source code can be found at:
-
-    - http://git-wip-us.apache.org/repos/asf/incubator-tamaya.git (read-only)
-    - https://git-wip-us.apache.org/repos/asf/incubator-tamaya.git
-
-Alternatively there is also a GitHub read-only mirror at
-https://github.com/apache/incubator-tamaya[https://github.com/apache/incubator-tamaya^].
-
-The GitHub mirror also provides the project as downloadable zip archive.
-
-== Contributions
-
-If you like to contribute to Apache Tamaya please also refer also to our
-<<devguide.adoc#contributing-workflow,section on contributing to Apache Tamaya>>.

http://git-wip-us.apache.org/repos/asf/incubator-tamaya/blob/63124d1f/src/site/asciidoc/usecasesAndReqs.adoc
----------------------------------------------------------------------
diff --git a/src/site/asciidoc/usecasesAndReqs.adoc b/src/site/asciidoc/usecasesAndReqs.adoc
deleted file mode 100644
index 66ee0dc..0000000
--- a/src/site/asciidoc/usecasesAndReqs.adoc
+++ /dev/null
@@ -1,505 +0,0 @@
-// Licensed to the Apache Software Foundation (ASF) under one
-// or more contributor license agreements.  See the NOTICE file
-// distributed with this work for additional information
-// regarding copyright ownership.  The ASF licenses this file
-// to you under the Apache License, Version 2.0 (the
-// "License"); you may not use this file except in compliance
-// with the License.  You may obtain a copy of the License at
-//
-//   http://www.apache.org/licenses/LICENSE-2.0
-//
-// Unless required by applicable law or agreed to in writing,
-// software distributed under the License is distributed on an
-// "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
-// KIND, either express or implied.  See the License for the
-// specific language governing permissions and limitations
-// under the License.
-
-include::temp-properties-files-for-site/attributes.adoc[]
-
-== Apache Tamaya: Use Cases and Requirements
-
-toc::[]
-
-== Use Cases
-
-=== Simple Access
-
-Users want to be able to access configuration in a unified way both in SE and EE. EE may provide additional
-mechanism, such as injection, but the SE mechanisms should work as well, so any code written in SE is fully
-portable to EE as well.
-This can only be achieved by providing a static accessor, e.g.
-
-[source,java]
-------------------------------------------------------------
-Configuration config = Configuration.current();
-------------------------------------------------------------
-
-The call above should work exactly the same in EE. To enable this the static call must be delegated in the
-internals of the singleton, depending on the runtime. In EE the executing component can behave contextually,
-or even be loaded within the CDI environment (at least for post loading, application runtime aspects, but not earlier).
-
-Additionally in EE it should also be possible to inject Configuration, which gives you the same results as the call
-above:
-
-[source,java]
-------------------------------------------------------------
-@Inject
-private Configuration cfg;
-------------------------------------------------------------
-
-
-=== Simple Lookup of Properties
-
-Users just want to create a configuration ad hoc, from given property files. The
-files could be locally in the file system, on the classpath.
-
-Tamaya should provide a simple Java API for accessing key/value based configuration. Hereby users want to access
-properties as simple String values.
-
-Hereby returning Java 8 Optional values must be considered as well, instead of returning +null+.
-
-
-=== Value Placeholders
-
-Users just want to to be able to add placeholders to the values of configuration (not the keys). The mechanisms for
-resolving the placeholders hereby should be not constraint to one single lanmguage like EL. Instead of different
-replacement strategies should be selectable, e.g. by prefixing an expression with the name of the resolver that
-should do the work (eg +"blabla ${env:HOME} using Java version ${sys:java.version}."+.
-This allows resolution mechanism to be isolated easily and also allows to use simpler mechanisms, if no more complex
-ones like EL are required. This is especially useful to deal with low resource environment like ME.
-
-
-=== Type Safe Properties
-
-Users just want to access properties not only as Strings, but let Tamaya do the conversion to the required
-or the configred target type. By defauklt all java.ui.lang wrapper and primitive types should be supported, but also
-other common types like date/time types, math numeric types and more.
-
-It must be possible that users can register their own custom types.
-
-Finally users also want to be able to dynamically provide or override type adaption (conversion), when reading a value,
-for a certain key/value pair.
-
-
-=== Configuration Templates
-
-Users want to be able to let Tamaya implement an interface template based on configuration.
-This use case is pretty similar to the injection use case. Basically the values are not injected,
-but cached within the template proxy returned, e.g. as +DynamicValue+.
-Similarly it could even be possible to define callback methods (default methods)
-or register listeners to DynamicValue instances returned.
-
-Templates hereby can easily be managed, but provide a excellent mechanism to provide type-safe configuration
-to clients in a very transparent way. Details can be controlled by using the same annotations as for
-normal configuration injection.
-
-
-=== Java 8 Functional Support
-
-Users want to be able to benefit from the new programming styles introduced with Java 8. Configuration
-should provide extension points for different aspects, where additional code can be hooked in easily.
-In short: were possible functional interfaces should be modelled.
-
-Examples:
-
-* code that converts a configuration to another kind of configuration: +UnaryOperator<Configuration>+
-* code that creates any kind of result based on a configuration: +Function<Configuration,T>+
-* Adapters for type conversion are defined as +Function<String,T>+
-* Key, value filters ccan be modelled as +BiFunction<String,String,String>+
-* etc.
-
-
-=== Configuration Locations
-
-Users want to be able to
-
-* read configuration from different locations.
-* By default classpath and file resources are
-  supported. But similarly remote access using a JSON ReST call should be possible.
-* Tamaya should define a JSON and XML format for configuration.
-* Configuration locations should be scannable using ant-styled resource patterns, if possible.
-* Scanning and reading logic can be modularized by using a +ConfigReader+ interface.
-
-
-=== Configuration Formats
-
-Users want to be able to use the format they prefer.
-
-* properties, xml-properties and ini-format should be supported by default
-* Other/custom formats should be easily addable by registering or providing the format on configuration evaluation (read).
-* When possible Tamaya should figure out which format to be used and how the InputStream should be correctly
-  interpreted.
-
-
-=== Multiple Configurations
-
-When systems grow they must be modularized to keep control. Whereas that sounds not really fancy, it leads to additional
-aspects to be considered by a configuration system.
-
-* Different code modules, libraries, plugins or products want to have their "own" separated configuration.
-* Similar it should be possible to add fully specific additional configurations.
-
-The default configuration hereby should always be present, whereas additional configurations are optional.
-Users want to be able to check the availability of such an additional configuration.
-
-Of course, additional configuration must be identifiable. The best way to do is to be discussed, nevertheless the
-mechanism must not depend on Java EE and the identifying keys must be serializable easily.
-Basically simple names are sufficient and woukld provide exact this required functionality.
-
-
-=== External Configuration
-
-Users want to be able to replace, override, extend or adapt any parts or all of an existing configuration from
-external sources.
-This also must be the case for multi-context environments, where the context identifiers are
-the only way to link to the correct remote configuration.
-
-
-=== Context Dependent Configuration
-
-In multi tenancy setups or complex systems a hierarchical/graph model of contexts for configurations is required, or different runtime contexts are executed in parallel
-within the same VN. What sounds normal for EE also may be the case for pure SE environments:
-
-* Users want to be able to model different layers of runtime context
-* Users want to identiofy the current layer, so configuration used may be adapted.
-
-
-
-=== Dynamic Provisioning (UC8)
-
-In Cloud Computing, especially the PaaS and SaaS areas a typical use case would be that an application (or server)
-is deployed, configured and started dynamically. Typically things are controlled by some "active controller components",
-which are capable of
-
-* creating new nodes (using IaaS services)
-* deploying and starting the required runtime platform , e.g. as part of a PaaS solution.
-* deploying and starting the application modules.
-
-All these steps require some kind of configuration. As of today required files are often created on the target node
-before the systems are started, using proprietary formats and mechanism. Similarly accessing the configuration in place
-may require examining the file system or using again proprietary management functions. Of course, a configuration
-solution should not try to solve that, but it can provide a significant bunch of functionality useful in such scenarios:
-
-* provide remote capabilities for configuration
-* allow configuration to be updated remotely.
-* allow client code to listen for configuration changes and react as needed.
-
-
-=== Minimal Property Source SPI
-
-Users expect that implementing an additional configuration property source is as easy as possible.
-So there should be an SPI defined that allows any kind of data source to be used for providing configuration data.
-The interface to be implemented is expected to be minimal to reduce the implementation burden. Default
-methods should be used where possible, so only a few methods are expected to be required to implement.
-
-
-=== Scannable Properties
-
-If possible configuration should be scannable, meaning it should be possible to evaluate the keys available.
-The corresponding capabilities should be accessible by a +isScannable()+ method.
-
-
-=== Combine Configurations
-
-Users want to be able to combine different configurations to a new configuration instance.
-Hereby the resulting configuration can be
-
-* a union of both, ignoring duplicates (and optionally log them)
-* a union of both, duplicates are ignored
-* a union of both, conflicts are thrown as ConfigException
-* an intersection of both, containing only keys present and equal in both configurations
-* an arbitrary mapping or filter, modelled by an +CombinationPolicy+, which basically can be modelled
-  as +BiFunction<String, String, String>+, hereby
-  ** a result of +null+ will remove the key
-  ** any other result will use the value returned as final value of the combination.
-
-
-=== MX/ReST Management
-
-Users want to be have comprehensive management support, which should allow
-
-* to change configuration
-* to remove configuration
-* to view configuration and its provider details
-
-
-=== Adaptable Service Context
-
-Tamaya should support an adaptable +ServiceContext+ to resolve any kind of implememntation services, both API services as core
-framework services. The +ServiceContext+ should be dynamically replecable by configuring an alternate instance of
-using the Java *ServiceContet+.
-
-This decouples component usage from its load and management part and als greatly simplifies integration with
-new/alternate runtime environments.
-The service context is exptected to provide
-
-* single singleton instances: these service can be cached.
-* access to multiple instances which implement some commons SPI interface.
-* as useful priorization of components is done by the model itself.
-
-
-=== Configuration Injection
-
-Users want to be able to polulate configured items by injecting configured values. Hereby
-
-* the lifecycle of the instances is not managed by Tamaya
-* all references to items configured are managed as weak references, to prevent memoryleaks.
-* Injection should if possible evaluate the properties by defaults. Even properties without
-  any annotations are possible.
-* Users expect to exclude certain properties from calculation
-* Beside injection of properties it is also possible to call setter methods with one parameter similarly.
-* Basically injection is performed, when the instance is passed to the Tamaya configuration system. It should also
-  be possible to inject/provide final values, especially Strings. Changes on configured values should be
-  reflected in the current value. Setters methods similarly can be called again, with the new values, on changes.
-* Users expect to control dynamic values and recall of setter methods, basically the following strategies should be
-  supported:
-  ** inject only once and ignore further changes.
-  ** reinject/reinitialize on each change
-
-* Dynamic Values can easily be modeled as +ConfiguredValue+ instances, which should have the following functionality:
-  ** access the current value
-  ** access the new value
-  ** access the latest value access time in ms
-  ** access the latest value update time in ms
-  ** evaluate easily if the value has changed since the last access
-  ** accept the change
-  *** as a shortcut it should be possible to accept the change on access of the value implicitly, hereby always accessing
-      the latest valid value.
-  ** ignore the change
-  ** register +Consumer<DynamicValue>+ liasteners to listen on the changes (ans also removing them later again).
-
-All observing functionality can be done completely asynchronously and in parallel.
-
-
-[[Requirements]]
-== Requirements
-=== Core Configuration Requirements
-==== General
-
-Tamaya must provide a Java SE API for accessing key/value based configuration. Hereby
-
-* +Configuration+ is modelled by an interface
-* +Configuration+ is organized as key/value pairs, using a subset of functionality present on +Map<String,String>+ as
-  follows:
-  ** access a value by key (+get+)
-  ** check if a value is present (+containsKey+)
-  ** get a set of all defined keys (+keySet+)
-  ** a configuration must be convertible to a +Map+, by calling +toMap()+
-  ** a configuration must provide access to its meta information.
-* +Configuration+ value access methods must never return null.
-* The API must support undefined values.
-* The API must support passing default values, to be returned if a value is undefined.
-* The API must allow to throw exceptions, when a value is undefined. Customized exceptions hereby should be supported.
-* Properties can be stored in the classpath, on a file or accessible by URL.
-* Properties can be stored minimally in properties, xml-properties or ini-format.
-
-
-==== Minimalistic Property Source
-
-For enabling easy integration of custom built configuration sources a minimalistic API/SPI must be defined, that
-
-* is modelled by an interface
-* is a minimal subset of +Configuration+ necessary to implement a configuration.
-* must be convertible to a "Configuration+.
-
-==== Extension Points
-
-For supporting more complex scenarios, +Configuration+
-
-* must implement the composite pattern, meaning new +Configuration+ instances can be created by combining existing
-  configurations.
-* must be adaptable, by creating a new configuration by applying a +UnaryOperator<COnfiguration>+ to it.
-* must be queryable, by passing a +ConfigQuery+ to an +Configuration+ instance.
-
-
-==== Type Safety
-
-Besides Strings +Configuration+ should also support the following types:
-
-* Primitive types
-* Wrapper types
-* All other types (by using a +PropertyAdapter+
-
-Hereby type conversion should be done as follows:
-
-. Check if for the given target type an explicit adapter is registered, if so, use the registered adapter.
-. If no adapter is present, check if the target type T has static methods called +T of(String), T getInstance(String), T valueOf(String), T from(String)+. If so
-use this method to create the non value of T.
-. Check if the target type has a constructor T(String). If so, try to instantiate an instance using the constructor.
-. Give up, throw a IllegalArgument exception.
-
-=== Configuration Fomats
-
-By default Tamaya support the following configuration formats:
-
-* .properties
-* .xml properties
-* .ini files
-
-It must be possible to add additional formats by registering them with the current +ServiceContext+.
-
-=== Mutability
-
-* Configurations can be mutable, mutability can be accessed as a property.
-* Configuration can be changed by collecting the changes into a +ConfigCHangeSet+ and apply this set to the
-  given +Configuration+ instance.
-* Besides the points above, +Configuration+ is immutable.
-
-=== Serializability and Immutability of Configuration
-
-* Configuration is modelled as a service. Therefore serialization may not work. This can be mitigated by adding
-  a freeze feature, where the know key/value pairs are extracted into an immutable and serializable form.
-
-=== Configuration Combination Requirements
-
-At least the following composition policies must be supported:
-
-* override: subsequent entries override existing ones.
-* aggregate-exception: key/values were added, in case of conflicts a +ConfigException+ must be thrown.
-* aggregate-ignore-duplicates: similar to union, whereas duplicates are ignored (leaving the initial value loaded).
-* aggregate-combine: conflicting entries were resolved by adding them both to the target configuration by
-  redefining partial keys.
-* custom: any function determining the key/values to be kept must be possible
-
-When combining configuration it must also be possible to override (file/classpath) configuration by
-
-* system properties.
-* command line arguments.
-
-
-=== Configuration Injection
-
-As metnioned configuration can be injected by passing a unconfigured instance of an annotated class to the
-+Configuration.configure+ static method:
-
-[source, java]
-.Configuring a POJO
-----------------------------------------------------
-MyPojo instance = new MyPojo();
-Configuration.configure(instance);
-----------------------------------------------------
-
-Hereby
-* It must be possible to define default values to be used, if no valid value is present.
-* It must be possible to define dynamic expressions, at least for default values.
-* The values configured can be reinjected, if the underlying configuration changes. This should also be the case
-  for final classes, such as Strings.
-* Reinjection should be controllable by an loading policy.
-* It must be possible to evaluate multiple keys, e.g. current keys, and as a backup deprecated keys
-  from former application releases.
-* It must be possible to evaluate multiple configurations.
-* The type conversion of the properties injected must be configurable, by defining a +PropertyAdapter+.
-* The value evaluated for a property (before type conversion) must be adaptable as well.
-* It must be possible to observe configuration changes.
-
-The following annotations must be present at least:
-
-* *@ConfiguredProperty* defining the key of the property to be evaluated. It takes an optional value, defining the
-  property name. It must be possible to add multiple annotations of this kind to define an order of evaluation
-  of possible keys.
-* *@DefaultValue* (optional) defines a default String value, to be used, when no other key is present.
-* *@WithConfig* (optional) defines the name of the configuration to be used. Similar to +@ConfiguredProperty+ multiple
-  configuration can be defined for lookup.
-* *@WithConfigOperator* allows to adapt the String value evaluated, *before* it is passed as input to injection or
-  type conversion.
-* *@WithPropertyAdapter* allows to adapt the conversion to the required target type, hereby overriding any default
-  conversion in place.
-* *@WithLoadPolicy* allows to define the policy for (re)injection of configured values.
-* *@ObservesConfigChange* allows to annotate methods that should be called on configuration changes.
-* *@DefaultAreas" allows to define a key prefix key to be used for the configured key, if no absolute key
-  is defined.
-
-=== Configuration Templates
-
-For type safe configuration clients should be able to define an interface and let it implement by the
-configuration system based on +Configuration+ available:
-
-* Clients define an interface and annotate it as required (similar to above)
-* The interface methods must not take any arguments
-* The configuration system can be called to return such an interface implementation.
-* The configuration system returns a proxy hereby providing type-safe access the values required.
-* Similar to configured types also templates support multiple values and custom adapters.
-* It is possible to listen on configuration changes for templates, so users of the templates
-  may react on configuration changes.
-
-The following snippet illustrates the requirements:
-
-[source, java]
-.Type Safe Configuration Template Example
-----------------------------------------------------
-public interface MyConfig {
-
-  @ConfiguredProperty("myCurrency")
-  @DefaultValue("CHF")
-  String getCurrency();
-
-  @ConfiguredProperty("myCurrencyRate")
-  Long getCurrencyRate();
-
-  @ConfigChange
-  default configChanged(ConfigChange event){
-     ...
-  }
-
-}
-----------------------------------------------------
-
-Templates can be accessed by calling the +Configuration.current(Class)+ method:
-
-[source, java]
-.Accessing a type safe Configuration Template
-----------------------------------------------------
-MyConfig config = Configuration.current(MyConfig.class);
-----------------------------------------------------
-
-[[RequirementsServer]]
-=== Server Configuration Requirements
-
-* Ensure Configuration can be transferred over the network easily.
-* Beside serializability text based formats for serialization in +XML+ and +JSON+ must be defined.
-* A management API must be defined, which allows to inspect the configuration in place, e.g. using
-   JMX or REST services.
-
-[[RequirementsJavaEE]]
-
-Java EE leads to the following requirements:
-
-* Configuration must be contextual, depending on the current runtime context (e.g. boot level, ear, war, ...).
-* Hereby contextual aspects can even exceed the levels described above, e.g. for SaaS scenarios.
-* Resources can be unloaded, e.g. wars, ears can be restarted.
-* The different contextual levels can also be used for overriding, e.g. application specific configuration
-may override ear or system configuration.
-* Configuration may be read from different sources (different classloaders, files, databases, remote locations).
-* Configuration may be read in different formats (deployment descriptors, +ServiceLoader+ configuration, alt-DD feature, ...)
-* JSF also knows the concept of stages.
-* Many SPI's of Java EE require the implementation of some well defined Java interface, so it would be useful if the
-   configuration solution supports easy implementation of such instances.
-* In general it would be useful to model the +Environment+ explicitly.
-* Configuration used as preferences is writable as well. This requires mutability to be modelled in way, without the
-   need of synchronization.
-* JNDI can be used for configuration as well.
-
-[[RequirementsMultitenancy]]
-
-Configurations made in the tenant or user layer override the default app configuration etc., so
-
-* It must be possible to structure Configuration in layers that can override/extend each other.
-* The current environment must be capable of mapping tenant, user and other aspects, so a corresponding configuration
-  (or layer) can be derived.
-
-[[RequirementsExtensions]]
-=== Extensions Requirements
-
-It must be possible to easily add additional functionality by implementing external functional interfaces operating
-on +Configuration+.
-
-* +UnaryOperator<Configuration>+ for converting into other version of +Configuration+.
-* +ConfigQuery<T>+ extending +Function<T, Configuration>+.
-
-[[RequirementsNonFunctional]]
-=== Non Functional Requirements
-THe following non-functional requirements must be met:
-
-* tbd
-

http://git-wip-us.apache.org/repos/asf/incubator-tamaya/blob/63124d1f/src/site/markdown/index.md.vm
----------------------------------------------------------------------
diff --git a/src/site/markdown/index.md.vm b/src/site/markdown/index.md.vm
deleted file mode 100644
index 9c66599..0000000
--- a/src/site/markdown/index.md.vm
+++ /dev/null
@@ -1,54 +0,0 @@
-About Apache Tamaya
--------------------
-
-Apache Tamaya (incubating) provides a flexible and powerful
-configuration solution
-for Java developers using Java SE as well as for more complex 
-usage scenarios like cloud or Java EE. It provides a modern
-type-safe property based Configuration API combined with a 
-powerful environment model and a flexible SPI. 
-
-Features
---------
-
-* Unified Configuration API
-* Pluggable Configuration Backends
-* Enforceable Configuration Policies
-* Configuration Validation and Documentation
-* Seemless Enterprise Integration
-
-Documentation
--------------
-
-* [Use Cases and Requirements](usecasesAndReqs.html)
-* [High Level Design](HighLevelDesign.html)
-* [API](API.html)
-* [Core](Core.html)
-* [Extensions](extensions.html)
-
----
-
-Quickstart
-----------
-
-Using Apache Tamaya is simple:
-
-1. Add `org.apache.tamaya:tamaya-core:${released_version}` to your dependencies.
-2. Add your config to `META-INF/javaconfiguration.properties`
-3. Access your configuration by `ConfigurationProvider.getConfiguration()` and use it.
-4. Look at the [extension modules](extensions.html) to customize your setup!
-5. Enjoy!
-
-
-Rationale
----------
-
-Configuration is one of the most prominent cross-cutting concerns similar to logging. Most of us already have been
-writing similar code again and again in each of our projects. Sometimes in a similar way but mostly always slightly
-different, but certainly with high coupling to your configuration backends. Given your code is reused or integrated
-some how, or deployed by some customers, struggling starts: not supported backends, different policies, missing
-combination and validation mechanisms and so on. Tamaya solves all this by defining a common API and backend SPI.
-Your code is decoupled from the configuration backend. There is no difference if your code is deployed on your dev box
-or in a clustered Docker environment in production, it stays the same!
-
-

http://git-wip-us.apache.org/repos/asf/incubator-tamaya/blob/63124d1f/src/site/resources/css/site.css
----------------------------------------------------------------------
diff --git a/src/site/resources/css/site.css b/src/site/resources/css/site.css
deleted file mode 100644
index ef35671..0000000
--- a/src/site/resources/css/site.css
+++ /dev/null
@@ -1,57 +0,0 @@
-/*
- * Licensed to the Apache Software Foundation (ASF) under one
- * or more contributor license agreements.  See the NOTICE file
- * distributed with this work for additional information
- * regarding copyright ownership.  The ASF licenses this file
- * to you under the Apache License, Version 2.0 (the
- * "License"); you may not use this file except in compliance
- * with the License.  You may obtain a copy of the License at
- *
- *    http://www.apache.org/licenses/LICENSE-2.0
- *
- * Unless required by applicable law or agreed to in writing,
- * software distributed under the License is distributed on an
- * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
- * KIND, either express or implied.  See the License for the
- * specific language governing permissions and limitations
- * under the License.
- *
- */
-
-/*
- * This fixes a CSS rule from reflow-skin.css which hides
- * some links on the page and makes them unclickable.
- * Oliver B. Fischer, 2016-04-17
- */
-h1[id]:before,
-h2[id]:before,
-h3[id]:before,
-h4[id]:before,
-h5[id]:before,
-h6[id]:before,
-a[name]:before {
-    height: 0;
-    margin: 0;
-}
-
-/*
- * These rules are for the Apache Incubator
- * disclaimer in the footer.
- */
-.bottom-description blockquote {
-    padding-top: 0;
-}
-
-.bottom-description .disclaimer {
-    font-size: 11px;
-    font-weight: 700;
-    color: #000;
-    text-transform: uppercase;
-    display: block;;
-}
-
-.bottom-description .incubator-logo {
-    padding-top: 10px;
-    border: none;
-
-}

http://git-wip-us.apache.org/repos/asf/incubator-tamaya/blob/63124d1f/src/site/resources/logos/egg-logo2.png
----------------------------------------------------------------------
diff --git a/src/site/resources/logos/egg-logo2.png b/src/site/resources/logos/egg-logo2.png
deleted file mode 100644
index 9d25899..0000000
Binary files a/src/site/resources/logos/egg-logo2.png and /dev/null differ

http://git-wip-us.apache.org/repos/asf/incubator-tamaya/blob/63124d1f/src/site/site.xml
----------------------------------------------------------------------
diff --git a/src/site/site.xml b/src/site/site.xml
deleted file mode 100644
index 6f1f076..0000000
--- a/src/site/site.xml
+++ /dev/null
@@ -1,122 +0,0 @@
-<?xml version="1.0" encoding="ISO-8859-1"?>
-<!--
-Licensed to the Apache Software Foundation (ASF) under one
-or more contributor license agreements.  See the NOTICE file
-distributed with this work for additional information
-regarding copyright ownership.  The ASF licenses this file
-to you under the Apache License, Version 2.0 (the
-"License"); you may not use this file except in compliance
-with the License.  You may obtain a copy of the License at
-
-   http://www.apache.org/licenses/LICENSE-2.0
-
-Unless required by applicable law or agreed to in writing,
-software distributed under the License is distributed on an
-"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
-KIND, either express or implied.  See the License for the
-specific language governing permissions and limitations
-under the License.
--->
-<project xmlns="http://maven.apache.org/DECORATION/1.6.0"
-         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
-         xsi:schemaLocation="http://maven.apache.org/DECORATION/1.6.0 http://maven.apache.org/xsd/decoration-1.6.0.xsd"
-         name="Apache Tamaya">
-
-    <!-- Position of publishing date and version information -->
-    <publishDate position="bottom" format="yyyy-MM-dd"/>
-    <version position="bottom"/>
-
-    <!-- We use the Reflow Skin for Tamaya -->
-    <skin>
-        <groupId>lt.velykis.maven.skins</groupId>
-        <artifactId>reflow-maven-skin</artifactId>
-        <version>${reflow-skin.version}</version>
-    </skin>
-
-    <body>
-        <menu ref="parent"  inherit="top" />
-        <menu ref="reports" inherit="bottom"/>
-        <menu ref="modules" inherit="bottom"/>
-
-        <menu name="Documentation">
-            <item name="Use Cases and Requirements" href="usecasesAndReqs.html"/>
-            <item name="Quickstart" href="quickstart.html"/>
-            <item name="API" href="API.html"/>
-            <item name="Core" href="Core.html"/>
-            <item name="Extension Guide" href="extensions.html"/>
-            <item name="Design Guide" href="HighLevelDesign.html"/>
-            <item name="JavaDoc of ${project.version}" target="" href="apidocs/index.html"/>
-        </menu>
-
-        <menu name="Development">
-            <item name="Sources" href="source.html"/>
-            <item name="Community" href="community.html"/>
-            <item name="CI Server" href="https://builds.apache.org/view/S-Z/view/Tamaya/" target="_blank"/>
-            <item name="Issues" href="https://issues.apache.org/jira/browse/TAMAYA" target="_blank"/>
-            <item name="Development Guide" href="devguide.html"/>
-            <item name="Release Guide" href="release-guide.html"/>
-        </menu>
-
-        <menu name="Reports" ref="reports">
-        </menu>
-
-        <menu name="Releases">
-            <item name="Download" href="download.html"/>
-            <item name="Release History" href="history.html"/>
-        </menu>
-
-    </body>
-
-
-
-    <custom>
-        <reflowSkin>
-
-            <!-- Brand on the top left menu bar -->
-            <brand>
-                <name>Apache Tamaya (incubating)</name>
-                <href>index.html</href>
-            </brand>
-
-            <pages>
-                <index>
-                    <sections>
-                        <columns>3</columns>
-                        <columns>2</columns>
-                        <columns>1</columns>
-                        <body/>
-                        <!--<sidebar/>-->
-                    </sections>
-                </index>
-            </pages>
-
-            <topNav>Documentation|Development|Releases|Reports</topNav>
-            <bottomNav>
-                <column>Documentation</column>
-                <column>Development</column>
-                <column>Releases</column>
-                <column>Reports</column>
-            </bottomNav>
-            <bottomDescription>
-                <![CDATA[
-                    <span class="disclaimer">Disclaimer</span>
-                    Apache Tamaya (incubating) is an effort undergoing
-                    incubation at
-                    The Apache Software Foundation (ASF), sponsored by
-                    the name of Apache Incubator. Incubation is required of
-                    all newly accepted projects until a further review indicates
-                    that the infrastructure, communications, and decision making
-                    process have stabilized in a manner consistent with other
-                    successful ASF projects. While incubation status is not
-                    necessarily a reflection of the completeness or stability of
-                    the code, it does indicate that the project has yet to
-                    be fully endorsed by the ASF.
-                    <a href="http://incubator.apache.org/guides/website.html"
-                      target="_target"><img class="incubator-logo" src="logos/egg-logo2.png"/></a>
-                ]]>
-            </bottomDescription>
-
-            <theme>bootswatch-cosmo</theme>
-        </reflowSkin>
-    </custom>
-</project>


Mime
View raw message