You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@unomi.apache.org by sh...@apache.org on 2018/09/10 09:30:16 UTC
[2/8] incubator-unomi git commit: Create new manual module and add
master documentation in asciidoc format
http://git-wip-us.apache.org/repos/asf/incubator-unomi/blob/837c4628/manual/src/main/asciidoc/connectors/salesforce-connector.adoc
----------------------------------------------------------------------
diff --git a/manual/src/main/asciidoc/connectors/salesforce-connector.adoc b/manual/src/main/asciidoc/connectors/salesforce-connector.adoc
new file mode 100644
index 0000000..23c0a22
--- /dev/null
+++ b/manual/src/main/asciidoc/connectors/salesforce-connector.adoc
@@ -0,0 +1,224 @@
+//
+// Licensed 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 Unomi Salesforce Connector
+
+This connectors makes it possible to push and pull data to/from the Salesforce CRM. It can copy information between
+Apache Unomi profiles and Salesforce Leads.
+
+==== Getting started
+
+.
+
+Create a new developer account here:
+
+[source]
+----
+https://developer.salesforce.com/signup
+----
+
+.
+
+Create a new Connected App, by going into Setup -> App Manager and click "Create Connected App"
+
+.
+
+In the settings, make sure you do the following:
+
+[source]
+----
+Enable OAuth settings -> Activated
+Enable for device flow -> Activated (no need for a callback URL)
+Add all the selected OAuth scopes you want (or put all of them)
+Make sure Require Secret for Web Server flow is activated
+----
+
+.
+
+Make sure you retrieve the following information once you have created the app in the API (Enable OAuth Settings):
+
+[source]
+----
+Consumer key
+Consumer secret (click to see it)
+----
+
+.
+
+You must also retrieve your user's security token, or create it if you don't have one already. To do this simply
+click on your user at the top right, select "Settings", the click on "Reset my security token". You will receive an email
+with the security token.
+
+.
+
+You are now ready to configure the Apache Unomi Salesforce Connector. In the etc/org.apache.unomi.sfdc.cfg file
+change the following settings:
+
+[source]
+----
+sfdc.user.username=YOUR_USER_NAME
+sfdc.user.password=YOUR_PASSWORD
+sfdc.user.securityToken=YOUR_USER_SECURITY_TOKEN
+sfdc.consumer.key=CONNECTED_APP_CONSUMER_KEY
+sfdc.consumer.secret=CONNECTED_APP_SECRET
+----
+
+.
+
+Connected to the Apache Unomi Karaf Shell using :
+
+[source]
+----
+ssh -p 8102 karaf@localhost (default password is karaf)
+----
+
+.
+
+Deploy into Apache Unomi using the following commands from the Apache Karaf shell:
+
+[source]
+----
+feature:repo-add mvn:org.apache.unomi/unomi-salesforce-connectors-karaf-kar/${project.version}/xml/features
+feature:install unomi-salesforce-connectors-karaf-kar
+----
+
+.
+
+You can then test the connection to Salesforce by accessing the following URLs:
+
+[source]
+----
+https://localhost:9443/cxs/sfdc/version
+https://localhost:9443/cxs/sfdc/limits
+----
+
+The first URL will give you information about the version of the connectors, so this makes it easy to check that the
+plugin is properly deployed, started and the correct version. The second URL will actually make a request to the
+Salesforce REST API to retrieve the limits of the Salesforce API.
+
+Both URLs are password protected by the Apache Unomi (Karaf) password. You can find this user and password information
+in the etc/users.properties file.
+
+.
+
+You can now use the connectors's defined actions in rules to push or pull data to/from the Salesforce CRM. You can
+find more information about rules in the link:concepts.html[Concepts] and the link:getting-started.html[Getting Started] pages.
+
+==== Upgrading the Salesforce connectors
+
+If you followed all the steps in the Getting Started section, you can upgrade the Salesforce connectors by using the following steps:
+
+.
+
+Compile the connectors using:
+
+[source]
+----
+cd extensions/salesforce-connectors
+mvn clean install
+----
+
+.
+
+Login to the Unomi Karaf Shell using:
+
+[source]
+----
+ssh -p 8102 karaf@localhost (password by default is karaf)
+----
+
+.
+
+Execute the following commands in the Karaf shell
+
+[source]
+----
+feature:repo-refresh
+feature:uninstall unomi-salesforce-connectors-karaf-feature
+feature:install unomi-salesforce-connectors-karaf-feature
+----
+
+.
+
+You can then check that the new version is properly deployed by accessing the following URL and checking the build date:
+
+[source]
+----
+https://localhost:9443/cxs/sfdc/version
+----
+
+(if asked for a password it's the same karaf/karaf default)
+
+==== Using the Salesforce Workbench for testing REST API
+
+The Salesforce Workbench contains a REST API Explorer that is very useful to test requests. You may find it here :
+
+[source]
+----
+https://workbench.developerforce.com/restExplorer.php
+----
+
+==== Setting up Streaming Push queries
+
+Using the Salesforce Workbench, you can setting streaming push queries (Queries->Streaming push topics) such as the
+following example:
+
+[source]
+----
+Name: LeadUpdates
+Query : SELECT Id,FirstName,LastName,Email,Company FROM Lead
+----
+
+==== Executing the unit tests
+
+Before running the tests, make sure you have completed all the steps above, including the streaming push queries setup.
+
+By default the unit tests will not run as they need proper Salesforce credentials to run. To set this up create a
+properties file like the following one:
+
+test.properties
+
+[source]
+----
+#
+# 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.
+#
+sfdc.user.username=YOUR_USER_NAME
+sfdc.user.password=YOUR_PASSWORD
+sfdc.user.securityToken=YOUR_USER_SECURITY_TOKEN
+sfdc.consumer.key=CONNECTED_APP_CONSUMER_KEY
+sfdc.consumer.secret=CONNECTED_APP_SECRET
+----
+
+and then use the following command line to reference the file:
+
+[source]
+----
+cd extensions/salesforce-connectors
+mvn clean install -DsfdcProperties=../test.properties
+----
+
+(in case you're wondering the ../ is because the test is located in the services sub-directory)
\ No newline at end of file
http://git-wip-us.apache.org/repos/asf/incubator-unomi/blob/837c4628/manual/src/main/asciidoc/consent-api.adoc
----------------------------------------------------------------------
diff --git a/manual/src/main/asciidoc/consent-api.adoc b/manual/src/main/asciidoc/consent-api.adoc
new file mode 100644
index 0000000..fad664f
--- /dev/null
+++ b/manual/src/main/asciidoc/consent-api.adoc
@@ -0,0 +1,139 @@
+//
+// Licensed 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.
+//
+=== Consent API
+
+Starting with Apache Unomi 1.3 (still in development), a new API for consent management is now available. This API
+is designed to be able to store/retrieve/update visitor consents in order to comply with new
+privacy regulations such as the https://en.wikipedia.org/wiki/General_Data_Protection_Regulation[GDPR].
+
+==== Profiles with consents
+
+Visitor profiles now contain a new Consent object that contains the following information:
+
+* a scope
+* a type identifier for the consent. This can be any key to reference a consent. Note that Unomi does not manage consent
+definitions, it only stores/retrieves consents for each profile based on this type
+* a status : GRANT, DENY or REVOKED
+* a status date (the date at which the status was updated)
+* a revocation date, in order to comply with GDPR this is usually set at two years
+
+Here is an example of a Profile with a consent attached to it:
+
+[source]
+----
+{
+ "profileId": "8cbe380f-57bb-419d-97bf-24bf30178550",
+ "sessionId": "0d755f4e-154a-45c8-9169-e852e1d706d9",
+ "consents": {
+ "example/newsletter": {
+ "scope": "example",
+ "typeIdentifier": "newsletter",
+ "status": "GRANTED",
+ "statusDate": "2018-05-22T09:44:33Z",
+ "revokeDate": "2020-05-21T09:44:33Z"
+ }
+ }
+}
+----
+
+It is of course possible to have multiple consents defined for a single visitor profile.
+
+==== Consent type definitions
+
+Apache Unomi does not manage consent definitions, it leaves that to an external system (for example a CMS) so that it
+can handle user-facing UIs to create, update, internationalize and present consent definitions to end users.
+
+The only thing that is import to Apache Unomi to manage visitor consents is a globally unique key, that is called the
+consent type.
+
+==== Creating / update a visitor consent
+
+A new built-in event type called "modifyConsent" can be sent to Apache Unomi to update a consent for the current
+profile.
+
+Here is an example of such an event:
+
+[source]
+----
+{
+ "events": [
+ {
+ "scope": "example",
+ "eventType": "modifyConsent",
+ "source": {
+ "itemType": "page",
+ "scope": "example",
+ "itemId": "anItemId"
+ },
+ "target": {
+ "itemType": "anyType",
+ "scope": "example",
+ "itemId": "anyItemId"
+ },
+ "properties": {
+ "consent": {
+ "typeIdentifier": "newsletter",
+ "scope": "example",
+ "status": "GRANTED",
+ "statusDate": "2018-05-22T09:27:09.473Z",
+ "revokeDate": "2020-05-21T09:27:09.473Z"
+ }
+ }
+ }
+ ]
+}
+----
+
+You could send it using the following curl request:
+
+[source]
+----
+curl -H "Content-Type: application/json" -X POST -d '{"source":{"itemId":"homepage","itemType":"page","scope":"example"},"events":[{"scope":"example","eventType":"modifyConsent","source":{"itemType":"page","scope":"example","itemId":"anItemId"},"target":{"itemType":"anyType","scope":"example","itemId":"anyItemId"},"properties":{"consent":{"typeIdentifier":"newsletter","scope":"example","status":"GRANTED","statusDate":"2018-05-22T09:27:09.473Z","revokeDate":"2020-05-21T09:27:09.473Z"}}}]}' http://localhost:8181/context.json?sessionId=1234
+----
+
+==== How it works (internally)
+
+Upon receiving this event, Apache Unomi will trigger the modifyAnyConsent rule that has the following definition:
+
+[source]
+----
+{
+ "metadata" : {
+ "id": "modifyAnyConsent",
+ "name": "Modify any consent",
+ "description" : "Modify any consent and sets the consent in the profile",
+ "readOnly":true
+ },
+
+ "condition" : {
+ "type": "modifyAnyConsentEventCondition",
+ "parameterValues": {
+ }
+ },
+
+ "actions" : [
+ {
+ "type": "modifyConsentAction",
+ "parameterValues": {
+ }
+ }
+ ]
+
+}
+----
+
+As we can see this rule is pretty simple it will simply execute the modifyConsentAction that is implemented by the
+https://github.com/apache/incubator-unomi/blob/9f1bab437fd93826dc54d318ed00d3b2e3161437/plugins/baseplugin/src/main/java/org/apache/unomi/plugins/baseplugin/actions/ModifyConsentAction.java[ModifyConsentAction Java class]
+
+This class will update the current visitor profile to add/update/revoke any consents that are included in the event.
\ No newline at end of file
http://git-wip-us.apache.org/repos/asf/incubator-unomi/blob/837c4628/manual/src/main/asciidoc/custom-extensions.adoc
----------------------------------------------------------------------
diff --git a/manual/src/main/asciidoc/custom-extensions.adoc b/manual/src/main/asciidoc/custom-extensions.adoc
new file mode 100644
index 0000000..20faa72
--- /dev/null
+++ b/manual/src/main/asciidoc/custom-extensions.adoc
@@ -0,0 +1,419 @@
+//
+// Licensed 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.
+//
+=== Custom extensions
+
+Apache Unomi is a pluggeable server that may be extended in many ways. This document assumes you are familiar with the
+link:concepts.html[Apache Unomi concepts] . This document is mostly a reference document on the different things that may
+be used inside an extension. If you are looking for complete samples, please see the link:samples.html[samples page].
+
+==== Creating an extension
+
+An extension is simply a Maven project, with a Maven pom that looks like this:
+
+[source]
+----
+<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
+ <parent>
+ <groupId>org.apache.unomi</groupId>
+ <artifactId>unomi-extensions</artifactId>
+ <version>${project.version}</version>
+ </parent>
+
+ <modelVersion>4.0.0</modelVersion>
+
+ <artifactId>unomi-extension-example</artifactId>
+ <name>Apache Unomi :: Extensions :: Example</name>
+ <description>Service implementation for the Apache Unomi Context Server extension that integrates with the Geonames database</description>
+ <version>${project.version}</version>
+ <packaging>bundle</packaging>
+
+ <dependencies>
+ <!-- This dependency is not required but generally used in extensions -->
+ <dependency>
+ <groupId>org.apache.unomi</groupId>
+ <artifactId>unomi-api</artifactId>
+ <version>${project.version}</version>
+ <scope>provided</scope>
+ </dependency>
+ </dependencies>
+
+ <build>
+ <plugins>
+ <plugin>
+ <groupId>org.apache.felix</groupId>
+ <artifactId>maven-bundle-plugin</artifactId>
+ <extensions>true</extensions>
+ <configuration>
+ <instructions>
+ <Embed-Dependency>*;scope=compile|runtime</Embed-Dependency>
+ <Import-Package>
+ sun.misc;resolution:=optional,
+ *
+ </Import-Package>
+ </instructions>
+ </configuration>
+ </plugin>
+ </plugins>
+ </build>
+</project>
+----
+
+An extension may contain many different kinds of Apache Unomi objects, as well as custom OSGi services or anything that
+is needed to build your application.
+
+==== Deployment and custom definition
+
+When you deploy a custom bundle with a custom definition (see "Predefined xxx" chapters under) for the first time, the definition will automatically be deployed at your bundle start event *if it does not exist*, after that if you redeploy the same bundle there are two cases:
+1. Your bundle *is a SNAPSHOT* then every time you redeploy it the definition will be redeployed
+2. Your bundle *is NOT a SNAPSHOT* then the definition will not be redeployed, but you can redeploy it manually using the command `unomi:deploy-definition <bundleId> <fileName>`
+
+==== Predefined segments
+
+You may provide pre-defined segments by simply adding a JSON file in the src/main/resources/META-INF/cxs/segments directory of
+your Maven project. Here is an example of a pre-defined segment:
+
+[source]
+----
+{
+ "metadata": {
+ "id": "leads",
+ "name": "Leads",
+ "scope": "systemscope",
+ "description": "You can customize the list below by editing the leads segment.",
+ "readOnly":true
+ },
+ "condition": {
+ "parameterValues": {
+ "subConditions": [
+ {
+ "parameterValues": {
+ "propertyName": "properties.leadAssignedTo",
+ "comparisonOperator": "exists"
+ },
+ "type": "profilePropertyCondition"
+ }
+ ],
+ "operator" : "and"
+ },
+ "type": "booleanCondition"
+ }
+}
+----
+
+Basically this segment uses a condition to test if the profile has a property `leadAssignedTo` that exists. All profiles
+that match this condition will be part of the pre-defined segment.
+
+==== Predefined rules
+
+You may provide pre-defined rules by simply adding a JSON file in the src/main/resources/META-INF/cxs/rules directory of
+your Maven project. Here is an example of a pre-defined rule:
+
+[source]
+----
+{
+ "metadata" : {
+ "id": "evaluateProfileSegments",
+ "name": "Evaluate segments",
+ "description" : "Evaluate segments when a profile is modified",
+ "readOnly":true
+ },
+
+ "condition" : {
+ "type": "profileUpdatedEventCondition",
+ "parameterValues": {
+ }
+ },
+
+ "actions" : [
+ {
+ "type": "evaluateProfileSegmentsAction",
+ "parameterValues": {
+ }
+ }
+ ]
+
+}
+----
+
+In this example we provide a rule that will execute when a predefined composed condition of type
+"profileUpdatedEventCondition" is received. See below to see how predefined composed conditions are declared.
+Once the condition is matched, the actions will be executed in sequence. In this example there is only a single
+action of type "evaluateProfileSegmentsAction" that is defined so it will be executed by Apache Unomi's rule engine.
+You can also see below how custom actions may be defined.
+
+==== Predefined properties
+
+By default Apache Unomi comes with a set of pre-defined properties, but in many cases it is useful to add additional
+predefined property definitions. You can create property definitions for session or profile properties by creating them
+in different directories.
+
+For session properties you must create a JSON file in the following directory in your Maven project:
+
+[source]
+----
+src/main/resources/META-INF/cxs/properties/sessions
+----
+
+For profile properties you must create the JSON file inside the directory in your Maven project:
+
+[source]
+----
+src/main/resources/META-INF/cxs/properties/profiles
+----
+
+Here is an example of a property definition JSON file
+
+[source]
+----
+{
+ "metadata": {
+ "id": "city",
+ "name": "City",
+ "systemTags": ["properties", "profileProperties", "contactProfileProperties"]
+ },
+ "type": "string",
+ "defaultValue": "",
+ "automaticMappingsFrom": [ ],
+ "rank": "304.0"
+}
+----
+
+==== Predefined child conditions
+
+You can define new predefined conditions that are actually conditions inheriting from a parent condition and setting
+pre-defined parameter values. You can do this by creating a JSON file in:
+
+[source]
+----
+src/main/resources/META-INF/cxs/conditions
+----
+
+Here is an example of a JSON file that defines a profileUpdateEventCondition that inherits from a parent condition of
+type eventTypeCondition.
+
+[source]
+----
+{
+ "metadata": {
+ "id": "profileUpdatedEventCondition",
+ "name": "profileUpdatedEventCondition",
+ "description": "",
+ "systemTags": [
+ "event",
+ "eventCondition"
+ ],
+ "readOnly": true
+ },
+ "parentCondition": {
+ "type": "eventTypeCondition",
+ "parameterValues": {
+ "eventTypeId": "profileUpdated"
+ }
+ },
+
+ "parameters": [
+ ]
+}
+----
+
+==== Predefined personas
+
+Personas may also be pre-defined by creating JSON files in the following directory:
+
+[source]
+----
+src/main/resources/META-INF/cxs/personas
+----
+
+Here is an example of a persona definition JSON file:
+
+[source]
+----
+{
+ "persona": {
+ "itemId": "usVisitor",
+ "properties": {
+ "description": "Represents a visitor browsing from inside the continental US",
+ "firstName": "U.S.",
+ "lastName": "Visitor"
+ },
+ "segments": []
+ },
+ "sessions": [
+ {
+ "itemId": "aa3b04bd-8f4d-4a07-8e96-d33ffa04d3d9",
+ "profileId": "usVisitor",
+ "properties": {
+ "operatingSystemName": "OS X 10.9 Mavericks",
+ "sessionCountryName": "United States",
+ "location": {
+ "lat":37.422,
+ "lon":-122.084058
+ },
+ "userAgentVersion": "37.0.2062.120",
+ "sessionCountryCode": "US",
+ "deviceCategory": "Personal computer",
+ "operatingSystemFamily": "OS X",
+ "userAgentName": "Chrome",
+ "sessionCity": "Mountain View"
+ },
+ "timeStamp": "2014-09-18T11:40:54Z",
+ "lastEventDate": "2014-09-18T11:40:59Z",
+ "duration": 4790
+ }
+ ]
+}
+----
+
+You can see that it's also possible to define sessions for personas.
+
+==== Custom actions
+
+Custom actions are a powerful way to integrate with external systems by being able to define custom logic that will
+be executed by an Apache Unomi rule. An action is defined by a JSON file created in the following directory:
+
+[source]
+----
+src/main/resources/META-INF/cxs/actions
+----
+
+Here is an example of a JSON action definition:
+
+[source]
+----
+{
+ "metadata": {
+ "id": "addToListsAction",
+ "name": "addToListsAction",
+ "description": "",
+ "systemTags": [
+ "demographic",
+ "availableToEndUser"
+ ],
+ "readOnly": true
+ },
+ "actionExecutor": "addToLists",
+ "parameters": [
+ {
+ "id": "listIdentifiers",
+ "type": "string",
+ "multivalued": true
+ }
+ ]
+}
+----
+
+The `actionExecutor` identifier refers to a service property that is defined in the OSGi Blueprint service registration.
+Note that any OSGi service registration may be used, but in these examples we use OSGi Blueprint. The definition for the
+above JSON file will be found in a file called `src/main/resources/OSGI-INF/blueprint/blueprint.xml` with the following
+content:
+
+[source]
+----
+<?xml version="1.0" encoding="UTF-8"?>
+<blueprint xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0"
+ xsi:schemaLocation="http://www.osgi.org/xmlns/blueprint/v1.0.0 http://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd">
+
+ <reference id="profileService" interface="org.apache.unomi.api.services.ProfileService"/>
+ <reference id="eventService" interface="org.apache.unomi.api.services.EventService"/>
+
+ <!-- Action executors -->
+
+ <service interface="org.apache.unomi.api.actions.ActionExecutor">
+ <service-properties>
+ <entry key="actionExecutorId" value="addToLists"/>
+ </service-properties>
+ <bean class="org.apache.unomi.lists.actions.AddToListsAction">
+ <property name="profileService" ref="profileService"/>
+ <property name="eventService" ref="eventService"/>
+ </bean>
+ </service>
+
+</blueprint>
+----
+
+You can note here the `actionExecutorId` that corresponds to the `actionExecutor` in the JSON file.
+
+The implementation of the action is available here : https://github.com/apache/incubator-unomi/blob/master/extensions/lists-extension/actions/src/main/java/org/apache/unomi/lists/actions/AddToListsAction.java[org.apache.unomi.lists.actions.AddToListsAction]
+
+==== Custom conditions
+
+Custom conditions are different from predefined child conditions because they implement their logic using Java classes.
+They are also declared by adding a JSON file into the conditions directory:
+
+[source]
+----
+src/main/resources/META-INF/cxs/conditions
+----
+
+Here is an example of JSON custom condition definition:
+
+[source]
+----
+{
+ "metadata": {
+ "id": "matchAllCondition",
+ "name": "matchAllCondition",
+ "description": "",
+ "systemTags": [
+ "logical",
+ "profileCondition",
+ "eventCondition",
+ "sessionCondition",
+ "sourceEventCondition"
+ ],
+ "readOnly": true
+ },
+ "conditionEvaluator": "matchAllConditionEvaluator",
+ "queryBuilder": "matchAllConditionESQueryBuilder",
+
+ "parameters": [
+ ]
+}
+----
+
+Note the `conditionEvaluator` and the `queryBuilder` values. These reference OSGi service properties that are declared
+in an OSGi Blueprint configuration file (other service definitions may also be used such as Declarative Services or even
+Java registered services). Here is an example of an OSGi Blueprint definition corresponding to the above JSON condition
+definition file.
+
+[source]
+----
+src/main/resources/OSGI-INF/blueprint/blueprint.xml
+
+<blueprint xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0"
+ xsi:schemaLocation="http://www.osgi.org/xmlns/blueprint/v1.0.0 http://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd">
+
+ <service
+ interface="org.apache.unomi.persistence.elasticsearch.conditions.ConditionESQueryBuilder">
+ <service-properties>
+ <entry key="queryBuilderId" value="matchAllConditionESQueryBuilder"/>
+ </service-properties>
+ <bean class="org.apache.unomi.plugins.baseplugin.conditions.MatchAllConditionESQueryBuilder"/>
+ </service>
+
+ <service interface="org.apache.unomi.persistence.elasticsearch.conditions.ConditionEvaluator">
+ <service-properties>
+ <entry key="conditionEvaluatorId" value="matchAllConditionEvaluator"/>
+ </service-properties>
+ <bean class="org.apache.unomi.plugins.baseplugin.conditions.MatchAllConditionEvaluator"/>
+ </service>
+
+</blueprint>
+----
+
+You can find the implementation of the two classes here :
+
+* https://github.com/apache/incubator-unomi/blob/master/plugins/baseplugin/src/main/java/org/apache/unomi/plugins/baseplugin/conditions/MatchAllConditionESQueryBuilder.java[org.apache.unomi.plugins.baseplugin.conditions.MatchAllConditionESQueryBuilder]
+* https://github.com/apache/incubator-unomi/blob/master/plugins/baseplugin/src/main/java/org/apache/unomi/plugins/baseplugin/conditions/MatchAllConditionEvaluator.java[org.apache.unomi.plugins.baseplugin.conditions.MatchAllConditionEvaluator]
\ No newline at end of file
http://git-wip-us.apache.org/repos/asf/incubator-unomi/blob/837c4628/manual/src/main/asciidoc/extending-plugins.adoc
----------------------------------------------------------------------
diff --git a/manual/src/main/asciidoc/extending-plugins.adoc b/manual/src/main/asciidoc/extending-plugins.adoc
new file mode 100644
index 0000000..8a29fb1
--- /dev/null
+++ b/manual/src/main/asciidoc/extending-plugins.adoc
@@ -0,0 +1,113 @@
+//
+// Licensed 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.
+//
+Unomi is architected so that users can provided extensions in the form of plugins.
+
+=== Types vs. instances
+
+Several extension points in Unomi rely on the concept of type: the extension defines a prototype for what the actual items will be once parameterized with values known only at runtime. This is similar to the concept of classes in object-oriented programming: types define classes, providing the expected structure and which fields are expected to be provided at runtime, that are then instantiated when needed with actual values.
+
+=== Plugin structure
+
+Being built on top of Apache Karaf, Unomi leverages OSGi to support plugins. A Unomi plugin is, thus, an OSGi bundle specifying some specific metadata to tell Unomi the kind of entities it provides. A plugin can provide the following entities to extend Unomi, each with its associated definition (as a JSON file), located in a specific spot within the `META-INF/cxs/` directory of the bundle JAR file:
+
+|====
+|Entity |Location in `cxs` directory
+
+|ActionType |actions
+|ConditionType |conditions
+|Persona |personas
+|PropertyMergeStrategyType |mergers
+|PropertyType |properties then profiles or sessions subdirectory then `<category name>` directory
+|Rule |rules
+|Scoring |scorings
+|Segment |segments
+|ValueType |values
+|====
+
+http://aries.apache.org/modules/blueprint.html[Blueprint] is used to declare what the plugin provides and inject any required dependency. The Blueprint file is located, as usual, at `OSGI-INF/blueprint/blueprint.xml` in the bundle JAR file.
+
+The plugin otherwise follows a regular maven project layout and should depend on the Unomi API maven artifact:
+
+[source,xml]
+----
+<dependency>
+ <groupId>org.apache.unomi</groupId>
+ <artifactId>unomi-api</artifactId>
+ <version>...</version>
+</dependency>
+----
+
+Some plugins consists only of JSON definitions that are used to instantiate the appropriate structures at runtime while some more involved plugins provide code that extends Unomi in deeper ways.
+
+In both cases, plugins can provide more that one type of extension. For example, a plugin could provide both `ActionType`s and `ConditionType`s.
+
+=== Extension points
+
+==== ActionType
+
+`ActionType`s define new actions that can be used as consequences of Rules being triggered. When a rule triggers, it creates new actions based on the event data and the rule internal processes, providing values for parameters defined in the associated `ActionType`. Example actions include: “Set user property x to value y” or “Send a message to service x”.
+
+==== ConditionType
+
+`ConditionType`s define new conditions that can be applied to items (for example to decide whether a rule needs to be triggered or if a profile is considered as taking part in a campaign) or to perform queries against the stored Unomi data. They may be implemented in Java when attempting to define a particularly complex test or one that can better be optimized by coding it. They may also be defined as combination of other conditions. A simple condition could be: “User is male”, while a more generic condition with parameters may test whether a given property has a specific value: “User property x has value y”.
+
+==== Persona
+
+A persona is a "virtual" profile used to represent categories of profiles, and may also be used to test how a personalized experience would look like using this virtual profile. A persona can define predefined properties and sessions. Persona definition make it possible to “emulate” a certain type of profile, e.g : US visitor, non-US visitor, etc.
+
+==== PropertyMergeStrategyType
+
+A strategy to resolve how to merge properties when merging profile together.
+
+==== PropertyType
+
+Definition for a profile or session property, specifying how possible values are constrained, if the value is multi-valued (a vector of values as opposed to a scalar value). `PropertyType`s can also be categorized using systemTags or file system structure, using sub-directories to organize definition files.
+
+==== Rule
+
+`Rule`s are conditional sets of actions to be executed in response to incoming events. Triggering of rules is guarded by a condition: the rule is only triggered if the associated condition is satisfied. That condition can test the event itself, but also the profile or the session. Once a rule triggers, a list of actions can be performed as consequences. Also, when rules trigger, a specific event is raised so that other parts of Unomi can react accordingly.
+
+==== Scoring
+
+`Scoring`s are set of conditions associated with a value to assign to profiles when matching so that the associated users can be scored along that dimension. Each scoring element is evaluated and matching profiles' scores are incremented with the associated value.
+
+==== Segments
+
+`Segment`s represent dynamically evaluated groups of similar profiles in order to categorize the associated users. To be considered part of a given segment, users must satisfies the segment’s condition. If they match, users are automatically added to the segment. Similarly, if at any given point during, they cease to satisfy the segment’s condition, they are automatically removed from it.
+
+==== Tag
+
+`Tag`s are simple labels that are used to classify all other objects inside Unomi.
+
+==== ValueType
+
+Definition for values that can be assigned to properties ("primitive" types).
+
+=== Other Unomi entities
+
+==== UserList
+
+User list are simple static lists of users. The associated profile stores the lists it belongs to in a specific property.
+
+==== Goal
+
+Goals represent tracked activities / actions that can be accomplished by site (or more precisely scope) visitors. These are tracked in general because they relate to specific business objectives or are relevant to measure site/scope performance.
+
+Goals can be defined at the scope level or in the context of a particular `Campaign`. Either types of goals behave exactly the same way with the exception of two notable differences:
+ - duration: scope-level goals are considered until removed while campaign-level goals are only considered for the campaign duration
+ - audience filtering: any visitor is considered for scope-level goals while campaign-level goals only consider visitors who match the campaign's conditions
+
+==== Campaign
+
+A goal-oriented, time-limited marketing operation that needs to be evaluated for return on investment performance by tracking the ratio of visits to conversions.
\ No newline at end of file
http://git-wip-us.apache.org/repos/asf/incubator-unomi/blob/837c4628/manual/src/main/asciidoc/getting-started.adoc
----------------------------------------------------------------------
diff --git a/manual/src/main/asciidoc/getting-started.adoc b/manual/src/main/asciidoc/getting-started.adoc
new file mode 100644
index 0000000..b0307a2
--- /dev/null
+++ b/manual/src/main/asciidoc/getting-started.adoc
@@ -0,0 +1,121 @@
+//
+// Licensed 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.
+//
+=== Getting started with Unomi
+
+We will first get you up and running with an example. We will then lift the corner of the cover somewhat and explain in greater details what just happened.
+
+==== Prerequisites
+
+This document assumes that you are already familiar with Unomi's link:concepts.html[concepts]. On the technical side, we also assume working knowledge of https://git-scm.com/[git] to be able to retrieve the code for Unomi and the example. Additionnally, you will require a working Java 7 or above install. Refer to http://www.oracle.com/technetwork/java/javase/[http://www.oracle.com/technetwork/java/javase/] for details on how to download and install Java SE 7 or greater.
+
+==== Running Unomi
+
+===== Building Unomi
+
+. Get the code: `git clone https://git-wip-us.apache.org/repos/asf/incubator-unomi.git`
+. Build and install according to the link:building-and-deploying.html[instructions] and install Unomi.
+
+===== Start Unomi
+
+Start Unomi according to the link:building-and-deploying.html#Deploying_the_generated_package[instructions]. Once you have Karaf running,
+ you should wait until you see the following messages on the Karaf console:
+
+[source]
+----
+Initializing user list service endpoint...
+Initializing geonames service endpoint...
+Initializing segment service endpoint...
+Initializing scoring service endpoint...
+Initializing campaigns service endpoint...
+Initializing rule service endpoint...
+Initializing profile service endpoint...
+Initializing cluster service endpoint...
+----
+
+This indicates that all the Unomi services are started and ready to react to requests. You can then open a browser and go to `http://localhost:8181/cxs` to see the list of
+available RESTful services or retrieve an initial context at `http://localhost:8181/context.json` (which isn't very useful at this point).
+
+===== Request examples
+
+====== Retrieving your first context
+
+You can retrieve a context using curl like this :
+
+[source]
+----
+curl http://localhost:8181/context.js?sessionId=1234
+----
+
+This will retrieve a JavaScript script that contains a `cxs` object that contains the context with the current user
+profile, segments, scores as well as functions that makes it easier to perform further requests (such as collecting
+events using the cxs.collectEvents() function).
+
+====== Retrieving a context as a JSON object.
+
+If you prefer to retrieve a pure JSON object, you can simply use a request formed like this:
+
+[source]
+----
+curl http://localhost:8181/context.json?sessionId=1234
+----
+
+====== Accessing profile properties in a context
+
+By default, in order to optimize the amount of data sent over the network, Apache Unomi will not send the content of
+the profile or session properties. If you need this data, you must send a JSON object to configure the resulting output
+of the context.js(on) servlet.
+
+Here is an example that will retrieve all the session and profile properties.
+
+[source]
+----
+curl -H "Content-Type: application/json" -X POST -d '{"source":{"itemId":"homepage","itemType":"page","scope":"example"},"requiredProfileProperties":["*"],"requiredSessionProperties":["*"],"requireSegments":true}' http://localhost:8181/context.json?sessionId=1234
+----
+
+The `requiredProfileProperties` and `requiredSessionProperties` are properties that take an array of property names
+that should be retrieved. In this case we use the wildcard character '*' to say we want to retrieve all the available
+properties. The structure of the JSON object that you should send is a JSON-serialized version of the http://unomi.incubator.apache.org/unomi-api/apidocs/org/apache/unomi/api/ContextRequest.html[ContextRequest]
+Java class.
+
+====== Sending events using the context servlet
+
+At the same time as you are retrieving the context, you can also directly send events in the ContextRequest object as
+illustrated in the following example:
+
+[source]
+----
+curl -H "Content-Type: application/json" -X POST -d '{"source":{"itemId":"homepage","itemType":"page","scope":"example"},"events":[{"eventType":"view","scope": "example","source":{"itemType": "site","scope":"example","itemId": "mysite"},"target":{"itemType":"page","scope":"example","itemId":"homepage","properties":{"pageInfo":{"referringURL":""}}}}]}' http://localhost:8181/context.json?sessionId=1234
+----
+
+Upon received events, Apache Unomi will execute all the rules that match the current context, and return an updated context.
+This way of sending events is usually used upon first loading of a page. If you want to send events after the page has
+finished loading you could either do a second call and get an updating context, or if you don't need the context and want
+to send events in a network optimal way you can use the eventcollector servlet (see below).
+
+====== Sending events using the eventcollector servlet
+
+If you only need to send events without retrieving a context, you should use the eventcollector servlet that is optimized
+respond quickly and minimize network traffic. Here is an example of using this servlet:
+
+[source]
+----
+curl -H "Content-Type: application/json" -X POST -d '{"events":[{"eventType":"view","scope": "example","source":{"itemType": "site","scope":"example","itemId": "mysite"},"target":{"itemType":"page","scope":"example","itemId":"homepage","properties":{"pageInfo":{"referringURL":""}}}}]}' http://localhost:8181/eventcollector?sessionId=1234
+----
+
+Note that the eventcollector executes the rules but does not return a context. If is generally used after a page is loaded
+to send additional events.
+
+===== Where to go from here
+
+* Read the link:twitter-samples.html[Twitter samples] documentation that contains a detailed example of how to integrate with Apache Unomi.
\ No newline at end of file
http://git-wip-us.apache.org/repos/asf/incubator-unomi/blob/837c4628/manual/src/main/asciidoc/images/asf_logo_url.png
----------------------------------------------------------------------
diff --git a/manual/src/main/asciidoc/images/asf_logo_url.png b/manual/src/main/asciidoc/images/asf_logo_url.png
new file mode 100644
index 0000000..5ad4544
Binary files /dev/null and b/manual/src/main/asciidoc/images/asf_logo_url.png differ
http://git-wip-us.apache.org/repos/asf/incubator-unomi/blob/837c4628/manual/src/main/asciidoc/images/incubator-logo.png
----------------------------------------------------------------------
diff --git a/manual/src/main/asciidoc/images/incubator-logo.png b/manual/src/main/asciidoc/images/incubator-logo.png
new file mode 100644
index 0000000..714dbd7
Binary files /dev/null and b/manual/src/main/asciidoc/images/incubator-logo.png differ
http://git-wip-us.apache.org/repos/asf/incubator-unomi/blob/837c4628/manual/src/main/asciidoc/images/unomi-request.png
----------------------------------------------------------------------
diff --git a/manual/src/main/asciidoc/images/unomi-request.png b/manual/src/main/asciidoc/images/unomi-request.png
new file mode 100755
index 0000000..fdba277
Binary files /dev/null and b/manual/src/main/asciidoc/images/unomi-request.png differ
http://git-wip-us.apache.org/repos/asf/incubator-unomi/blob/837c4628/manual/src/main/asciidoc/index.adoc
----------------------------------------------------------------------
diff --git a/manual/src/main/asciidoc/index.adoc b/manual/src/main/asciidoc/index.adoc
new file mode 100644
index 0000000..7008160
--- /dev/null
+++ b/manual/src/main/asciidoc/index.adoc
@@ -0,0 +1,69 @@
+//
+// Licensed 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 Unomi 1.x - Documentation
+Apache Software Foundation
+:doctype: article
+:toc: left
+:toclevels: 3
+:toc-position: left
+:toc-title: Table of Contents
+:numbered:
+:homepage: https://unomi.apache.org
+
+image::incubator-logo.png[pdfwidth=35%,align=center]
+
+== Concepts
+
+include::concepts.adoc[]
+
+== Extending Unomi via plugins
+
+include::extending-plugins.adoc[]
+
+== Quick start
+
+include::building-and-deploying.adoc[]
+
+include::getting-started.adoc[]
+
+include::configuration.adoc[]
+
+== Sample
+
+include::samples/samples.adoc[]
+
+include::samples/login-sample.adoc[]
+
+include::samples/twitter-sample.adoc[]
+
+include::samples/weather-update-sample.adoc[]
+
+== Connectors
+
+include::connectors/connectors.adoc[]
+
+include::connectors/salesforce-connector.adoc[]
+
+== Cluster setup
+
+include::clustering.adoc[]
+
+== Custom extensions
+
+include::custom-extensions.adoc[]
+
+== Consent API
+
+include::consent-api.adoc[]
\ No newline at end of file
http://git-wip-us.apache.org/repos/asf/incubator-unomi/blob/837c4628/manual/src/main/asciidoc/samples/login-sample.adoc
----------------------------------------------------------------------
diff --git a/manual/src/main/asciidoc/samples/login-sample.adoc b/manual/src/main/asciidoc/samples/login-sample.adoc
new file mode 100644
index 0000000..b1664d8
--- /dev/null
+++ b/manual/src/main/asciidoc/samples/login-sample.adoc
@@ -0,0 +1,73 @@
+//
+// Licensed 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.
+//
+=== Login samples
+
+This samples is an example of what is involved in integrated a login with Apache Unomi.
+
+==== Warning !
+
+The example code uses client-side Javascript code to send the login event. This is only
+done this way for the sake of samples simplicity but if should NEVER BE DONE THIS WAY in real cases.
+
+The login event should always be sent from the server performing the actual login since it must
+only be sent if the user has authenticated properly, and only the authentication server can validate this.
+
+==== Installing the samples
+
+.
+
+Login into the Unomi Karaf SSH shell using something like this :
+
+[source]
+----
+ssh -p 8102 karaf@localhost (default password is karaf)
+----
+
+.
+
+Install the login samples using the following command:
+
+[source]
+----
+bundle:install mvn:org.apache.unomi/login-integration-samples/${project.version}
+----
+
+when the bundle is successfully install you will get an bundle ID back we will call it BUNDLE_ID.
+
+.
+
+You can then do:
+
+[source]
+----
+bundle:start BUNDLE_ID
+----
+
+.
+
+If all went well you can access the login samples HTML page here :
+
+[source]
+----
+http://localhost:8181/login/index.html
+----
+
+.
+
+You can fill in the form to test it. Note that the hardcoded password is:
+
+[source]
+----
+test1234
+----
\ No newline at end of file
http://git-wip-us.apache.org/repos/asf/incubator-unomi/blob/837c4628/manual/src/main/asciidoc/samples/samples.adoc
----------------------------------------------------------------------
diff --git a/manual/src/main/asciidoc/samples/samples.adoc b/manual/src/main/asciidoc/samples/samples.adoc
new file mode 100644
index 0000000..877a2e4
--- /dev/null
+++ b/manual/src/main/asciidoc/samples/samples.adoc
@@ -0,0 +1,19 @@
+//
+// Licensed 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.
+//
+=== Samples
+
+Apache Unomi provides the following samples:
+
+* link:twitter-samples.html[Twitter integration]
+* link:login-samples.html[Login integration]
\ No newline at end of file
http://git-wip-us.apache.org/repos/asf/incubator-unomi/blob/837c4628/manual/src/main/asciidoc/samples/twitter-sample.adoc
----------------------------------------------------------------------
diff --git a/manual/src/main/asciidoc/samples/twitter-sample.adoc b/manual/src/main/asciidoc/samples/twitter-sample.adoc
new file mode 100644
index 0000000..f17bc80
--- /dev/null
+++ b/manual/src/main/asciidoc/samples/twitter-sample.adoc
@@ -0,0 +1,432 @@
+//
+// Licensed 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.
+//
+=== Twitter samples
+
+==== Overview
+
+We will examine how a simple HTML page can interact with Unomi to enrich a user's profile. The use case we will follow
+is a rather simple one: we use a Twitter button to record the number of times the visitor tweeted (as a `tweetNb` profile
+integer property) as well as the URLs they tweeted from (as a `tweetedFrom` multi-valued string profile property).
+A javascript script will use the Twitter API to react to clicks on this button
+and update the user profile using a `ContextServlet` request triggering a custom event. This event will, in turn,
+trigger a Unomi action on the server implemented using a Unomi plugin, a standard extension point for the server.
+
+===== Building the tweet button samples
+
+In your local copy of the Unomi repository and run:
+
+[source]
+----
+cd samples/tweet-button-plugin
+mvn clean install
+----
+
+This will compile and create the OSGi bundle that can be deployed on Unomi to extend it.
+
+===== Deploying the tweet button samples
+
+In standard Karaf fashion, you will need to copy the samples bundle to your Karaf `deploy` directory.
+
+If you are using the packaged version of Unomi (as opposed to deploying it to your own Karaf version), you can simply run, assuming your current directory is `samples/tweet-button-plugin` and that you uncompressed the archive in the directory it was created:
+
+[source]
+----
+cp target/tweet-button-plugin-1.0.0-incubating-SNAPSHOT.jar ../../package/target/unomi-1.0.0-incubating-SNAPSHOT/deploy
+----
+
+===== Testing the samples
+
+You can now go to http://localhost:8181/index.html[http://localhost:8181/index.html] to test the samples code. The page is very simple, you will see a Twitter button, which, once clicked, will open a new window to tweet about the current page. The original page should be updated with the new values of the properties coming from Unomi. Additionnally, the raw JSON response is displayed.
+
+We will now explain in greater details some concepts and see how the example works.
+
+==== Interacting with the context server
+
+There are essentially two modalities to interact with the context server, reflecting different types of Unomi users: context server clients and context server integrators.
+
+*Context server clients* are usually web applications or content management systems. They interact with Unomi by providing raw, uninterpreted contextual data in the form of events and associated metadata. That contextual data is then processed by the context server to be fed to clients once actionable. In that sense context server clients are both consumers and producers of contextual data. Context server clients will mostly interact with Unomi using a single entry point called the `ContextServlet`, requesting context for the current user and providing any triggered events along the way.
+
+On the other hand, *context server integrators* provide ways to feed more structured data to the context server either to integrate with third party services or to provide analysis of the uninterpreted data provided by context server clients. Such integration will mostly be done using Unomi's API either directly using Unomi plugins or via the provided REST APIs. However, access to REST APIs is restricted due for security reasons, requiring privileged access to the Unomi server, making things a little more complex to set up.
+
+For simplicity's sake, this document will focus solely on the first use case and will interact only with the context servlet.
+
+==== Retrieving context information from Unomi using the context servlet
+
+Unomi provides two ways to retrieve context: either as a pure JSON object containing strictly context information or as a couple of JSON objects augmented with javascript functions that can be used to interact with the Unomi server using the `<context server base URL>/context.json` or `<context server base URL>/context.js` URLs, respectively.
+
+Below is an example of asynchronously loading the initial context using the javascript version, assuming a default Unomi install running on `http://localhost:8181`:
+
+[source,javascript]
+----
+// Load context from Unomi asynchronously
+(function (document, elementToCreate, id) {
+ var js, fjs = document.getElementsByTagName(elementToCreate)[0];
+ if (document.getElementById(id)) return;
+ js = document.createElement(elementToCreate);
+ js.id = id;
+ js.src = 'http://localhost:8181/context.js';
+ fjs.parentNode.insertBefore(js, fjs);
+}(document, 'script', 'context'));
+
+----
+
+This initial context results in a javascript file providing some functions to interact with the context server from javascript along with two objects: a `cxs` object containing
+information about the context for the current user and a `digitalData` object that is injected into the browser’s `window` object (leveraging the
+http://www.w3.org/2013/12/ceddl-201312.pdf[Customer Experience Digital Data Layer] standard). Note that this last object is not under control of the context server and clients
+ are free to use it or not. Our example will not make use of it.
+
+On the other hand, the `cxs` top level object contains interesting contextual information about the current user:
+
+[source,json]
+----
+{
+ "profileId":<identifier of the profile associated with the current user>,
+ "sessionId":<identifier of the current user session>,
+ "profileProperties":<requested profile properties, if any>,
+ "sessionProperties":<requested session properties, if any>,
+ "profileSegments":<segments the profile is part of if requested>,
+ "filteringResults":<result of the evaluation of personalization filters>,
+ "trackedConditions":<tracked conditions in the source page, if any>
+}
+----
+
+We will look at the details of the context request and response later.
+
+=== Example
+
+==== HTML page
+
+The code for the HTML page with our Tweet button can be found at https://github.com/apache/incubator-unomi/blob/master/wab/src/main/webapp/index.html[https://github.com/apache/incubator-unomi/blob/master/wab/src/main/webapp/index.html].
+
+This HTML page is fairly straightforward: we create a tweet button using the Twitter API while a Javascript script performs the actual logic.
+
+==== Javascript
+
+Globally, the script loads both the twitter widget and the initial context asynchronously (as shown previously). This is accomplished using fairly standard javascript code and we won't look at it here. Using the Twitter API, we react to the `tweet` event and call the Unomi server to update the user's profile with the required information, triggering a custom `tweetEvent` event. This is accomplished using a `contextRequest` function which is an extended version of a classic `AJAX` request:
+
+[source,javascript]
+----
+function contextRequest(successCallback, errorCallback, payload) {
+ var data = JSON.stringify(payload);
+ // if we don't already have a session id, generate one
+ var sessionId = cxs.sessionId || generateUUID();
+ var url = 'http://localhost:8181/context.json?sessionId=' + sessionId;
+ var xhr = new XMLHttpRequest();
+ var isGet = data.length < 100;
+ if (isGet) {
+ xhr.withCredentials = true;
+ xhr.open("GET", url + "&payload=" + encodeURIComponent(data), true);
+ } else if ("withCredentials" in xhr) {
+ xhr.open("POST", url, true);
+ xhr.withCredentials = true;
+ } else if (typeof XDomainRequest != "undefined") {
+ xhr = new XDomainRequest();
+ xhr.open("POST", url);
+ }
+ xhr.onreadystatechange = function () {
+ if (xhr.readyState != 4) {
+ return;
+ }
+ if (xhr.status ==== 200) {
+ var response = xhr.responseText ? JSON.parse(xhr.responseText) : undefined;
+ if (response) {
+ cxs.sessionId = response.sessionId;
+ successCallback(response);
+ }
+ } else {
+ console.log("contextserver: " + xhr.status + " ERROR: " + xhr.statusText);
+ if (errorCallback) {
+ errorCallback(xhr);
+ }
+ }
+ };
+ xhr.setRequestHeader("Content-Type", "text/plain;charset=UTF-8"); // Use text/plain to avoid CORS preflight
+ if (isGet) {
+ xhr.send();
+ } else {
+ xhr.send(data);
+ }
+}
+----
+
+There are a couple of things to note here:
+
+* If we specify a payload, it is expected to use the JSON format so we `stringify` it and encode it if passed as a URL parameter in a `GET` request.
+* We need to make a https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS[`CORS`] request since the Unomi server is most likely not running on the same host than the one from which the request originates. The specific details are fairly standard and we will not explain them here.
+* We need to either retrieve (from the initial context we retrieved previously using `cxs.sessionId`) or generate a session identifier for our request since Unomi currently requires one.
+* We're calling the `ContextServlet` using the default install URI, specifying the session identifier: `http://localhost:8181/context.json?sessionId=' + sessionId`. This URI requests context from Unomi, resulting in an updated `cxs` object in the javascript global scope. The context server can reply to this request either by returning a JSON-only object containing solely the context information as is the case when the requested URI is `context.json`. However, if the client requests `context.js` then useful functions to interact with Unomi are added to the `cxs` object in addition to the context information as depicted above.
+* We don't need to provide any authentication at all to interact with this part of Unomi since we only have access to read-only data (as well as providing events as we shall see later on). If we had been using the REST API, we would have needed to provide authentication information as well.
+
+===== Context request and response structure
+
+The interesting part, though, is the payload. This is where we provide Unomi with contextual information as well as ask for data in return. This allows clients to specify which type of information they are interested in getting from the context server as well as specify incoming events or content filtering or property/segment overrides for personalization or impersonation. This conditions what the context server will return with its response.
+
+Let's look at the context request structure:
+
+[source,json]
+----
+{
+ source: <Item source of the context request>,
+ events: <optional array of triggered events>,
+ requiredProfileProperties: <optional array of property identifiers>,
+ requiredSessionProperties: <optional array of property identifiers>,
+ filters: <optional array of filters to evaluate>,
+ profileOverrides: <optional profile containing segments,scores or profile properties to override>,
+ - segments: <optional array of segment identifiers>,
+ - profileProperties: <optional map of property name / value pairs>,
+ - scores: <optional map of score id / value pairs>
+ sessionPropertiesOverrides: <optional map of property name / value pairs>,
+ requireSegments: <boolean, whether to return the associated segments>
+}
+----
+
+We will now look at each part in greater details.
+
+====== Source
+
+A context request payload needs to at least specify some information about the source of the request in the form of an `Item` (meaning identifier, type and scope plus any additional properties we might have to provide), via the `source` property of the payload. Of course the more information can be provided about the source, the better.
+
+====== Filters
+
+A client wishing to perform content personalization might also specify filtering conditions to be evaluated by the context server so that it can tell the client whether the content associated with the filter should be activated for this profile/session. This is accomplished by providing a list of filter definitions to be evaluated by the context server via the `filters` field of the payload. If provided, the evaluation results will be provided in the `filteringResults` field of the resulting `cxs` object the context server will send.
+
+====== Overrides
+
+It is also possible for clients wishing to perform user impersonation to specify properties or segments to override the proper ones so as to emulate a specific profile, in which case the overridden value will temporarily replace the proper values so that all rules will be evaluated with these values instead of the proper ones. The `segments` (array of segment identifiers), `profileProperties` (maps of property name and associated object value) and `scores` (maps of score id and value) all wrapped in a profileOverrides object and the `sessionPropertiesOverrides` (maps of property name and associated object value) fields allow to provide such information. Providing such overrides will, of course, impact content filtering results and segments matching for this specific request.
+
+====== Controlling the content of the response
+
+The clients can also specify which information to include in the response by setting the `requireSegments` property to true if segments the current profile matches should be returned or provide an array of property identifiers for `requiredProfileProperties` or `requiredSessionProperties` fields to ask the context server to return the values for the specified profile or session properties, respectively. This information is provided by the `profileProperties`, `sessionProperties` and `profileSegments` fields of the context server response.
+
+Additionally, the context server will also returns any tracked conditions associated with the source of the context request. Upon evaluating the incoming request, the context server will determine if there are any rules marked with the `trackedCondition` tag and which source condition matches the source of the incoming request and return these tracked conditions to the client. The client can use these tracked conditions to learn that the context server can react to events matching the tracked condition and coming from that source. This is, in particular, used to implement form mapping (a solution that allows clients to update user profiles based on values provided when a form is submitted).
+
+====== Events
+
+Finally, the client can specify any events triggered by the user actions, so that the context server can process them, via the `events` field of the context request.
+
+====== Default response
+
+If no payload is specified, the context server will simply return the minimal information deemed necessary for client applications to properly function: profile identifier, session identifier and any tracked conditions that might exist for the source of the request.
+
+===== Context request for our example
+
+Now that we've seen the structure of the request and what we can expect from the context response, let's examine the request our component is doing.
+
+In our case, our `source` item looks as follows: we specify a scope for our application (`unomi-tweet-button-samples`), specify that the item type (i.e. the kind of element that is the source of our event) is a `page` (which corresponds, as would be expected, to a web page), provide an identifier (in our case, a Base-64 encoded version of the page's URL) and finally, specify extra properties (here, simply a `url` property corresponding to the page's URL that will be used when we process our event in our Unomi extension).
+
+[source,javascript]
+----
+var scope = 'unomi-tweet-button-samples';
+var itemId = btoa(window.location.href);
+var source = {
+ itemType: 'page',
+ scope: scope,
+ itemId: itemId,
+ properties: {
+ url: window.location.href
+ }
+};
+----
+
+We also specify that we want the context server to return the values of the `tweetNb` and `tweetedFrom` profile properties in its response. Finally, we provide a custom event of type `tweetEvent` with associated scope and source information, which matches the source of our context request in this case.
+
+[source,javascript]
+----
+var contextPayload = {
+ source: source,
+ events: [
+ {
+ eventType: 'tweetEvent',
+ scope: scope,
+ source: source
+ }
+ ],
+ requiredProfileProperties: [
+ 'tweetNb',
+ 'tweetedFrom'
+ ]
+};
+----
+
+The `tweetEvent` event type is not defined by default in Unomi. This is where our Unomi plugin comes into play since we need to tell Unomi how to react when it encounters such events.
+
+===== Unomi plugin overview
+
+In order to react to `tweetEvent` events, we will define a new Unomi rule since this is exactly what Unomi rules are supposed to do. Rules are guarded by conditions and if these
+ conditions match, the associated set of actions will be executed. In our case, we want our new
+ https://github.com/apache/incubator-unomi/blob/master/samples/tweet-button-plugin/src/main/resources/META-INF/cxs/rules/incrementTweetNumber.json[`incrementTweetNumber`] rule to only react to `tweetEvent` events and
+ we want it to perform the profile update accordingly: create the property types for our custom properties if they don't exist and update them. To do so, we will create a
+ custom
+ https://github.com/apache/incubator-unomi/blob/master/samples/tweet-button-plugin/src/main/resources/META-INF/cxs/actions/incrementTweetNumberAction.json[`incrementTweetNumberAction`] action that will be triggered any time our rule matches. An action is some custom code that is deployed in the context server and can access the
+ Unomi API to perform what it is that it needs to do.
+
+===== Rule definition
+
+Let's look at how our custom https://github.com/apache/incubator-unomi/blob/master/samples/tweet-button-plugin/src/main/resources/META-INF/cxs/rules/incrementTweetNumber.json[`incrementTweetNumber`] rule is defined:
+
+[source,json]
+----
+{
+ "metadata": {
+ "id": "smp:incrementTweetNumber",
+ "name": "Increment tweet number",
+ "description": "Increments the number of times a user has tweeted after they click on a tweet button"
+ },
+ "raiseEventOnlyOnceForSession": false,
+ "condition": {
+ "type": "eventTypeCondition",
+ "parameterValues": {
+ "eventTypeId": "tweetEvent"
+ }
+ },
+ "actions": [
+ {
+ "type": "incrementTweetNumberAction",
+ "parameterValues": {}
+ }
+ ]
+}
+----
+
+Rules define a metadata section where we specify the rule name, identifier and description.
+
+When rules trigger, a specific event is raised so that other parts of Unomi can react to it accordingly. We can control how that event should be raised. Here we specify that the event should be raised each time the rule triggers and not only once per session by setting `raiseEventOnlyOnceForSession` to `false`, which is not strictly required since that is the default. A similar setting (`raiseEventOnlyOnceForProfile`) can be used to specify that the event should only be raised once per profile if needed.
+
+We could also specify a priority for our rule in case it needs to be executed before other ones when similar conditions match. This is accomplished using the `priority` property. We're using the default priority here since we don't have other rules triggering on `tweetEvent`s and don't need any special ordering.
+
+We then tell Unomi which condition should trigger the rule via the `condition` property. Here, we specify that we want our rule to trigger on an `eventTypeCondition` condition. Unomi can be extended by adding new condition types that can enrich how matching or querying is performed. The condition type definition file specifies which parameters are expected for our condition to be complete. In our case, we use the built-in event type condition that will match if Unomi receives an event of the type specified in the condition's `eventTypeId` parameter value: `tweetEvent` here.
+
+Finally, we specify a list of actions that should be performed as consequences of the rule matching. We only need one action of type `incrementTweetNumberAction` that doesn't require any parameters.
+
+===== Action definition
+
+Let's now look at our custom https://github.com/apache/incubator-unomi/blob/master/samples/tweet-button-plugin/src/main/resources/META-INF/cxs/actions/incrementTweetNumberAction.json[`incrementTweetNumberAction`] action type definition:
+
+[source,json]
+----
+{
+ "id": "incrementTweetNumberAction",
+ "actionExecutor": "incrementTweetNumber",
+ "systemTags": [
+ "event"
+ ],
+ "parameters": []
+}
+----
+
+We specify the identifier for the action type, a list of systemTags if needed: here we say that our action is a consequence of events using the `event` tag. Our actions does not require any parameters so we don't define any.
+
+Finally, we provide a mysterious `actionExecutor` identifier: `incrementTweetNumber`.
+
+===== Action executor definition
+
+The action executor references the actual implementation of the action as defined in our https://github.com/apache/incubator-unomi/blob/master/samples/tweet-button-plugin/src/main/resources/OSGI-INF/blueprint/blueprint.xml[blueprint definition]:
+
+[source,xml]
+----
+<blueprint xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
+ xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0"
+ xsi:schemaLocation="http://www.osgi.org/xmlns/blueprint/v1.0.0 http://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd">
+
+ <reference id="profileService" interface="org.apache.unomi.api.services.ProfileService"/>
+
+ <!-- Action executor -->
+ <service id="incrementTweetNumberAction" interface="org.apache.unomi.api.actions.ActionExecutor">
+ <service-properties>
+ <entry key="actionExecutorId" value="incrementTweetNumber"/>
+ </service-properties>
+ <bean class="org.apache.unomi.examples.unomi_tweet_button_plugin.actions.IncrementTweetNumberAction">
+ <property name="profileService" ref="profileService"/>
+ </bean>
+ </service>
+</blueprint>
+----
+
+In standard Blueprint fashion, we specify that we will need the `profileService` defined by Unomi and then define a service of our own to be exported for Unomi to use. Our service specifies one property: `actionExecutorId` which matches the identifier we specified in our action definition. We then inject the profile service in our executor and we're done for the configuration side of things!
+
+===== Action executor implementation
+
+Our action executor definition specifies that the bean providing the service is implemented in the https://github.com/apache/incubator-unomi/blob/master/samples/tweet-button-plugin/src/main/java/org/apache/unomi/samples/tweet_button_plugin/actions/IncrementTweetNumberAction.java[`org.apache.unomi.samples.tweet_button_plugin.actions
+.IncrementTweetNumberAction`] class. This class implements the Unomi `ActionExecutor` interface which provides a single `int execute(Action action, Event event)` method: the executor gets the action instance to execute along with the event that triggered it, performs its work and returns an integer status corresponding to what happened as defined by public constants of the `EventService` interface of Unomi: `NO_CHANGE`, `SESSION_UPDATED` or `PROFILE_UPDATED`.
+
+Let's now look at the implementation of the method:
+
+[source,java]
+----
+final Profile profile = event.getProfile();
+Integer tweetNb = (Integer) profile.getProperty(TWEET_NB_PROPERTY);
+List<String> tweetedFrom = (List<String>) profile.getProperty(TWEETED_FROM_PROPERTY);
+
+if (tweetNb ==== null || tweetedFrom ==== null) {
+ // create tweet number property type
+ PropertyType propertyType = new PropertyType(new Metadata(event.getScope(), TWEET_NB_PROPERTY, TWEET_NB_PROPERTY, "Number of times a user tweeted"));
+ propertyType.setValueTypeId("integer");
+ service.createPropertyType(propertyType);
+
+ // create tweeted from property type
+ propertyType = new PropertyType(new Metadata(event.getScope(), TWEETED_FROM_PROPERTY, TWEETED_FROM_PROPERTY, "The list of pages a user tweeted from"));
+ propertyType.setValueTypeId("string");
+ propertyType.setMultivalued(true);
+ service.createPropertyType(propertyType);
+
+ tweetNb = 0;
+ tweetedFrom = new ArrayList<>();
+}
+
+profile.setProperty(TWEET_NB_PROPERTY, tweetNb + 1);
+final String sourceURL = extractSourceURL(event);
+if (sourceURL != null) {
+ tweetedFrom.add(sourceURL);
+}
+profile.setProperty(TWEETED_FROM_PROPERTY, tweetedFrom);
+
+return EventService.PROFILE_UPDATED;
+----
+
+It is fairly straightforward: we retrieve the profile associated with the event that triggered the rule and check whether it already has the properties we are interested in. If not, we create the associated property types and initialize the property values.
+
+____
+
+Note that it is not an issue to attempt to create the same property type multiple times as Unomi will not add a new property type if an identical type already exists.
+
+____
+
+Once this is done, we update our profile with the new property values based on the previous values and the metadata extracted from the event using the `extractSourceURL` method which uses our `url` property that we've specified for our event source. We then return that the profile was updated as a result of our action and Unomi will properly save it for us when appropriate. That's it!
+
+For reference, here's the `extractSourceURL` method implementation:
+
+[source,java]
+----
+private String extractSourceURL(Event event) {
+ final Item sourceAsItem = event.getSource();
+ if (sourceAsItem instanceof CustomItem) {
+ CustomItem source = (CustomItem) sourceAsItem;
+ final String url = (String) source.getProperties().get("url");
+ if (url != null) {
+ return url;
+ }
+ }
+
+ return null;
+}
+----
+
+=== Conclusion
+
+We have seen a simple example how to interact with Unomi using a combination of client-side code and Unomi plugin. Hopefully, this provided an introduction to the power of what Unomi can do and how it can be extended to suit your needs.
+
+=== Annex
+
+Here is an overview of how Unomi processes incoming requests to the `ContextServlet`.
+image: images/unomi-request.png[Unomi request overview]
\ No newline at end of file
http://git-wip-us.apache.org/repos/asf/incubator-unomi/blob/837c4628/manual/src/main/asciidoc/samples/weather-update-sample.adoc
----------------------------------------------------------------------
diff --git a/manual/src/main/asciidoc/samples/weather-update-sample.adoc b/manual/src/main/asciidoc/samples/weather-update-sample.adoc
new file mode 100644
index 0000000..cfde0f6
--- /dev/null
+++ b/manual/src/main/asciidoc/samples/weather-update-sample.adoc
@@ -0,0 +1,14 @@
+//
+// Licensed 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.
+//
+=== Weather update samples
\ No newline at end of file
http://git-wip-us.apache.org/repos/asf/incubator-unomi/blob/837c4628/manual/src/theme/apache-theme.yml
----------------------------------------------------------------------
diff --git a/manual/src/theme/apache-theme.yml b/manual/src/theme/apache-theme.yml
new file mode 100644
index 0000000..855b46c
--- /dev/null
+++ b/manual/src/theme/apache-theme.yml
@@ -0,0 +1,271 @@
+font:
+ catalog:
+ #SourceSansPro
+ SourceSansPro:
+ normal: SourceSansPro-Regular.ttf
+ italic: SourceSansPro-Italic.ttf
+ bold: SourceSansPro-Bold.ttf
+ bold_italic: SourceSansPro-BoldItalic.ttf
+ #DroidSerif
+ DroidSerif:
+ normal: DroidSerif-Regular.ttf
+ italic: DroidSerif-Italic.ttf
+ bold: DroidSerif-Bold.ttf
+ bold_italic: DroidSerif-BoldItalic.ttf
+
+page:
+ background_color: #ffffff
+ layout: portrait
+ margin: [0.5in, 0.67in, 0.67in, 0.67in]
+ # margin_inner and margin_outer keys are used for recto/verso print margins when media=prepress
+ margin_inner: 0.75in
+ margin_outer: 0.59in
+ size: A4
+base:
+ align: justify
+ # color as hex string (leading # is optional)
+ font_color: #333333
+ # color as RGB array
+ #font_color: [51, 51, 51]
+ # color as CMYK array (approximated)
+ #font_color: [0, 0, 0, 0.92]
+ #font_color: [0, 0, 0, 92%]
+ font_family: DroidSerif
+ # choose one of these font_size/line_height_length combinations
+ #font_size: 14
+ #line_height_length: 20
+ #font_size: 11.25
+ #line_height_length: 18
+ #font_size: 11.2
+ #line_height_length: 16
+ font_size: 10
+ line_height_length: 15
+ #font_size: 11.25
+ #line_height_length: 18
+ line_height: $base_line_height_length / $base_font_size
+ font_size_large: round($base_font_size * 1.25)
+ font_size_small: round($base_font_size * 0.85)
+ font_size_min: $base_font_size * 0.75
+ font_style: normal
+ border_color: #cccccc
+ border_radius: 0
+ border_width: 0.5
+# FIXME vertical_rhythm is weird; we should think in terms of ems
+#vertical_rhythm: $base_line_height_length * 2 / 3
+# correct line height for Noto Serif metrics (comes with built-in line height)
+vertical_rhythm: $base_line_height_length
+horizontal_rhythm: $base_line_height_length
+# QUESTION should vertical_spacing be block_spacing instead?
+vertical_spacing: $vertical_rhythm
+link:
+ font_color: #585ac2
+# literal is currently used for inline monospaced in prose and table cells
+literal:
+ font_color: #585ac2
+ font_family: DroidSerif
+menu_caret_content: " <font size=\"1.15em\"><color rgb=\"b12146\">\u203a</color></font> "
+heading:
+ align: left
+ font_color: #303284
+ #font_color: $base_font_color
+ font_family: SourceSansPro
+ font_style: bold
+ text_transform: uppercase
+ # h1 is used for part titles (book doctype only)
+ h1_font_size: floor($base_font_size * 2.6)
+ # h2 is used for chapter titles (book doctype only)
+ h2_font_size: floor($base_font_size * 2.15)
+ h3_font_size: round($base_font_size * 1.7)
+ h4_font_size: $base_font_size_large
+ h5_font_size: $base_font_size
+ h6_font_size: $base_font_size_small
+ #line_height: 1.4
+ # correct line height for Noto Serif metrics (comes with built-in line height)
+ line_height: 1
+ margin_top: $vertical_rhythm * 0.4
+ margin_bottom: $vertical_rhythm * 0.9
+title_page:
+ align: right
+ logo:
+ top: 10%
+ align: right
+ image: image:images/asf_logo_url.png[pdfwidth=35%,align=right]
+ title:
+ top: 55%
+ font_size: $heading_h1_font_size
+ font_family: $heading_font_family
+ font_style: bold
+ text_transform: uppercase
+ font_color: $heading_font_color
+ line_height: 0.9
+ subtitle:
+ font_size: $heading_h3_font_size
+ font_family: $heading_font_family
+ font_style: bold_italic
+ font_color: $heading_font_color
+ line_height: 1
+ authors:
+ margin_top: $base_font_size * 1.25
+ font_size: $base_font_size_large
+ font_color: $heading_font_color
+ font_family: $heading_font_family
+ revision:
+ margin_top: $base_font_size * 1.25
+block:
+ margin_top: 0
+ margin_bottom: $vertical_rhythm
+caption:
+ align: left
+ font_size: $base_font_size * 0.95
+ font_style: italic
+ # FIXME perhaps set line_height instead of / in addition to margins?
+ margin_inside: $vertical_rhythm / 3
+ #margin_inside: $vertical_rhythm / 4
+ margin_outside: 0
+lead:
+ font_size: $base_font_size_large
+ line_height: 1.4
+abstract:
+ font_color: #5c6266
+ font_size: $lead_font_size
+ line_height: $lead_line_height
+ font_style: italic
+ first_line_font_style: bold
+ title:
+ align: center
+ font_color: $heading_font_color
+ font_family: $heading_font_family
+ font_size: $heading_h4_font_size
+ font_style: $heading_font_style
+admonition:
+ column_rule_color: $base_border_color
+ column_rule_width: $base_border_width
+ padding: [0, $horizontal_rhythm, 0, $horizontal_rhythm]
+ #icon:
+ # tip:
+ # name: fa-lightbulb-o
+ # stroke_color: 111111
+ # size: 24
+ label:
+ text_transform: uppercase
+ font_style: bold
+blockquote:
+ font_color: $base_font_color
+ font_size: $base_font_size_large
+ border_color: $base_border_color
+ border_width: 5
+ # FIXME disable negative padding bottom once margin collapsing is implemented
+ padding: [0, $horizontal_rhythm, $block_margin_bottom * -0.75, $horizontal_rhythm + $blockquote_border_width / 2]
+ cite_font_size: $base_font_size_small
+ cite_font_color: #999999
+# code is used for source blocks (perhaps change to source or listing?)
+code:
+ font_color: #5c4cdb
+ font_family: $literal_font_family
+ font_size: ceil($base_font_size)
+ padding: $code_font_size
+ line_height: 1.25
+ # line_gap is an experimental property to control how a background color is applied to an inline block element
+ line_gap: 3.8
+ background_color: #f5f5f5
+ border_color: #f5f5f5
+ border_radius: $base_border_radius
+ border_width: 0.75
+conum:
+ font_family: OpenSans
+ font_color: $literal_font_color
+ font_size: $base_font_size
+ line_height: 4 / 3
+example:
+ border_color: #f5f5f5
+ border_radius: $base_border_radius
+ border_width: 0.75
+ background_color: #f5f5f5
+ # FIXME reenable padding bottom once margin collapsing is implemented
+ padding: [$vertical_rhythm, $horizontal_rhythm, 0, $horizontal_rhythm]
+image:
+ align: left
+prose:
+ margin_top: $block_margin_top
+ margin_bottom: $block_margin_bottom
+sidebar:
+ background_color: #eeeeee
+ border_color: #e1e1e1
+ border_radius: $base_border_radius
+ border_width: $base_border_width
+ # FIXME reenable padding bottom once margin collapsing is implemented
+ padding: [$vertical_rhythm, $vertical_rhythm * 1.25, 0, $vertical_rhythm * 1.25]
+ title:
+ align: center
+ font_color: $heading_font_color
+ font_family: $heading_font_family
+ font_size: $heading_h4_font_size
+ font_style: $heading_font_style
+thematic_break:
+ border_color: $base_border_color
+ border_style: solid
+ border_width: $base_border_width
+ margin_top: $vertical_rhythm * 0.5
+ margin_bottom: $vertical_rhythm * 1.5
+description_list:
+ term_font_style: bold
+ term_spacing: $vertical_rhythm / 4
+ description_indent: $horizontal_rhythm * 1.25
+outline_list:
+ indent: $horizontal_rhythm * 1.5
+ #marker_font_color: 404040
+ # NOTE outline_list_item_spacing applies to list items that do not have complex content
+ item_spacing: $vertical_rhythm / 2
+table:
+ background_color: #ffffff
+ font_color: $base_font_color
+ #head_background_color: <hex value>
+ head_font_color: $base_font_color
+ head_font_style: bold
+ #body_background_color: <hex value>
+ body_stripe_background_color: #f9f9f9
+ foot_background_color: #f5f5f5
+ border_color: #dddddd
+ border_width: $base_border_width
+ cell_padding: 3
+toc:
+ indent: $horizontal_rhythm
+ line_height: 1.4
+ dot_leader:
+ #content: ". "
+ font_color: #a9a9a9
+ #levels: 2 3
+# NOTE in addition to footer, header is also supported
+footer:
+ font_size: $base_font_size_small
+ # NOTE if background_color is set, background and border will span width of page
+ border_color: #dddddd
+ border_width: 0.25
+ height: $base_line_height_length * 2.5
+ line_height: 1
+ padding: [$base_line_height_length / 2, 1, 0, 1]
+ vertical_align: top
+ #image_vertical_align: <alignment> or <number>
+ # additional attributes for content:
+ # * {page-count}
+ # * {page-number}
+ # * {document-title}
+ # * {document-subtitle}
+ # * {chapter-title}
+ # * {section-title}
+ # * {section-or-chapter-title}
+ recto:
+ #columns: "<50% =0% >50%"
+ right:
+ #content: '{page-number}'
+ #content: '{section-or-chapter-title} - {page-number}'
+ content: '{document-title} - {page-number}'
+ #center:
+ # content: '{page-number}'
+ verso:
+ #columns: $footer_recto_columns
+ left:
+ content: $footer_recto_right_content
+ #content: '{page-number} - {chapter-title}'
+ #center:
+# content: '{page-number}'
\ No newline at end of file
http://git-wip-us.apache.org/repos/asf/incubator-unomi/blob/837c4628/manual/src/theme/fonts/DroidSerif-Bold.ttf
----------------------------------------------------------------------
diff --git a/manual/src/theme/fonts/DroidSerif-Bold.ttf b/manual/src/theme/fonts/DroidSerif-Bold.ttf
new file mode 100644
index 0000000..838d255
Binary files /dev/null and b/manual/src/theme/fonts/DroidSerif-Bold.ttf differ
http://git-wip-us.apache.org/repos/asf/incubator-unomi/blob/837c4628/manual/src/theme/fonts/DroidSerif-BoldItalic.ttf
----------------------------------------------------------------------
diff --git a/manual/src/theme/fonts/DroidSerif-BoldItalic.ttf b/manual/src/theme/fonts/DroidSerif-BoldItalic.ttf
new file mode 100644
index 0000000..0b1601f
Binary files /dev/null and b/manual/src/theme/fonts/DroidSerif-BoldItalic.ttf differ
http://git-wip-us.apache.org/repos/asf/incubator-unomi/blob/837c4628/manual/src/theme/fonts/DroidSerif-Italic.ttf
----------------------------------------------------------------------
diff --git a/manual/src/theme/fonts/DroidSerif-Italic.ttf b/manual/src/theme/fonts/DroidSerif-Italic.ttf
new file mode 100644
index 0000000..2972809
Binary files /dev/null and b/manual/src/theme/fonts/DroidSerif-Italic.ttf differ
http://git-wip-us.apache.org/repos/asf/incubator-unomi/blob/837c4628/manual/src/theme/fonts/DroidSerif-Regular.ttf
----------------------------------------------------------------------
diff --git a/manual/src/theme/fonts/DroidSerif-Regular.ttf b/manual/src/theme/fonts/DroidSerif-Regular.ttf
new file mode 100644
index 0000000..5b4fe81
Binary files /dev/null and b/manual/src/theme/fonts/DroidSerif-Regular.ttf differ