You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@tamaya.apache.org by po...@apache.org on 2016/12/19 21:50:11 UTC
incubator-tamaya-site git commit: TAMAYA-209: Integrate old contents
in new structure
Repository: incubator-tamaya-site
Updated Branches:
refs/heads/master bf7e37ced -> c12761dfe
TAMAYA-209: Integrate old contents in new structure
* Fix menu structure, add missing external links.
* Reintegrate exentions from old core repository
* Fix baking errors in templates.
Project: http://git-wip-us.apache.org/repos/asf/incubator-tamaya-site/repo
Commit: http://git-wip-us.apache.org/repos/asf/incubator-tamaya-site/commit/c12761df
Tree: http://git-wip-us.apache.org/repos/asf/incubator-tamaya-site/tree/c12761df
Diff: http://git-wip-us.apache.org/repos/asf/incubator-tamaya-site/diff/c12761df
Branch: refs/heads/master
Commit: c12761dfeed6aa04aea67d9b8c18b0b9622bef0a
Parents: bf7e37c
Author: Phil Ottlinger <po...@apache.org>
Authored: Mon Dec 19 22:49:27 2016 +0100
Committer: Phil Ottlinger <po...@apache.org>
Committed: Mon Dec 19 22:49:27 2016 +0100
----------------------------------------------------------------------
content/about.html | 26 ---
content/development/community.adoc | 2 +-
content/development/possible-contributions.adoc | 223 +++++++++++++++++++
content/documentation/api.adoc | 8 +-
content/documentation/core.adoc | 6 +-
.../extensions/mod_usagetracker.adoc | 155 +++++++++++++
.../extensions/mod_validation.adoc | 97 ++++++++
content/start.md | 6 +-
templates/menu.thyme | 11 +-
9 files changed, 492 insertions(+), 42 deletions(-)
----------------------------------------------------------------------
http://git-wip-us.apache.org/repos/asf/incubator-tamaya-site/blob/c12761df/content/about.html
----------------------------------------------------------------------
diff --git a/content/about.html b/content/about.html
deleted file mode 100644
index 617e7fb..0000000
--- a/content/about.html
+++ /dev/null
@@ -1,26 +0,0 @@
-title=About
-date=2016-12-18
-type=page
-status=published
-~~~~~~
-
-Tamaya 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.
-
-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!
-
-Features
-Unified Configuration API
-Pluggable Configuration Backends
-Enforceable Configuration Policies
-Configuration Validation and Documentation
-Seemless Enterprise Integration
-
-Quickstart
-Using Apache Tamaya is simple:
-
-Add org.apache.tamaya:tamaya-core:0.2-incubating to your dependencies.
-Add your config to META-INF/javaconfiguration.properties
-Access your configuration by ConfigurationProvider.getConfiguration() and use it.
-Look at the extension modules to customize your setup!
-Enjoy!
http://git-wip-us.apache.org/repos/asf/incubator-tamaya-site/blob/c12761df/content/development/community.adoc
----------------------------------------------------------------------
diff --git a/content/development/community.adoc b/content/development/community.adoc
index ad9e1dc..2bb4d2b 100644
--- a/content/development/community.adoc
+++ b/content/development/community.adoc
@@ -3,7 +3,7 @@
= Apache Tamaya: Community
-:sectnums:
+//:sectnums:
// Document properties
:twitterhandle: tamayaconf
http://git-wip-us.apache.org/repos/asf/incubator-tamaya-site/blob/c12761df/content/development/possible-contributions.adoc
----------------------------------------------------------------------
diff --git a/content/development/possible-contributions.adoc b/content/development/possible-contributions.adoc
new file mode 100644
index 0000000..60503ef
--- /dev/null
+++ b/content/development/possible-contributions.adoc
@@ -0,0 +1,223 @@
+:jbake-type: page
+:jbake-status: published
+
+toc::[]
+
+= Apache Tamaya - Possible Tasks
+
+: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-site/blob/c12761df/content/documentation/api.adoc
----------------------------------------------------------------------
diff --git a/content/documentation/api.adoc b/content/documentation/api.adoc
index 1dd1d41..56394a6 100644
--- a/content/documentation/api.adoc
+++ b/content/documentation/api.adoc
@@ -6,11 +6,11 @@
Though Tamaya is a very powerful and flexible solution there are basically only a few simple core concepts required
that are the base of all the other mechanisms. As a starting point we recommend you read the corresponding
-llink:HighLevelDesign.html[High Level Design Documentation]
+llink:highleveldesign.html[High Level Design Documentation]
[[API]]
== The Tamaya API
-The API provides the artifacts as described in the link:HighLevelDesign.html[High Level Design Documentation], which are:
+The API provides the artifacts as described in the link:highleveldesign.html[High Level Design Documentation], which are:
* A simple but complete SE *API* for accessing key/value based _Configuration_:
** +Configuration+ hereby models configuration, the main interface of Tamaya. +Configuration+ provides
@@ -520,8 +520,6 @@ One of the most important SPI in Tamaya if the +ConfigurationProviderSpi+ interf
= Interface ConfigurationContextBuilder
-include::temp-properties-files-for-site/attributes.adoc[]
-
[[BuilderCore]]
== Interface ConfigurationContextBuilder
=== Overview
@@ -683,5 +681,5 @@ com.mypackage.MyPropertySource
[[APIImpl]]
== API Implementation
-The API is implemented by the Tamaya _Core_module. Refer to the link:Core.html[Core documentation] for
+The API is implemented by the Tamaya-Core-module. Refer to the link:core.html[Core documentation] for
further details.
http://git-wip-us.apache.org/repos/asf/incubator-tamaya-site/blob/c12761df/content/documentation/core.adoc
----------------------------------------------------------------------
diff --git a/content/documentation/core.adoc b/content/documentation/core.adoc
index 139eade..424818a 100644
--- a/content/documentation/core.adoc
+++ b/content/documentation/core.adoc
@@ -5,7 +5,7 @@
== Tamaya Core Implementation
=== Overview
-Tamaya Core provides an implementation of the link:API.html[Tamaya Configuration API] and adds additional functionality
+Tamaya Core provides an implementation of the link:api.html[Tamaya Configuration API] and adds additional functionality
and building blocks for supporting SPI implementations.
Tamaya Core contains the following artifacts:
@@ -36,7 +36,7 @@ enough to be extended/accommodated with additional features as needed, such as
* remote configuration
* and more
-For details about the extension modules available and their functionality refer to the link:modules.html[extension user guide].
+For details about the extension modules available and their functionality refer to the link:extensions.html[extension user guide].
[[CorePropertyConverters]]
@@ -207,7 +207,7 @@ and +META-INF/javaconfiguration.xml+.
[[Extensions]]
== Adding Extensions
-The Core module only implements the link:API.html[API]. Many users require/wish additional functionality from a
+The Core module only implements the link:api.html[API]. Many users require/wish additional functionality from a
configuration system. Fortunately there are numerous extensions available that add further functionality.
Loading extensions hereby is trivial: you only are required to add the corresponding dependency to the classpath.
http://git-wip-us.apache.org/repos/asf/incubator-tamaya-site/blob/c12761df/content/documentation/extensions/mod_usagetracker.adoc
----------------------------------------------------------------------
diff --git a/content/documentation/extensions/mod_usagetracker.adoc b/content/documentation/extensions/mod_usagetracker.adoc
new file mode 100644
index 0000000..fdb44cc
--- /dev/null
+++ b/content/documentation/extensions/mod_usagetracker.adoc
@@ -0,0 +1,155 @@
+:jbake-type: page
+:jbake-status: published
+
+= 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>{tamaya_version}</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-site/blob/c12761df/content/documentation/extensions/mod_validation.adoc
----------------------------------------------------------------------
diff --git a/content/documentation/extensions/mod_validation.adoc b/content/documentation/extensions/mod_validation.adoc
new file mode 100644
index 0000000..ffb033f
--- /dev/null
+++ b/content/documentation/extensions/mod_validation.adoc
@@ -0,0 +1,97 @@
+:jbake-type: page
+:jbake-status: published
+
+= 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 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>{tamaya_version}</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-site/blob/c12761df/content/start.md
----------------------------------------------------------------------
diff --git a/content/start.md b/content/start.md
index a4f2181..95dc525 100644
--- a/content/start.md
+++ b/content/start.md
@@ -1,10 +1,10 @@
-title=About Apache Tamaya
+title=Tamaya in 5 minutes
type=page
status=published
~~~~~~
-About Apache Tamaya
--------------------
+Tamaya in 5 minutes - a short introduction
+------------------------------------------
Apache Tamaya (incubating) provides a flexible and powerful
configuration solution
http://git-wip-us.apache.org/repos/asf/incubator-tamaya-site/blob/c12761df/templates/menu.thyme
----------------------------------------------------------------------
diff --git a/templates/menu.thyme b/templates/menu.thyme
index 0919a26..b5bcbb8 100644
--- a/templates/menu.thyme
+++ b/templates/menu.thyme
@@ -14,12 +14,11 @@
<span class="icon-bar"></span>
<span class="icon-bar"></span>
</button>
- <a class="navbar-brand" th:with="rootpath=(${content.rootpath != null} ? ${content.rootpath} : '')" th:href="${rootpath}">Apache Tamaya (incubating)</a>
+ <a class="navbar-brand" th:with="rootpath=(${content.rootpath != null} ? ${content.rootpath} : '')" th:href="${rootpath}+'index.html'">Apache Tamaya (incubating)</a>
</div>
<div class="navbar-collapse collapse">
<ul class="nav navbar-nav">
- <li><a th:with="rootpath=(${content.rootpath != null} ? ${content.rootpath} : '')" th:href="${rootpath}+'index.html'">Home</a></li>
- <li><a th:with="rootpath=(${content.rootpath != null} ? ${content.rootpath} : '')" th:href="${rootpath}+'about.html'">About</a></li>
+ <li><a th:with="rootpath=(${content.rootpath != null} ? ${content.rootpath} : '')" th:href="${rootpath}+'start.html'">Tamaya in 5 minutes</a></li>
<li class="dropdown">
<a href="#" class="dropdown-toggle" data-toggle="dropdown">Documentation <b class="caret"></b></a>
<ul class="dropdown-menu">
@@ -29,7 +28,7 @@
<li><a th:with="rootpath=(${content.rootpath != null} ? ${content.rootpath} : '')" th:href="${rootpath}+'documentation/core.html'">Core</a></li>
<li><a th:with="rootpath=(${content.rootpath != null} ? ${content.rootpath} : '')" th:href="${rootpath}+'documentation/extensions.html'">Extension Guide</a></li>
<li class="divider"></li>
- <li><a th:with="rootpath=(${content.rootpath != null} ? ${content.rootpath} : '')" th:href="${rootpath}+'apidocs/index.html'">Javadoc ${tamaya_version} (external)</a></li>
+ <li><a th:with="rootpath=(${content.rootpath != null} ? ${content.rootpath} : '')" th:href="${rootpath}+'apidocs/index.html'">Javadoc {tamaya_version} (external)</a></li>
</ul>
</li>
<li class="dropdown">
@@ -38,8 +37,12 @@
<li><a th:with="rootpath=(${content.rootpath != null} ? ${content.rootpath} : '')" th:href="${rootpath}+'development/source.html'">Sources</a></li>
<li><a th:with="rootpath=(${content.rootpath != null} ? ${content.rootpath} : '')" th:href="${rootpath}+'development/community.html'">Community</a></li>
<li><a th:with="rootpath=(${content.rootpath != null} ? ${content.rootpath} : '')" th:href="${rootpath}+'development/team.html'">Project Team</a></li>
+ <li><a target="_blank" href="https://builds.apache.org/view/S-Z/view/Tamaya/">CI / ASF Jenkins</a></li>
+ <li><a target="_blank" href="https://issues.apache.org/jira/browse/TAMAYA">Issues / ASF Jira</a></li>
<li><a th:with="rootpath=(${content.rootpath != null} ? ${content.rootpath} : '')" th:href="${rootpath}+'devguide.html'">Development Guide</a></li>
<li><a th:with="rootpath=(${content.rootpath != null} ? ${content.rootpath} : '')" th:href="${rootpath}+'release-guide.html'">Release Guide</a></li>
+ <li class="divider"></li>
+ <li><a th:with="rootpath=(${content.rootpath != null} ? ${content.rootpath} : '')" th:href="${rootpath}+'development/possible-contributions.html'">Possible Contributions</a></li>
</ul>
</li>
<li class="dropdown">