You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@polygene.apache.org by ni...@apache.org on 2015/07/08 11:43:13 UTC
[10/11] zest-qi4j git commit: Wrong encoding must have been used earlier. Changed to UTF-8 for all tradmarks ™, and merged in DocUpdate branch
Wrong encoding must have been used earlier. Changed to UTF-8 for all tradmarks ™, and merged in DocUpdate branch
Project: http://git-wip-us.apache.org/repos/asf/zest-qi4j/repo
Commit: http://git-wip-us.apache.org/repos/asf/zest-qi4j/commit/88b203bb
Tree: http://git-wip-us.apache.org/repos/asf/zest-qi4j/tree/88b203bb
Diff: http://git-wip-us.apache.org/repos/asf/zest-qi4j/diff/88b203bb
Branch: refs/heads/develop
Commit: 88b203bb6c676b7b9915c87a25f7c132ef23bf13
Parents: ee29929
Author: Niclas Hedhman <he...@betfair.com>
Authored: Wed Jul 8 12:42:20 2015 +0300
Committer: Niclas Hedhman <he...@betfair.com>
Committed: Wed Jul 8 12:42:20 2015 +0300
----------------------------------------------------------------------
core/api/src/docs/composition.txt | 4 +--
core/api/src/docs/concern.txt | 4 +--
core/api/src/docs/configuration.txt | 2 +-
core/api/src/docs/entitycomposite.txt | 2 +-
core/api/src/docs/metrics.txt | 4 +--
core/api/src/docs/mixin.txt | 10 +++----
core/api/src/docs/reference/ref-api.txt | 6 ++--
core/api/src/docs/servicecomposite.txt | 6 ++--
core/api/src/docs/structure.txt | 20 ++++++-------
core/api/src/docs/type-lookup.txt | 2 +-
core/api/src/docs/unitofwork.txt | 4 +--
core/api/src/docs/valuecomposite.txt | 2 +-
core/bootstrap/src/docs/bootstrap.txt | 14 ++++-----
core/functional/src/docs/functional.txt | 10 +++----
core/io/src/docs/io.txt | 14 ++++-----
core/spi/src/docs/spi.txt | 4 +--
core/spi/src/docs/valueserialization.txt | 2 +-
core/testsupport/src/docs/testsupport.txt | 8 +++---
.../src/docs/es-voldemort.txt | 2 +-
.../indexing-solr/src/docs/index-solr.txt | 2 +-
extensions/indexing-sql/instructions.txt | 4 +--
libraries/alarm/src/docs/alarm.txt | 2 +-
.../circuitbreaker/src/docs/circuitbreaker.txt | 6 ++--
libraries/constraints/src/docs/constraints.txt | 2 +-
.../src/docs/eventsourcing-jdbm.txt | 1 -
libraries/fileconfig/src/docs/fileconfig.txt | 2 +-
libraries/http/src/docs/http.txt | 4 +--
libraries/jmx/src/docs/jmx.txt | 2 +-
libraries/lang-beanshell/README.txt | 2 +-
libraries/logging/src/docs/logging.txt | 2 +-
libraries/metrics/dev-status.xml | 4 +--
libraries/osgi/src/docs/osgi.txt | 8 +++---
libraries/rest-client/src/docs/primer.txt | 4 +--
libraries/servlet/src/docs/servlet.txt | 6 ++--
libraries/spring/src/docs/spring.txt | 20 ++++++-------
.../tutorials/howto-assembly-application.txt | 12 ++++----
.../src/docs/tutorials/howto-build-system.txt | 30 ++++++++++----------
.../docs/tutorials/howto-configure-service.txt | 6 ++--
.../src/docs/tutorials/howto-create-concern.txt | 4 +--
.../src/docs/tutorials/howto-create-entity.txt | 14 ++++-----
.../docs/tutorials/howto-create-sideeffect.txt | 4 +--
.../tutorials/howto-leverage-properties.txt | 2 +-
.../src/docs/tutorials/howto-writing-docs.txt | 2 +-
manual/src/docs/userguide/extensions.txt | 4 +--
manual/src/docs/userguide/faq.txt | 2 +-
manual/src/docs/userguide/glossary.txt | 26 ++++++++---------
manual/src/docs/userguide/index.txt | 2 +-
manual/src/docs/userguide/libraries.txt | 2 +-
manual/src/docs/userguide/preface.txt | 8 +++---
manual/src/docs/userguide/tools.txt | 4 +--
manual/src/docs/website/samples.txt | 12 ++++----
manual/src/docs/website/tutorials.txt | 20 ++++++-------
samples/dci-cargo/README.txt | 2 +-
tools/envisage/src/docs/envisage.txt | 2 +-
tutorials/composites/src/docs/step1.txt | 4 +--
tutorials/composites/src/docs/step2.txt | 4 +--
tutorials/composites/src/docs/step5.txt | 6 ++--
tutorials/composites/src/docs/step7.txt | 8 +++---
tutorials/composites/src/docs/step8.txt | 4 +--
tutorials/composites/src/docs/step9.txt | 4 +--
.../composites/src/docs/tut-composites.txt | 8 +++---
tutorials/introduction/src/docs/background.txt | 14 ++++-----
tutorials/introduction/src/docs/qi4j-cop.txt | 4 +--
.../introduction/src/docs/state-modeling.txt | 16 +++++------
.../introduction/src/docs/whats-an-object.txt | 14 ++++-----
.../tenminutes/src/docs/ten-minutes.txt | 28 +++++++++---------
.../thirtyminutes/src/docs/thirty-minutes.txt | 24 ++++++++--------
.../twohours/src/docs/two-hours.txt | 8 +++---
.../twominutes/src/docs/two-minutes.txt | 10 +++----
tutorials/services/src/docs/step1.txt | 4 +--
tutorials/services/src/docs/step2.txt | 2 +-
tutorials/services/src/docs/step3.txt | 6 ++--
tutorials/services/src/docs/tut-services.txt | 4 +--
73 files changed, 260 insertions(+), 261 deletions(-)
----------------------------------------------------------------------
http://git-wip-us.apache.org/repos/asf/zest-qi4j/blob/88b203bb/core/api/src/docs/composition.txt
----------------------------------------------------------------------
diff --git a/core/api/src/docs/composition.txt b/core/api/src/docs/composition.txt
index a06c965..467fd7a 100644
--- a/core/api/src/docs/composition.txt
+++ b/core/api/src/docs/composition.txt
@@ -47,12 +47,12 @@ these, so the right meta type is used for the right purpose.
* Service - Service is injectable to other composites and java objects. They are not persistable, but if
referenced from an Entity or Value, a new reference to the Service will be injected when the Entity/Value is
deserialized. Services are singletons. There are 'hosted' and 'imported' Services. The 'hosted' Service has
- Configuration and its life cycle controlled by the Zest� runtime, whereas the 'imported' Services are external
+ Configuration and its life cycle controlled by the Zest™ runtime, whereas the 'imported' Services are external
references.
* Transient - Short-lived composites that are not persistable. Equals/hashCode/toString are forwarded to the
Mixin Type declaring those methods explicitly.
-In versions of Zest� prior to 2.0 (then Qi4j), composite types had to extend one of these 4 meta types, but in 2.0 and later, the
+In versions of Zest™ prior to 2.0 (then Qi4j), composite types had to extend one of these 4 meta types, but in 2.0 and later, the
meta type interface is added dynamically during <<core-bootstrap-assembly>>.
We can therefor get rid of a lot of additional types, and use Zest-free interfaces directly;
http://git-wip-us.apache.org/repos/asf/zest-qi4j/blob/88b203bb/core/api/src/docs/concern.txt
----------------------------------------------------------------------
diff --git a/core/api/src/docs/concern.txt b/core/api/src/docs/concern.txt
index 0b39a9c..3d6e36f 100644
--- a/core/api/src/docs/concern.txt
+++ b/core/api/src/docs/concern.txt
@@ -34,12 +34,12 @@ business domain, and can be used for many important things in the domain model,
ensure that the state in the entire composite is valid), coordinating services, handling events and much more.
Typed Concerns doesn't have to implement all the methods in the Mixin Type. By making the class abstract and only
-implementing the methods of interest, Zest� runtime will subclass the concern (otherwise not valid for the JVM), but the
+implementing the methods of interest, Zest™ runtime will subclass the concern (otherwise not valid for the JVM), but the
generated methods will never be invoked.
== Generic Concern ==
In classic AOP, all advice are effectively _generic_. There is no type information in the advice implementation and the
-pointcut can be defined anywhere in the code, and the implementation uses proxy InvocationHandlers. Zest� supports this
+pointcut can be defined anywhere in the code, and the implementation uses proxy InvocationHandlers. Zest™ supports this
construct as well, and we call it *Generic Concern*.
Generic Concerns will be added to all methods that the AppliesToFilter evaluates to true. By default, that is all methods.
http://git-wip-us.apache.org/repos/asf/zest-qi4j/blob/88b203bb/core/api/src/docs/configuration.txt
----------------------------------------------------------------------
diff --git a/core/api/src/docs/configuration.txt b/core/api/src/docs/configuration.txt
index d61e0bd..75ce54d 100644
--- a/core/api/src/docs/configuration.txt
+++ b/core/api/src/docs/configuration.txt
@@ -15,7 +15,7 @@
[[core-api-service-configuration,Service Configuration]]
= Service Configuration =
-Configuration in Zest� is for Zest� <<core-api-service>> only. The Configuration is stored in a visible Entity
+Configuration in Zest™ is for Zest™ <<core-api-service>> only. The Configuration is stored in a visible Entity
Store and is therefor runtime modifiable and not static in properties or XML files as in most other dependency
injection frameworks.
http://git-wip-us.apache.org/repos/asf/zest-qi4j/blob/88b203bb/core/api/src/docs/entitycomposite.txt
----------------------------------------------------------------------
diff --git a/core/api/src/docs/entitycomposite.txt b/core/api/src/docs/entitycomposite.txt
index c926545..b445f4b 100644
--- a/core/api/src/docs/entitycomposite.txt
+++ b/core/api/src/docs/entitycomposite.txt
@@ -22,7 +22,7 @@ Hibernate (4+ somewhat incompatible versions) and many other less known. This se
creating objects that survives over long periods of time is a difficult one.
Eric Evans points out in his book that Entities is a very definite and distinct concept that needs to be handled
-explicitly. Composite Oriented Programming in general, and Zest� in particular, takes this point very seriously and
+explicitly. Composite Oriented Programming in general, and Zest™ in particular, takes this point very seriously and
makes Entities a central part of the whole system. And likewise, we are convinced that it is not possible to develop
domain-knowledge-rich applications without a conscious and well-defined strategy on Entities. So, instead of spending
endless hours trying to get Hibernate mapping to do the right thing, we introduce a Composite meta type called
http://git-wip-us.apache.org/repos/asf/zest-qi4j/blob/88b203bb/core/api/src/docs/metrics.txt
----------------------------------------------------------------------
diff --git a/core/api/src/docs/metrics.txt b/core/api/src/docs/metrics.txt
index 6bf8bac..65f80a7 100644
--- a/core/api/src/docs/metrics.txt
+++ b/core/api/src/docs/metrics.txt
@@ -15,7 +15,7 @@
[[core-api-metrics, Metrics API]]
= Metrics API =
-The Zest� platform defines an advanced Metrics SPI to capture runtime metrics of Zest's internals as well be used by
+The Zest™ platform defines an advanced Metrics SPI to capture runtime metrics of Zest's internals as well be used by
application code (via this API) to provide production metrics for operations personnel, ensuring healthy state of
the applications.
@@ -25,7 +25,7 @@ There are quite a lot of different Metrics components available, which are insta
factory for each component type, to allow for additional components to be created in the future without breaking
compatibility in the existing implementations.
-The MetricsProvider is a standard Zest� Service and simply acquired via the @Service annotation on a field or
+The MetricsProvider is a standard Zest™ Service and simply acquired via the @Service annotation on a field or
constructor argument.
[snippet,java]
http://git-wip-us.apache.org/repos/asf/zest-qi4j/blob/88b203bb/core/api/src/docs/mixin.txt
----------------------------------------------------------------------
diff --git a/core/api/src/docs/mixin.txt b/core/api/src/docs/mixin.txt
index 241b35b..625f894 100644
--- a/core/api/src/docs/mixin.txt
+++ b/core/api/src/docs/mixin.txt
@@ -122,16 +122,16 @@ source=core/api/src/test/java/org/qi4j/api/mixin/partial/SpeedMixin.java
tag=partial
-----------
-Above the SpeedMixin only implements the accelerate() method, and Zest� will only map that method to this mixin. The
+Above the SpeedMixin only implements the accelerate() method, and Zest™ will only map that method to this mixin. The
other method of the SpeedLocation interface is not satisfied as the example is written and will generate a runtime
exception.
== Private Mixins ==
-Public mixins expose their methods in the composite interface, and this is not always desirable. Zest� supports
+Public mixins expose their methods in the composite interface, and this is not always desirable. Zest™ supports
_Private Mixins_, which are only visible within the composite itself. That means that other fragments in the composite
can see/use it, but it is not visible to the clients of the composite.
-Private Mixins are handled automatically. When Zest� detects a +@This+ annotation referring to a type that is not defined
+Private Mixins are handled automatically. When Zest™ detects a +@This+ annotation referring to a type that is not defined
in the Composite interface, then that is a Private Mixin. The Mixin implementation class, however, must exist in the
list of Mixins in the @Mixins annotation. But often, the Private Mixin only list internal Property methods in the Mixin
Type, which will be satisfied by the standard PropertyMixin and hence always available.
@@ -172,7 +172,7 @@ Typically, AppliesTo annotation is used to filter the methods that such Generic
and sometimes Generic Mixin implementations are "last resort".
Experience shows that Generic Mixin implementations are rare, and should only be used in extreme cases. They are
-less frequent than Generic Concern or Generic SideEffect implementations, but inside the Zest� API are a couple of
+less frequent than Generic Concern or Generic SideEffect implementations, but inside the Zest™ API are a couple of
Generic Mixin implementations that are always present to make the life of the developer easier, such as PropertyMixin,
AssociationMixin, ManyAssociationMixin, NoopMixin. The first 3 are declared on the Composite and EntityComposite
interfaces and automatically included if needed. They also serve as excellent example of what they can be used for.
@@ -193,6 +193,6 @@ which seems to indicate that Generic Mixin implementations are likely to be used
Typed Mixin implementations are much preferred in general business logic, as they will be first-class citizens of
the IDE as well, for navigation, find usage, refactoring and many other common tasks. This is one of the main
-advantages of the Zest� way of doing AOP compared to AspectJ et al, where "weaving" is something bolted onto an
+advantages of the Zest™ way of doing AOP compared to AspectJ et al, where "weaving" is something bolted onto an
application's classes via regular expressions and known naming conventions, which can change in an instance by a
developer being unaware of which PointCuts applies to his code.
http://git-wip-us.apache.org/repos/asf/zest-qi4j/blob/88b203bb/core/api/src/docs/reference/ref-api.txt
----------------------------------------------------------------------
diff --git a/core/api/src/docs/reference/ref-api.txt b/core/api/src/docs/reference/ref-api.txt
index bafff6d..eec16ce 100644
--- a/core/api/src/docs/reference/ref-api.txt
+++ b/core/api/src/docs/reference/ref-api.txt
@@ -14,10 +14,10 @@
//////////////////////
[[ref-core-api, Core API]]
-= Zest� Core API =
+= Zest™ Core API =
-The Zest� Core API is main API that Zest� developers interact with. In fact, if you need to use classes/interfaces
-in the Zest� Core SPI or Zest� Core Runtime, then please contact the Zest� Community and explain your use-case.
+The Zest™ Core API is main API that Zest™ developers interact with. In fact, if you need to use classes/interfaces
+in the Zest™ Core SPI or Zest™ Core Runtime, then please contact the Zest™ Community and explain your use-case.
The Core API is strictly layered, with no _spaghetti_ cross packages. The package list is fairly long, and
we will look at each one in detail further down.
http://git-wip-us.apache.org/repos/asf/zest-qi4j/blob/88b203bb/core/api/src/docs/servicecomposite.txt
----------------------------------------------------------------------
diff --git a/core/api/src/docs/servicecomposite.txt b/core/api/src/docs/servicecomposite.txt
index 3f19a6c..0736d90 100644
--- a/core/api/src/docs/servicecomposite.txt
+++ b/core/api/src/docs/servicecomposite.txt
@@ -24,8 +24,8 @@ to encapsulate all the behavior together with the object's state, programmers le
decoupling and re-use was to make the objects into data containers and deploy services that acted upon those data
containers. Very much what functions did on structs back in the C and Pascal days.
-Zest� will bring a lot of the behavior back to the Composite itself, but we still need Services for cross-composite
-functionality. The Zest� Service model is fairly simple, yet powerful and flexible enough to accommodate most
+Zest™ will bring a lot of the behavior back to the Composite itself, but we still need Services for cross-composite
+functionality. The Zest™ Service model is fairly simple, yet powerful and flexible enough to accommodate most
service-oriented patterns and ability to integrate well with external systems whether they are in-JVM or remote,
such as Spring, OSGi, WS-*, Rest and others.
@@ -37,7 +37,7 @@ The characteristics of a ServiceComposite compared to other Composite meta types
* It has an optional Configuration.
-_Services_ in Zest� are _singletons_, one instance per definition. That means that there may exist multiple instances
+_Services_ in Zest™ are _singletons_, one instance per definition. That means that there may exist multiple instances
of the same service type, but they can not be created on the fly in runtime, but has to be explicitly defined during
<<core-bootstrap-assembly>>.
http://git-wip-us.apache.org/repos/asf/zest-qi4j/blob/88b203bb/core/api/src/docs/structure.txt
----------------------------------------------------------------------
diff --git a/core/api/src/docs/structure.txt b/core/api/src/docs/structure.txt
index 9507633..ac4d81e 100644
--- a/core/api/src/docs/structure.txt
+++ b/core/api/src/docs/structure.txt
@@ -15,17 +15,17 @@
[[core-api-structure,Structure]]
= Structure =
-Zest� promotes a conventional view of application structure, that computer science has been using for decades.
+Zest™ promotes a conventional view of application structure, that computer science has been using for decades.
The definition is as follows;
- * One Application per Zest� runtime instance.
+ * One Application per Zest™ runtime instance.
* One or more Layers per Application.
* Zero, one or more Modules per Layer.
* Zero, one or more Assemblies per Module.
The principle of this Structure is to assist the programmer to create well modularized applications, that are easily
-extended and maintained. Zest� will restrict access between Modules, so that code can only reach Composites and Objects
+extended and maintained. Zest™ will restrict access between Modules, so that code can only reach Composites and Objects
in Modules (including itself) of the same or lower Layers.
Each Layer has to be declared which lower Layer(s) it uses, and it is not allowed that a lower Layer uses a higher
@@ -33,20 +33,20 @@ Layer, i.e. cyclic references.
[[core-api-application,Application]]
= Application =
-Every Zest� runtime has _one and only one_ Application in it. It is possible to run multiple Zest� runtimes in the same
-JVM, and it is even possible to embed a Zest� runtime within a Zest� Application, but there can only be one Application
-in a Zest� runtime.
+Every Zest™ runtime has _one and only one_ Application in it. It is possible to run multiple Zest™ runtimes in the same
+JVM, and it is even possible to embed a Zest™ runtime within a Zest™ Application, but there can only be one Application
+in a Zest™ runtime.
An Application is then broken into layers and modules are placed within those layers. Composites are placed within
-modules. This forms the Application Structure and is enforced by the Zest� runtime.
+modules. This forms the Application Structure and is enforced by the Zest™ runtime.
[[core-api-layer,Layer]]
= Layer =
-A Zest� Application must consist of at least one layer. More layers are common, often dividing the application along the
+A Zest™ Application must consist of at least one layer. More layers are common, often dividing the application along the
common architectural diagrams used on whiteboards, perhaps with a UI layer at the top, followed by a service or application
layer, then with a domain layer and finally some persistence layer at the bottom.
-Zest� enforces this layering by requiring the <<core-bootstrap-assembly>> to declare which layer uses which other layer. And
+Zest™ enforces this layering by requiring the <<core-bootstrap-assembly>> to declare which layer uses which other layer. And
<<core-api-visibility>> rules define that layers below can not locate composites in layers above. Also, defining that
"Layer1 uses Layer2" and "Layer2 uses Layer3" does NOT imply that Layer1 has <<core-api-visibility>> to Layer3. If that
is wanted, then it must be declared explicitly.
@@ -60,7 +60,7 @@ belongs to a single Layer, but many Modules can exist in the same Layer. Composi
* Composites from Modules in the same Layer, with Visibility set to Visibility.layer
* Composites from Modules in Layers below, with Visibility set to Visibility.application
-Modules contains a lot of the Zest� infrastructure, which are the enforcers of these wise modularization principles.
+Modules contains a lot of the Zest™ infrastructure, which are the enforcers of these wise modularization principles.
It is not possible to modify the Modules, their resolution nor binding in any way after the application starts.
http://git-wip-us.apache.org/repos/asf/zest-qi4j/blob/88b203bb/core/api/src/docs/type-lookup.txt
----------------------------------------------------------------------
diff --git a/core/api/src/docs/type-lookup.txt b/core/api/src/docs/type-lookup.txt
index 100d480..2340fab 100644
--- a/core/api/src/docs/type-lookup.txt
+++ b/core/api/src/docs/type-lookup.txt
@@ -23,7 +23,7 @@
Composite Types Lookup can occurs when you explicitely lookup for a Composite by Type
(ex. ServiceFinder.findService(..) methods), when you ask for an injection or when you create a new composite instance.
-All theses type lookup start from a Module, are lazy, cached and obey the Zest� Visibility rules. Type Lookup works
+All theses type lookup start from a Module, are lazy, cached and obey the Zest™ Visibility rules. Type Lookup works
equally accross Composite Types with some subtle differences when it comes to Services and Entities.
http://git-wip-us.apache.org/repos/asf/zest-qi4j/blob/88b203bb/core/api/src/docs/unitofwork.txt
----------------------------------------------------------------------
diff --git a/core/api/src/docs/unitofwork.txt b/core/api/src/docs/unitofwork.txt
index 582aefe..d8ad3bc 100644
--- a/core/api/src/docs/unitofwork.txt
+++ b/core/api/src/docs/unitofwork.txt
@@ -19,7 +19,7 @@ A UnitOfWork is a bounded group of operations performed, typically on entities,
to other threads until the UnitOfWork is completed. It is also possible to discard these operations, as if they were
never executed.
-NOTE: UnitOfWork has many similarities with the Transaction concept used with RDBMSes. But since Zest� introduced several deviations to the common definitions of Transactions, we chose to use a different term.
+NOTE: UnitOfWork has many similarities with the Transaction concept used with RDBMSes. But since Zest™ introduced several deviations to the common definitions of Transactions, we chose to use a different term.
There are several key characteristics of UnitOfWork;
@@ -44,5 +44,5 @@ and aborting the UnitOfWork is handled by the transaction boundary, often in the
<<core-api-layer>>)
Since it is very common to have all, or nearly all, methods in the _transaction boundary_ to handle the creation and
-completion, possibly with retry, in the same class, module or even layer, Zest� provides annotations to easily declare
+completion, possibly with retry, in the same class, module or even layer, Zest™ provides annotations to easily declare
UnitOfWork concern: @UnitOfWorkPropagation, @UnitOfWorkDiscardOn and @UnitOfWorkRetry
http://git-wip-us.apache.org/repos/asf/zest-qi4j/blob/88b203bb/core/api/src/docs/valuecomposite.txt
----------------------------------------------------------------------
diff --git a/core/api/src/docs/valuecomposite.txt b/core/api/src/docs/valuecomposite.txt
index f080376..7f06ec7 100644
--- a/core/api/src/docs/valuecomposite.txt
+++ b/core/api/src/docs/valuecomposite.txt
@@ -21,7 +21,7 @@ immutable and can be compared by value instead of memory reference. Concurrency
the value exists or it doesn't, no need for synchronization. Values are typically very easy to test and very robust to
refactoring.
-Zest� defines values as a primary meta type through the ValueComposite, as we think the benefits of values are great.
+Zest™ defines values as a primary meta type through the ValueComposite, as we think the benefits of values are great.
The ValueComposite is very light-weight compared to the EntityComposite, and its value can still be persisted as part
of an EntityComposite via a Property.
http://git-wip-us.apache.org/repos/asf/zest-qi4j/blob/88b203bb/core/bootstrap/src/docs/bootstrap.txt
----------------------------------------------------------------------
diff --git a/core/bootstrap/src/docs/bootstrap.txt b/core/bootstrap/src/docs/bootstrap.txt
index 7b500b7..56be2d0 100644
--- a/core/bootstrap/src/docs/bootstrap.txt
+++ b/core/bootstrap/src/docs/bootstrap.txt
@@ -22,7 +22,7 @@
source=core/bootstrap/dev-status.xml
--------------
-Zest� has a distinct bootstrap phase, also known as the _Assembly_ of an application, where the applications structure
+Zest™ has a distinct bootstrap phase, also known as the _Assembly_ of an application, where the applications structure
is defined programmatically. Once all the layers, modules and all the composite types in each module have been defined
the model is instantiated into an application. This enables the entire _structure_ system in Zest, where types "belongs"
to a module and visibility rules define default behaviors, enforcement of architectural integrity and much more.
@@ -43,7 +43,7 @@ You can also;
* Add additional interfaces to composites dynamically.
* Add concerns, mixins, constraints and side effects dynamically.
* Set _meta information_ on defined types.
- * Import external services to be available as Zest� services.
+ * Import external services to be available as Zest™ services.
* Tag services with markers
include::../../build/docs/buildinfo/artifact.txt[]
@@ -168,7 +168,7 @@ tag=UsingAssembler
[[core-bootstrap-assembly-layered,Layered Application Assembler]]
== Layered Application Assembler (RECOMMENDED!) ==
-In 2.1, a new way to instantiate Zest� applications was introduced. It starts with subclassing the
+In 2.1, a new way to instantiate Zest™ applications was introduced. It starts with subclassing the
+LayeredApplicationAssembler+, and implementing the +assembleLayers()+ method.
In the +assembleLayers()+ method, one is epected to either call the +createLayer()+ method in the super class
@@ -206,7 +206,7 @@ For example code, see the tutorial <<howto-assemble-application>>.
== Singleton Assembler ==
-Every Zest� runtime instance consist of One Application, with one or more Layers and one or more Modules in each Layer.
+Every Zest™ runtime instance consist of One Application, with one or more Layers and one or more Modules in each Layer.
So the minimal application is still one layer with one module. This is not recommended other than for testing purposes
and really trivial applications.
@@ -218,7 +218,7 @@ source=core/bootstrap/src/test/java/org/qi4j/bootstrap/DocumentationSupport.java
tag=singleton
--------------
-Once the SingletonAssembler constructor returns, the Zest� application is up and running.
+Once the SingletonAssembler constructor returns, the Zest™ application is up and running.
The SingletonAssembler also makes common system resources available from the bootstrap code, such as
Module, UnitOfWorkFactory and others. This is possible since there is only one Module.
@@ -274,10 +274,10 @@ tag=pancake
== Full Assembly ==
Full Assembly means that you have the opportunity to create any layer/module hierarchy that are within the rules of the
-Zest� runtime. It requires more support in your code to be useful, and the example below is by no means a recommended way
+Zest™ runtime. It requires more support in your code to be useful, and the example below is by no means a recommended way
to organize large application assemblies.
-In principle, you first start the Zest� runtime, call newApplication with an ApplicationAssembler instance and call
+In principle, you first start the Zest™ runtime, call newApplication with an ApplicationAssembler instance and call
activate() on the returned application. The ApplicationAssembler instance will be called with an
ApplicationAssemblyFactory, which is used to create an ApplicationAssembly describing the application structure.
http://git-wip-us.apache.org/repos/asf/zest-qi4j/blob/88b203bb/core/functional/src/docs/functional.txt
----------------------------------------------------------------------
diff --git a/core/functional/src/docs/functional.txt b/core/functional/src/docs/functional.txt
index 1b0c3f4..461e091 100644
--- a/core/functional/src/docs/functional.txt
+++ b/core/functional/src/docs/functional.txt
@@ -21,9 +21,9 @@
source=core/functional/dev-status.xml
--------------
-The Zest� Core Functional API is a generic package to work with Iterables in a "functional programming language" style.
+The Zest™ Core Functional API is a generic package to work with Iterables in a "functional programming language" style.
-This package is completely independent of everything else in Zest� and may be used on its own in any kind of environment
+This package is completely independent of everything else in Zest™ and may be used on its own in any kind of environment
such as Spring or Java EE applications.
include::../../build/docs/buildinfo/artifact.txt[]
@@ -38,7 +38,7 @@ source=core/functional/src/test/java/org/qi4j/functional/docsupport/FunctionalDo
tag=func1
-----------
-With the Zest� Core Functional API, you go about it in a different way. The code ends up looking like this;
+With the Zest™ Core Functional API, you go about it in a different way. The code ends up looking like this;
[snippet,java]
-----------
@@ -50,11 +50,11 @@ And this is just the tip of the iceberg.
== The Big Picture ==
-The Zest� Core Functional API are divided a handful of powerful concepts, especially when used together;
+The Zest™ Core Functional API are divided a handful of powerful concepts, especially when used together;
* *Iterables* - many methods to deal with Iterable data, so that the loops in your programs can largely be removed.
- * *Functions* - f(x) and f(x,y) are well-know from mathematics and used in functional programming languages. Zest� is
+ * *Functions* - f(x) and f(x,y) are well-know from mathematics and used in functional programming languages. Zest™ is
not capable of introducing lambda calculus due to limitations in Java itself, but we can simulate a lot to allow
people to create more readable code.
http://git-wip-us.apache.org/repos/asf/zest-qi4j/blob/88b203bb/core/io/src/docs/io.txt
----------------------------------------------------------------------
diff --git a/core/io/src/docs/io.txt b/core/io/src/docs/io.txt
index a8b85a8..d8ffef8 100644
--- a/core/io/src/docs/io.txt
+++ b/core/io/src/docs/io.txt
@@ -21,10 +21,10 @@
source=core/io/dev-status.xml
--------------
-The Zest� Core I/O API is completely generic and not tied to the Zest� programming model as a whole. It can be used
-independently of Zest, together with the Zest� Core Functional API, which the Core I/O API depends on.
+The Zest™ Core I/O API is completely generic and not tied to the Zest™ programming model as a whole. It can be used
+independently of Zest, together with the Zest™ Core Functional API, which the Core I/O API depends on.
-The Zest� Core I/O API tries to address the problem around shuffling data around from various I/O inputs and outputs,
+The Zest™ Core I/O API tries to address the problem around shuffling data around from various I/O inputs and outputs,
possibly with transformations and filtering along the way. It was identified that there is a general mix-up of concerns
in the stereotypical I/O handling codebases that people deal with all the time. The reasoning around this, can be found
in the <<howto-use-io>>, and is recommended reading.
@@ -44,7 +44,7 @@ source.copyTo( destination );
It seems natural to do, yet it is not present for us. We need to involve FileInputStream/FileOutputStream, wrap them
in Buffered versions of it, do our own looping, close the streams afterwards and what not. So, the java.io.File does
-not have this simple feature and in the Zest� Core API, we need to work around this limitation. We also want to
+not have this simple feature and in the Zest™ Core API, we need to work around this limitation. We also want to
make the abstraction a little bit more encompassing than "just" files. So how does that look like then?
== First Examples ==
@@ -60,7 +60,7 @@ tag=io1
-----------
Pretty much self-explanatory, wouldn't you say? But what happened to the handling of exceptions and closing of
-resources? It is all handled inside the Zest� Core I/O API. There is nothing you can forget to do.
+resources? It is all handled inside the Zest™ Core I/O API. There is nothing you can forget to do.
Another simple example, where we want to count the number of lines in the text;
@@ -127,7 +127,7 @@ interface. For O/S resources, they are handled purely inside the Input and Outpu
Sender/Receiver are effectively dealing with the data itself.
== org.qi4j.io.Transforms ==
-The 3 component in the Zest� Core I/O API is the transformations that are possible. Interestingly enough, with the
+The 3 component in the Zest™ Core I/O API is the transformations that are possible. Interestingly enough, with the
above separation of concerns, we don't need an InputOutput type that can both receive and send data. Instead, we
simply need to prepare easy to use static factory methods, which are found in the org.qi4j.io.Transforms class. Again,
it is fairly straight forward to create your own Transforms if you need something not provided here.
@@ -176,7 +176,7 @@ tag=progress
It combines the Counter and the Log implementations, so that the count is forwarded to the Log at a given interval, such
as every 1000 items. This may not be what you think a ProgressLog should look like, but it serves as a good example on
-how you can combine the general principles found in the Zest� Core API package.
+how you can combine the general principles found in the Zest™ Core API package.
== How to write a filter specification? ==
The filter transform takes a specification implementation which has a very simple method, isSatisfiedBy() (read more
http://git-wip-us.apache.org/repos/asf/zest-qi4j/blob/88b203bb/core/spi/src/docs/spi.txt
----------------------------------------------------------------------
diff --git a/core/spi/src/docs/spi.txt b/core/spi/src/docs/spi.txt
index 5b000ea..32fc8b2 100644
--- a/core/spi/src/docs/spi.txt
+++ b/core/spi/src/docs/spi.txt
@@ -21,7 +21,7 @@
source=core/spi/dev-status.xml
--------------
-The Zest� Core Runtime has a number of extension points, which we call the _Qi4j Core Extension SPI_. These are defined
+The Zest™ Core Runtime has a number of extension points, which we call the _Qi4j Core Extension SPI_. These are defined
interfaces used *only* by the Core Runtime and *never* directly by application code. <<extensions>> are assembled in
applications during the bootstrap phase.
@@ -35,7 +35,7 @@ There are currently 5 Core SPI extensions;
* <<core-spi-indexing>>
* <<core-spi-metrics>>
-Zest� Runtime Extensions implementations may depend on Zest� Libraries, but Libraries are NOT ALLOWED to depend on
+Zest™ Runtime Extensions implementations may depend on Zest™ Libraries, but Libraries are NOT ALLOWED to depend on
Extensions. Applications code is NOT ALLOWED to depend on extensions. And application code SHOULD NOT depend on the
Core Extension SPI. If you think that is needed, please contact qi4j-dev forum at Google Groups, to see if your usecase
can be solved in a support manner, or that we need to extend the Core API to support it.
http://git-wip-us.apache.org/repos/asf/zest-qi4j/blob/88b203bb/core/spi/src/docs/valueserialization.txt
----------------------------------------------------------------------
diff --git a/core/spi/src/docs/valueserialization.txt b/core/spi/src/docs/valueserialization.txt
index 1d4b650..fa5fb86 100644
--- a/core/spi/src/docs/valueserialization.txt
+++ b/core/spi/src/docs/valueserialization.txt
@@ -22,7 +22,7 @@
== Overview ==
-The Zest� Core Runtime use ValueSerialization to provide string representation of ValueComposites via their `toString()`
+The Zest™ Core Runtime use ValueSerialization to provide string representation of ValueComposites via their `toString()`
method, and, their instanciation from the very same representation via the `newValueFromSerializedState(..)` method of
the ValueBuilderFactory API.
http://git-wip-us.apache.org/repos/asf/zest-qi4j/blob/88b203bb/core/testsupport/src/docs/testsupport.txt
----------------------------------------------------------------------
diff --git a/core/testsupport/src/docs/testsupport.txt b/core/testsupport/src/docs/testsupport.txt
index 82d6ed9..f3c9585 100644
--- a/core/testsupport/src/docs/testsupport.txt
+++ b/core/testsupport/src/docs/testsupport.txt
@@ -21,15 +21,15 @@
source=core/testsupport/dev-status.xml
--------------
-Zest� comes with classes to help with testing. For general development, only a couple of classes are of interest as the
+Zest™ comes with classes to help with testing. For general development, only a couple of classes are of interest as the
others are mostly for EntityStore and Index/Query SPI implementations. There is also some mocking support, to allow
-some of Zest's unique aspects to be mocked, but since Zest� is so flexible at a fine-granular level, we have found that
+some of Zest's unique aspects to be mocked, but since Zest™ is so flexible at a fine-granular level, we have found that
mocking is seldom, if ever, needed.
include::../../build/docs/buildinfo/artifact.txt[]
== Your First Testcase ==
-In most cases, you will probably use the AbstractQi4jTest class to simplify starting a Zest� test instance.
+In most cases, you will probably use the AbstractQi4jTest class to simplify starting a Zest™ test instance.
[snippet,java]
--------------
@@ -37,7 +37,7 @@ source=tutorials/hello/src/test/java/org/qi4j/tutorials/hello/HelloTest.java
tag=step1
--------------
-This will do all the initialization of a Zest� runtime instance and create a single layer with a single module in it.
+This will do all the initialization of a Zest™ runtime instance and create a single layer with a single module in it.
What goes into that module is declared in the assembly() method;
[snippet,java]
http://git-wip-us.apache.org/repos/asf/zest-qi4j/blob/88b203bb/extensions/entitystore-voldemort/src/docs/es-voldemort.txt
----------------------------------------------------------------------
diff --git a/extensions/entitystore-voldemort/src/docs/es-voldemort.txt b/extensions/entitystore-voldemort/src/docs/es-voldemort.txt
index 5837bd1..9d6d7b3 100644
--- a/extensions/entitystore-voldemort/src/docs/es-voldemort.txt
+++ b/extensions/entitystore-voldemort/src/docs/es-voldemort.txt
@@ -41,7 +41,7 @@ tag=assembly
== Configuration ==
-Most of the configuration of Voldemort is available in the Zest� Configuration Entity.
+Most of the configuration of Voldemort is available in the Zest™ Configuration Entity.
[snippet,java]
----
http://git-wip-us.apache.org/repos/asf/zest-qi4j/blob/88b203bb/extensions/indexing-solr/src/docs/index-solr.txt
----------------------------------------------------------------------
diff --git a/extensions/indexing-solr/src/docs/index-solr.txt b/extensions/indexing-solr/src/docs/index-solr.txt
index 2f0ebd8..e964831 100644
--- a/extensions/indexing-solr/src/docs/index-solr.txt
+++ b/extensions/indexing-solr/src/docs/index-solr.txt
@@ -27,7 +27,7 @@ source=extensions/indexing-solr/dev-status.xml
Index/Query services backed by an embedded http://lucene.apache.org/solr/[Apache Solr Search].
-WARNING: Solr Index/Query service do not support the Zest� Query API but only native Solr queries.
+WARNING: Solr Index/Query service do not support the Zest™ Query API but only native Solr queries.
include::../../build/docs/buildinfo/artifact.txt[]
http://git-wip-us.apache.org/repos/asf/zest-qi4j/blob/88b203bb/extensions/indexing-sql/instructions.txt
----------------------------------------------------------------------
diff --git a/extensions/indexing-sql/instructions.txt b/extensions/indexing-sql/instructions.txt
index 5bed896..3b38bca 100644
--- a/extensions/indexing-sql/instructions.txt
+++ b/extensions/indexing-sql/instructions.txt
@@ -20,7 +20,7 @@
These instructions are for preparing your out-of-box PostgreSQL installation so it would be usable with PostgreSQL indexing of Zest.
1. Creating login role and database
-1.1. Using pgAdmin, connect to PostgreSQL database, and create database you intend to use to store Zest� entity data, and login role for Zest� application to use when it connects to database.
+1.1. Using pgAdmin, connect to PostgreSQL database, and create database you intend to use to store Zest™ entity data, and login role for Zest™ application to use when it connects to database.
1.1. Update these values into your .properties file, if necessary.
2. Adding ltree as type
@@ -29,6 +29,6 @@ These instructions are for preparing your out-of-box PostgreSQL installation so
2.3. This will open new window, erase any text which pgAdmin generates there for you.
2.4. Then navigate to your PostgreSQL installation directory, then into 'share', and then into 'contrib'. Open file 'ltree.sql' in your favorite text editor.
2.5. Select all text, copy it, and paste to SQL query window which you opened in stage 2.2.
-2.6. If you know what you are doing, you may change the line 'SET search_path = public;' to make search_path be 'pg_catalog', or name of schema that Zest� application will use ('qi4j' by default). It's ok to leave it to 'public' though.
+2.6. If you know what you are doing, you may change the line 'SET search_path = public;' to make search_path be 'pg_catalog', or name of schema that Zest™ application will use ('qi4j' by default). It's ok to leave it to 'public' though.
2.7. Hit F5 or go Query -> Execute Query to execute the SQL. It should print some notices into output window but no errors nor warnings should be present.
2.8. Ltree type should be now installed to your PostgreSQL installation.
http://git-wip-us.apache.org/repos/asf/zest-qi4j/blob/88b203bb/libraries/alarm/src/docs/alarm.txt
----------------------------------------------------------------------
diff --git a/libraries/alarm/src/docs/alarm.txt b/libraries/alarm/src/docs/alarm.txt
index 996a9fe..c0c7a59 100644
--- a/libraries/alarm/src/docs/alarm.txt
+++ b/libraries/alarm/src/docs/alarm.txt
@@ -78,7 +78,7 @@ tag=documentation
--------------
== Alarm Models ==
-The Zest� Alarm library comes with 3 _Alarm Models_ which should be sufficient for most uses. These are based on decades
+The Zest™ Alarm library comes with 3 _Alarm Models_ which should be sufficient for most uses. These are based on decades
of experience from the industrial automation industry and user feedback.
== Simple Alarm Model ==
http://git-wip-us.apache.org/repos/asf/zest-qi4j/blob/88b203bb/libraries/circuitbreaker/src/docs/circuitbreaker.txt
----------------------------------------------------------------------
diff --git a/libraries/circuitbreaker/src/docs/circuitbreaker.txt b/libraries/circuitbreaker/src/docs/circuitbreaker.txt
index 7b074a6..6706bd5 100644
--- a/libraries/circuitbreaker/src/docs/circuitbreaker.txt
+++ b/libraries/circuitbreaker/src/docs/circuitbreaker.txt
@@ -27,7 +27,7 @@ source=libraries/circuitbreaker/dev-status.xml
The Circuit Breaker library provides a way to guard your application
against faulty external systems (e.g. mail servers being down, web
-services being down). It is used by many Zest� Extensions and Libraries.
+services being down). It is used by many Zest™ Extensions and Libraries.
There's a couple of differences between this implementation and others
seen on the net, but we've also heavily borrowed from others. The
@@ -54,7 +54,7 @@ track service levels and see exception messages, and trip/enable circuit
breakers.
Fourth, if an external system is unavailable due to a circuitbreaker
-tripping it should be possible to expose this to other Zest� services.
+tripping it should be possible to expose this to other Zest™ services.
There is a standard implementation of the Availability interface that
delegates to a circuit breaker and the Enabled configuration flag, which
is what we'd suspect will be used in most cases where external systems
@@ -64,7 +64,7 @@ include::../../build/docs/buildinfo/artifact.txt[]
== Direct usage ==
-The CircuitBreaker can be used directly, even without using anything else from the Zest� SDK.
+The CircuitBreaker can be used directly, even without using anything else from the Zest™ SDK.
Here is a code snippet that demonstrate how to create a CircuitBreaker and how it behave:
http://git-wip-us.apache.org/repos/asf/zest-qi4j/blob/88b203bb/libraries/constraints/src/docs/constraints.txt
----------------------------------------------------------------------
diff --git a/libraries/constraints/src/docs/constraints.txt b/libraries/constraints/src/docs/constraints.txt
index f0a7e59..c358f75 100644
--- a/libraries/constraints/src/docs/constraints.txt
+++ b/libraries/constraints/src/docs/constraints.txt
@@ -26,7 +26,7 @@ source=libraries/constraints/dev-status.xml
--------------
The Constraints library provide a bunch of often used Constraints based on the
-Zest� Constraints api described in <<def-constraint>>.
+Zest™ Constraints api described in <<def-constraint>>.
Remember that you are not limited to constraints presents in this library, you
are encouraged to write your own constraints. See <<howto-create-constraint>>
http://git-wip-us.apache.org/repos/asf/zest-qi4j/blob/88b203bb/libraries/eventsourcing-jdbm/src/docs/eventsourcing-jdbm.txt
----------------------------------------------------------------------
diff --git a/libraries/eventsourcing-jdbm/src/docs/eventsourcing-jdbm.txt b/libraries/eventsourcing-jdbm/src/docs/eventsourcing-jdbm.txt
index 2202240..a2ead6e 100644
--- a/libraries/eventsourcing-jdbm/src/docs/eventsourcing-jdbm.txt
+++ b/libraries/eventsourcing-jdbm/src/docs/eventsourcing-jdbm.txt
@@ -25,7 +25,6 @@
source=libraries/eventsourcing-jdbm/dev-status.xml
--------------
-Event Sourcing - JDBM Library
NOTE: This Library has no documentation yet. Learn how to contribute in <<community-docs>>.
http://git-wip-us.apache.org/repos/asf/zest-qi4j/blob/88b203bb/libraries/fileconfig/src/docs/fileconfig.txt
----------------------------------------------------------------------
diff --git a/libraries/fileconfig/src/docs/fileconfig.txt b/libraries/fileconfig/src/docs/fileconfig.txt
index 5baa0a4..ac973e6 100644
--- a/libraries/fileconfig/src/docs/fileconfig.txt
+++ b/libraries/fileconfig/src/docs/fileconfig.txt
@@ -27,7 +27,7 @@ source=libraries/fileconfig/dev-status.xml
The FileConfig library provide a service for accessing application-specific directories.
-A lot of the Zest� Libraries and Extensions make use of this library to locate files.
+A lot of the Zest™ Libraries and Extensions make use of this library to locate files.
include::../../build/docs/buildinfo/artifact.txt[]
http://git-wip-us.apache.org/repos/asf/zest-qi4j/blob/88b203bb/libraries/http/src/docs/http.txt
----------------------------------------------------------------------
diff --git a/libraries/http/src/docs/http.txt b/libraries/http/src/docs/http.txt
index 3c135dd..654220f 100644
--- a/libraries/http/src/docs/http.txt
+++ b/libraries/http/src/docs/http.txt
@@ -29,7 +29,7 @@ The HTTP library provides a Jetty based embedded HTTP service with support for e
filters assembly as Services.
It's an easy way to embedd a servlet container and reuse everything that can be run in it (JAX-*, Restlet, Wicket,
-Vaadin, GWT etc..). If instead you want to run a Zest� Application in a servlet container, see <<library-servlet>>.
+Vaadin, GWT etc..). If instead you want to run a Zest™ Application in a servlet container, see <<library-servlet>>.
include::../../build/docs/buildinfo/artifact.txt[]
@@ -90,7 +90,7 @@ tag=jmx
=== Configuration ===
-Underlying Jetty engine configuration is exposed as a Zest� Service Configuration.
+Underlying Jetty engine configuration is exposed as a Zest™ Service Configuration.
The only one that is mandatory is the port.
See org.qi4j.library.http.JettyConfiguration for a reference of all available
http://git-wip-us.apache.org/repos/asf/zest-qi4j/blob/88b203bb/libraries/jmx/src/docs/jmx.txt
----------------------------------------------------------------------
diff --git a/libraries/jmx/src/docs/jmx.txt b/libraries/jmx/src/docs/jmx.txt
index 4469048..b8421a4 100644
--- a/libraries/jmx/src/docs/jmx.txt
+++ b/libraries/jmx/src/docs/jmx.txt
@@ -25,7 +25,7 @@
source=libraries/jmx/dev-status.xml
--------------
-The JMX library provides a service that exposes a Zest� app in
+The JMX library provides a service that exposes a Zest™ app in
JMX automatically, giving you an opportunity to inspect the app much as
you would with the <<tools-envisage>> tool.
http://git-wip-us.apache.org/repos/asf/zest-qi4j/blob/88b203bb/libraries/lang-beanshell/README.txt
----------------------------------------------------------------------
diff --git a/libraries/lang-beanshell/README.txt b/libraries/lang-beanshell/README.txt
index 1d47320..aeee619 100644
--- a/libraries/lang-beanshell/README.txt
+++ b/libraries/lang-beanshell/README.txt
@@ -2,7 +2,7 @@
BeanShell is licensed under LGPL, and Apache Software Foundation
doesn't allow the use of LGPL in Apache projects.
-Therefor, Apache Zest� had to drop this library component, but
+Therefor, Apache Zest™ had to drop this library component, but
it is still available for separate download at
https://github.com/Qi4j/qi4j-sdk
http://git-wip-us.apache.org/repos/asf/zest-qi4j/blob/88b203bb/libraries/logging/src/docs/logging.txt
----------------------------------------------------------------------
diff --git a/libraries/logging/src/docs/logging.txt b/libraries/logging/src/docs/logging.txt
index dabe4e7..ed7f6b6 100644
--- a/libraries/logging/src/docs/logging.txt
+++ b/libraries/logging/src/docs/logging.txt
@@ -21,7 +21,7 @@
source=libraries/logging/dev-status.xml
--------------
-First of all, Zest� is taking a fresh look at all things that we take for granted. Logging is one such thing.
+First of all, Zest™ is taking a fresh look at all things that we take for granted. Logging is one such thing.
It should (but is not) obvious that Logging are used for three very distinct purposes, and in our opinion the concepts
are not related and should not be abstracted in the same fashion, as has been the norm in Log4j, JDK logging, Commons
http://git-wip-us.apache.org/repos/asf/zest-qi4j/blob/88b203bb/libraries/metrics/dev-status.xml
----------------------------------------------------------------------
diff --git a/libraries/metrics/dev-status.xml b/libraries/metrics/dev-status.xml
index 4ad3244..04d78d0 100644
--- a/libraries/metrics/dev-status.xml
+++ b/libraries/metrics/dev-status.xml
@@ -21,13 +21,13 @@
http://www.qi4j.org/schemas/2008/dev-status/1/dev-status.xsd">
<status>
<!--none,early,beta,stable,mature-->
- <codebase>early</codebase>
+ <codebase>beta</codebase>
<!-- none, brief, good, complete -->
<documentation>brief</documentation>
<!-- none, some, good, complete -->
- <unittests>none</unittests>
+ <unittests>some</unittests>
</status>
<licenses>
<license>ALv2</license>
http://git-wip-us.apache.org/repos/asf/zest-qi4j/blob/88b203bb/libraries/osgi/src/docs/osgi.txt
----------------------------------------------------------------------
diff --git a/libraries/osgi/src/docs/osgi.txt b/libraries/osgi/src/docs/osgi.txt
index cee2129..957bbfc 100644
--- a/libraries/osgi/src/docs/osgi.txt
+++ b/libraries/osgi/src/docs/osgi.txt
@@ -25,12 +25,12 @@
source=libraries/osgi/dev-status.xml
--------------
-OSGi Library allows you to import OSGi services as Zest� Services and to export Zest� Services as OSGi Services both
-leveraging the Zest� Availability and OSGi FallbackStrategy mechanisms.
+OSGi Library allows you to import OSGi services as Zest™ Services and to export Zest™ Services as OSGi Services both
+leveraging the Zest™ Availability and OSGi FallbackStrategy mechanisms.
include::../../build/docs/buildinfo/artifact.txt[]
-== Export Zest� services to an OSGi Bundle ==
+== Export Zest™ services to an OSGi Bundle ==
[snippet,java]
----
@@ -39,7 +39,7 @@ tag=export
----
-== Import OSGi services in a Zest� Module ==
+== Import OSGi services in a Zest™ Module ==
[snippet,java]
----
http://git-wip-us.apache.org/repos/asf/zest-qi4j/blob/88b203bb/libraries/rest-client/src/docs/primer.txt
----------------------------------------------------------------------
diff --git a/libraries/rest-client/src/docs/primer.txt b/libraries/rest-client/src/docs/primer.txt
index 6ed3a9d..62245bd 100644
--- a/libraries/rest-client/src/docs/primer.txt
+++ b/libraries/rest-client/src/docs/primer.txt
@@ -20,7 +20,7 @@
[[library-rest-client-primer, HATEOAS Primer]]
= ReST - HATEOAS Primer
-The Zest� ReST Client implements HATEOAS (Hypermedia As The Engine Of Application State) to the full extent intended
+The Zest™ ReST Client implements HATEOAS (Hypermedia As The Engine Of Application State) to the full extent intended
by Roy Fielding. The ReST Client Library enables the creation of HATEOAS applications that are NOT using the URL space,
and it is NOT about doing RPC calls over HTTP using a common exchange format (like JSON).
@@ -81,5 +81,5 @@ It becomes possible to blend general application and error handling logic with u
That's basically it. This is where I want to go with support for REST, as a way to truly leverage the REST ideas and
make it very easy to do REST applications *and* clients based on Zest, by keeping the application logic on the server.
In the long run there would also be a JavaScript version of the client, with the same characteristics, so that you can
-easily build a jQuery UI for Zest� REST apps.
+easily build a jQuery UI for Zest™ REST apps.
http://git-wip-us.apache.org/repos/asf/zest-qi4j/blob/88b203bb/libraries/servlet/src/docs/servlet.txt
----------------------------------------------------------------------
diff --git a/libraries/servlet/src/docs/servlet.txt b/libraries/servlet/src/docs/servlet.txt
index 48974ee..4af90c1 100644
--- a/libraries/servlet/src/docs/servlet.txt
+++ b/libraries/servlet/src/docs/servlet.txt
@@ -25,16 +25,16 @@
source=libraries/servlet/dev-status.xml
--------------
-This library provide the necessary boilerplate code to bootstrap a Zest� Application in a Servlet container plus some
+This library provide the necessary boilerplate code to bootstrap a Zest™ Application in a Servlet container plus some
facilities. It aims at a very simple need and is provided as an example integration.
-If instead you want to run a servlet container inside a Zest� Application, see <<library-http>>.
+If instead you want to run a servlet container inside a Zest™ Application, see <<library-http>>.
include::../../build/docs/buildinfo/artifact.txt[]
== Application Bootstrap ==
-Extends `AbstractQi4jServletBootstrap` to easily bind a Zest� `Application` activation/passivation to your webapp
+Extends `AbstractQi4jServletBootstrap` to easily bind a Zest™ `Application` activation/passivation to your webapp
lifecycle.
Use `Qi4jServletSupport#application(javax.servlet.ServletContext)` to get a handle on the `Application` from the
http://git-wip-us.apache.org/repos/asf/zest-qi4j/blob/88b203bb/libraries/spring/src/docs/spring.txt
----------------------------------------------------------------------
diff --git a/libraries/spring/src/docs/spring.txt b/libraries/spring/src/docs/spring.txt
index 458eb99..12ec47e 100644
--- a/libraries/spring/src/docs/spring.txt
+++ b/libraries/spring/src/docs/spring.txt
@@ -27,14 +27,14 @@ source=libraries/spring/dev-status.xml
include::../../build/docs/buildinfo/artifact.txt[]
-== Using Spring Framework in Apache Zest� ==
-Zest� supports that Spring Application Context is imported into the Zest� runtime, and the declared Spring
-beans will be available as Zest� services. The most important things to remember are;
+== Using Spring Framework in Apache Zest™ ==
+Zest™ supports that Spring Application Context is imported into the Zest™ runtime, and the declared Spring
+beans will be available as Zest™ services. The most important things to remember are;
1. Only Spring Singletons are currently supported.
- 2. One ApplicationContext per Zest� Module.
- 3. The Zest� service will be given the same name as the Spring Bean name.
- 4. Zest� Configuration is not reacbable from the Spring bean (kind of obvious).
+ 2. One ApplicationContext per Zest™ Module.
+ 3. The Zest™ service will be given the same name as the Spring Bean name.
+ 4. Zest™ Configuration is not reacbable from the Spring bean (kind of obvious).
[snippet,java]
----
@@ -42,10 +42,10 @@ source=libraries/spring/src/test/java/org/qi4j/library/spring/importer/Qi4jImpor
tag=import
----
-== Using Apache Zest� in Spring Framework ==
-It is also possible to run a Zest� Application as a Spring Bean and export its Services to Spring.
+== Using Apache Zest™ in Spring Framework ==
+It is also possible to run a Zest™ Application as a Spring Bean and export its Services to Spring.
-Steps to export Zest� service:
+Steps to export Zest™ service:
1. Create spring BeanFactory service of qi4j services to export.
2. Create a class that extends Qi4jApplicationBootstrap.
@@ -54,7 +54,7 @@ Steps to export Zest
5. Sets the identity of bean factory service. This identity is the spring bean name.
6. Declare qi4j bootstrap in spring xml application context.
-To bootstrap the Zest� runtime in Spring, you should have a bootstrap bean that extends the
+To bootstrap the Zest™ runtime in Spring, you should have a bootstrap bean that extends the
+org.qi4j.library.spring.bootstrap.Qi4jApplicationBootstrap+ and implement the
+org.springframework.context.ApplicationContextAware+.
http://git-wip-us.apache.org/repos/asf/zest-qi4j/blob/88b203bb/manual/src/docs/tutorials/howto-assembly-application.txt
----------------------------------------------------------------------
diff --git a/manual/src/docs/tutorials/howto-assembly-application.txt b/manual/src/docs/tutorials/howto-assembly-application.txt
index 31a8e5b..e42a5cd 100644
--- a/manual/src/docs/tutorials/howto-assembly-application.txt
+++ b/manual/src/docs/tutorials/howto-assembly-application.txt
@@ -29,7 +29,7 @@ At runtime you will need the Core Runtime artifact too. See the <<howto-depend-o
First let's recap the structural requirements of Zest;
- * There is one and only one Application instance per Zest� Runtime.
+ * There is one and only one Application instance per Zest™ Runtime.
* Every Application must contain one or more Layers.
* All Composites must be declared in one or more Modules.
* Each Module belong to a Layer.
@@ -40,7 +40,7 @@ Ok, that was quite a handful. Let's look at them one by one.
== Application ==
-The first one means that for each Zest� Runtime you start, there will be exactly one application. As far as we know, Zest
+The first one means that for each Zest™ Runtime you start, there will be exactly one application. As far as we know, Zest
is fully isolated, meaning there are no static members being populated and such.
== Layers ==
@@ -58,7 +58,7 @@ that are both the top and bottom.
== Modules ==
-The Module concept has also been around forever. And in Zest� we also makes the Modules explicit. Each Module belong to a
+The Module concept has also been around forever. And in Zest™ we also makes the Modules explicit. Each Module belong to a
Layer, and for each Module you declare the Composite and Object types for that Module, together with a Visibility rule,
one of; application, layer, module.
@@ -109,7 +109,7 @@ acting addiction).
How to structure your code is beyond the scope of this section. If you are an experienced designer, you will have done
that before, and you may have started out with good intentions at times only to find yourself in a spaghetti swamp
later, or perhaps in the also famous "Clear as Clay" or "Ball (bowl?) of Mud". Either way, you need to draw on your
-experience and come up with good structure that Zest� lets you enforce.
+experience and come up with good structure that Zest™ lets you enforce.
So, for the sake of education, we are going to look at an application that consists of many layers, each with a few
modules. See picture below.
@@ -127,7 +127,7 @@ tag=main
-----------
The above is the basic setup on how to structure a real-world applicaton, unless you intend to mess with the
-implementations of various Zest� systems (yes there are hooks for that too), but that is definitely beyond the scope of
+implementations of various Zest™ systems (yes there are hooks for that too), but that is definitely beyond the scope of
this tutorial.
Now, the createXyzLayer() methods were excluded to keep the sample crisp and easy to follow. Let's take a look at what
@@ -158,5 +158,5 @@ source=manual/src/main/java/org/qi4j/manual/recipes/assemble/Main.java
tag=shutdown
-----------
-This concludes this tutorial. We have looked how to get the initial Zest� runtime going, how to declare the assembly
+This concludes this tutorial. We have looked how to get the initial Zest™ runtime going, how to declare the assembly
for application model creation and finally the activation of the model itself.
http://git-wip-us.apache.org/repos/asf/zest-qi4j/blob/88b203bb/manual/src/docs/tutorials/howto-build-system.txt
----------------------------------------------------------------------
diff --git a/manual/src/docs/tutorials/howto-build-system.txt b/manual/src/docs/tutorials/howto-build-system.txt
index 79ab6e1..e0008eb 100644
--- a/manual/src/docs/tutorials/howto-build-system.txt
+++ b/manual/src/docs/tutorials/howto-build-system.txt
@@ -20,24 +20,24 @@
[[build-system,Build System]]
= Build System =
-This tutorial is intended for developpers who want to build the Zest� SDK themselves.
-It describe the Zest� SDK Build System from compilation to publication of artifacts for consumption by other
+This tutorial is intended for developpers who want to build the Zest™ SDK themselves.
+It describe the Zest™ SDK Build System from compilation to publication of artifacts for consumption by other
applications.
-If instead you want to setup your project build system to depend on modules of the Zest� SDK see the
+If instead you want to setup your project build system to depend on modules of the Zest™ SDK see the
<<howto-depend-on-qi4j,dedicated tutorial>>.
== Gradle ==
NOTE: All major Java IDEs have great Gradle support.
-Visit the http://www.gradle.org/tooling[Gradle Tooling] page to learn how to import the Zest� SDK build into your
+Visit the http://www.gradle.org/tooling[Gradle Tooling] page to learn how to import the Zest™ SDK build into your
favorite IDE.
-Zest� community migrated away from Maven after several years of frustration, especially around release management,
+Zest™ community migrated away from Maven after several years of frustration, especially around release management,
versioning and cross-module dependency resolution issues, in Feb 2011.
The tool of choice is now Gradle, and it doesn't require any installation, there are +gradlew+ and +gradlew.bat+ in
-the root folder of the Zest� SDK that will bootstrap Gradle if not done so already.
+the root folder of the Zest™ SDK that will bootstrap Gradle if not done so already.
If you are new to Gradle, you should keep the http://www.gradle.org/documentation[documentation] at hands.
@@ -48,7 +48,7 @@ http://gradle.org/docs/current/userguide/tutorial_this_and_that.html#sec:gradle_
== Root project tasks ==
-The Zest� SDK root project has tasks that work with the whole SDK.
+The Zest™ SDK root project has tasks that work with the whole SDK.
The default build, triggered when running gradle without any command line arguments, compiles the code and run the
tests, but nothing else.
A quick way to check that nothing broke.
@@ -109,7 +109,7 @@ To see all available tasks on a submodule issue the following command:
----
This example will output all gradle tasks available in the +tests/performance+ module where you should find
-the +testPerf+ task that run the Zest� performance test suite.
+the +testPerf+ task that run the Zest™ performance test suite.
== Versions ==
@@ -131,7 +131,7 @@ If a +version+ property is not defined, the build system will refuse to make a r
== Tests ==
-NOTE: See the http://qi4j.org/community/ci.html[Zest� Continuous Integration] for current tests results
+NOTE: See the http://qi4j.org/community/ci.html[Zest™ Continuous Integration] for current tests results
// TODO
@@ -144,7 +144,7 @@ They are not part of the default build.
=== Performance tests ===
-Performance tests provide performance mesurements for typical Zest� use cases.
+Performance tests provide performance mesurements for typical Zest™ use cases.
They are not part of the default build.
// TODO
@@ -179,12 +179,12 @@ We'll list here services that the unit tests will use if available.
- MySQL for +extensions/entitystore-sql+ (need setup, see test source)
-== Releasing the Zest� SDK ==
+== Releasing the Zest™ SDK ==
IMPORTANT: Remember that if a +version+ property is not defined, the build system will refuse to make a release and upload.
-The Zest� SDK build system is setup for an easy release process.
-This is very useful to the Zest� Core Team but can also be useful to third parties that want to cut a in-house release.
+The Zest™ SDK build system is setup for an easy release process.
+This is very useful to the Zest™ Core Team but can also be useful to third parties that want to cut a in-house release.
In this regard, we try to make every aspect of the release process usable for such cases.
The following sections describe various aspects of the release process.
@@ -193,12 +193,12 @@ By default you need to have a proper PGP setup, see below.
=== Release Criteria ===
-The Zest� SDK modules are of varying maturity level and we try to maintain a STATUS (+dev-status.xml+) file indicating
+The Zest™ SDK modules are of varying maturity level and we try to maintain a STATUS (+dev-status.xml+) file indicating
how good the codebase, documentation and unit tests are for each of the modules. This is highly subjective and
potentially different individuals will judge this differently, but at least it gives a ballpark idea of the situation
for our users.
-The Zest� SDK build system use the values from the +dev-status.xml+ files to filter out non-releasable modules out for
+The Zest™ SDK build system use the values from the +dev-status.xml+ files to filter out non-releasable modules out for
the +javadocs+ and +uploadArchives+ root project tasks.
Moreover, the +release+ task ensure that no releasable module depends on module(s) that don't fit the release criteria
and throw a detailed exception if need be.
http://git-wip-us.apache.org/repos/asf/zest-qi4j/blob/88b203bb/manual/src/docs/tutorials/howto-configure-service.txt
----------------------------------------------------------------------
diff --git a/manual/src/docs/tutorials/howto-configure-service.txt b/manual/src/docs/tutorials/howto-configure-service.txt
index e019d25..8776e79 100644
--- a/manual/src/docs/tutorials/howto-configure-service.txt
+++ b/manual/src/docs/tutorials/howto-configure-service.txt
@@ -15,10 +15,10 @@
[[howto-configure-service,Configure a Service]]
= Configure a Service =
-Zest� supports a Configuration system for services. The configuration instance itself is an Entity and is therefor
+Zest™ supports a Configuration system for services. The configuration instance itself is an Entity and is therefor
readable, writeable and queryable, just like other Entities. This should make Configuration management much simpler,
since you can easily build GUI tools to allow editing of these in runtime. However, to simplify the initial values of
-the Configuration instance, Zest� also does the initial bootstrapping of the Configuration entity for you. This HowTo is
+the Configuration instance, Zest™ also does the initial bootstrapping of the Configuration entity for you. This HowTo is
going to show how.
If you want to reproduce what's explained in this tutorial, remember to depend on the Core Bootstrap artifact:
@@ -139,7 +139,7 @@ tag=params
File: org/qi4j/manual/travel/OrbitzService.properties
== Changing Configuration in runtime ==
-Unlike most frameworks, the Configuration in Zest� is an active Entity, and once the properties file has been read once
+Unlike most frameworks, the Configuration in Zest™ is an active Entity, and once the properties file has been read once
at the first(!) startup, it no longer serves any purpose. The Configuration will always be retrieved from the
EntityStore. Changes to the properties file are not taken into consideration if the Configuration entity is found in the
entity store.
http://git-wip-us.apache.org/repos/asf/zest-qi4j/blob/88b203bb/manual/src/docs/tutorials/howto-create-concern.txt
----------------------------------------------------------------------
diff --git a/manual/src/docs/tutorials/howto-create-concern.txt b/manual/src/docs/tutorials/howto-create-concern.txt
index 4438b4e..64cfde8 100644
--- a/manual/src/docs/tutorials/howto-create-concern.txt
+++ b/manual/src/docs/tutorials/howto-create-concern.txt
@@ -41,8 +41,8 @@ tag=allClass
Note that we could have implemented the InventoryConcern as an abstract class if we were not interested in __all__ the methods in the Order interface.
Extending the ConcernOf is a convenience mechanism, instead of an explicit @ConcernFor annotation on
a private field, which can be used in rare occasions when you are not able to extend. This base class defines the next
-field, which is set up by the Zest� runtime and points to the next fragment in the call stack. We can also see that the
-InventoryService is provided to the concern, which is done with dependency injection. Zest� also supports dependency
+field, which is set up by the Zest™ runtime and points to the next fragment in the call stack. We can also see that the
+InventoryService is provided to the concern, which is done with dependency injection. Zest™ also supports dependency
injection via constructors and methods.
It can be used as follows;
http://git-wip-us.apache.org/repos/asf/zest-qi4j/blob/88b203bb/manual/src/docs/tutorials/howto-create-entity.txt
----------------------------------------------------------------------
diff --git a/manual/src/docs/tutorials/howto-create-entity.txt b/manual/src/docs/tutorials/howto-create-entity.txt
index ec16fe4..70e3148 100644
--- a/manual/src/docs/tutorials/howto-create-entity.txt
+++ b/manual/src/docs/tutorials/howto-create-entity.txt
@@ -15,9 +15,9 @@
[[howto-create-entity,Create an Entity]]
= Create an Entity =
-One of the most common tasks in Zest� is the management of the life cycle of Entities. Since Zest� is capable of
+One of the most common tasks in Zest™ is the management of the life cycle of Entities. Since Zest™ is capable of
delivering much higher performance than traditional Object-Relational Mapping technologies, we also expect that people
-use Entities more frequently in Zest� applications, so it is a very important topic to cover.
+use Entities more frequently in Zest™ applications, so it is a very important topic to cover.
If you want to reproduce what's explained in this tutorial, remember to depend on the Core Bootstrap artifact:
@@ -39,7 +39,7 @@ Domain code typically don't need to know of the EntityComposite types directly,
interface. The Visibility rules will be applied to associate the right EntityComposite when a domain type is requested.
Ambiguities are not accepted and will result in runtime exceptions.
-Zest� supports that each entity instance can have more than one entity type, and it is managed per instance. This feature
+Zest™ supports that each entity instance can have more than one entity type, and it is managed per instance. This feature
is beyond the scope of this HowTO and will be covered subsequently.
== Good Practice ==
@@ -125,7 +125,7 @@ available as services.
== The Entity Factory ==
-The entity factory is something you need to write yourself, but as with most things in Zest� it will end up being a
+The entity factory is something you need to write yourself, but as with most things in Zest™ it will end up being a
fairly small implementation. So how is that done?
[snippet,java]
@@ -134,7 +134,7 @@ source=manual/src/main/java/org/qi4j/manual/recipes/createEntity/CarEntityFactor
tag=carFactory
-----------
-That is just the domain interface. We now need to make the service interface, which Zest� needs to identify services and
+That is just the domain interface. We now need to make the service interface, which Zest™ needs to identify services and
make it possible for the service injection later.
[snippet,java]
@@ -151,7 +151,7 @@ source=manual/src/main/java/org/qi4j/manual/recipes/createEntity/CarEntityFactor
tag=carFactoryMixin1
-----------
-And doing that, first of all we need to request Zest� runtime to give us the Module
+And doing that, first of all we need to request Zest™ runtime to give us the Module
that our code belongs to, and the UnitOfWork current context the execution is happening in.
Injections that are related to the Visibility rules are handled by the @Structure annotation. And the easiest way for us
@@ -163,7 +163,7 @@ source=manual/src/main/java/org/qi4j/manual/recipes/createEntity/CarEntityFactor
tag=carFactoryMixin2
-----------
-Here Zest� will inject the member module with the correct Module. In case we only need the Module
+Here Zest™ will inject the member module with the correct Module. In case we only need the Module
during the construction, we can also request it in the same manner as constructor argument.
[snippet,java]
http://git-wip-us.apache.org/repos/asf/zest-qi4j/blob/88b203bb/manual/src/docs/tutorials/howto-create-sideeffect.txt
----------------------------------------------------------------------
diff --git a/manual/src/docs/tutorials/howto-create-sideeffect.txt b/manual/src/docs/tutorials/howto-create-sideeffect.txt
index 5084a79..6e3b6f0 100644
--- a/manual/src/docs/tutorials/howto-create-sideeffect.txt
+++ b/manual/src/docs/tutorials/howto-create-sideeffect.txt
@@ -41,9 +41,9 @@ tag=allClass
The MailNotifySideEffect is implemented as an abstract class, since we are not interested in the many other methods in
the Confirmable interface. Extending the SideEffectOf is a convenience mechanism, instead of an explicit @SideEffectFor
annotation on a private field, which can be used in rare occasions when you are not able to extend. This base class
-defines the next field, which is set up by the Zest� runtime and points to the next fragment in the call stack. We can
+defines the next field, which is set up by the Zest™ runtime and points to the next fragment in the call stack. We can
also see that the MailService, HasLineItems and HasCustomer are provided to the side-effect, which is done with
-dependency injection. Zest� also supports dependency injection via constructors and methods.
+dependency injection. Zest™ also supports dependency injection via constructors and methods.
It can be used as follows;
http://git-wip-us.apache.org/repos/asf/zest-qi4j/blob/88b203bb/manual/src/docs/tutorials/howto-leverage-properties.txt
----------------------------------------------------------------------
diff --git a/manual/src/docs/tutorials/howto-leverage-properties.txt b/manual/src/docs/tutorials/howto-leverage-properties.txt
index 8637662..8cc1c7b 100644
--- a/manual/src/docs/tutorials/howto-leverage-properties.txt
+++ b/manual/src/docs/tutorials/howto-leverage-properties.txt
@@ -16,7 +16,7 @@
[[howto-leverage-properties,Leverage Properties]]
= Leverage Properties =
-Zest� does not follow the JavaBeans standard for property support. Instead, a much more explicit concept is in place. The
+Zest™ does not follow the JavaBeans standard for property support. Instead, a much more explicit concept is in place. The
advantages are enormous, and the only real downside is that people are already destroyed, thinking in so called POJO
terms.
http://git-wip-us.apache.org/repos/asf/zest-qi4j/blob/88b203bb/manual/src/docs/tutorials/howto-writing-docs.txt
----------------------------------------------------------------------
diff --git a/manual/src/docs/tutorials/howto-writing-docs.txt b/manual/src/docs/tutorials/howto-writing-docs.txt
index 5e7995b..14ed48c 100644
--- a/manual/src/docs/tutorials/howto-writing-docs.txt
+++ b/manual/src/docs/tutorials/howto-writing-docs.txt
@@ -18,7 +18,7 @@
///////////////////////////////////////////////////////////////
[[community-docs,Writing Documentation]]
-= Writing Zest� Documentation =
+= Writing Zest™ Documentation =
The documents use the asciidoc format, see:
http://git-wip-us.apache.org/repos/asf/zest-qi4j/blob/88b203bb/manual/src/docs/userguide/extensions.txt
----------------------------------------------------------------------
diff --git a/manual/src/docs/userguide/extensions.txt b/manual/src/docs/userguide/extensions.txt
index 107f418..7866ff5 100644
--- a/manual/src/docs/userguide/extensions.txt
+++ b/manual/src/docs/userguide/extensions.txt
@@ -24,7 +24,7 @@
== Overview ==
-We try to keep the Zest� Core Runtime as lean as possible, and a lot of the power to the Zest� Platform comes via its
+We try to keep the Zest™ Core Runtime as lean as possible, and a lot of the power to the Zest™ Platform comes via its
Extension SPI, which defines clear ways to extend the platform. There are currently the following Extensions types,
each with possibly more than one implementation;
@@ -37,7 +37,7 @@ each with possibly more than one implementation;
* Migration
This section will go through each of the available extensions.
-The Zest� Extensions are of varying maturity level and we try to maintain a STATUS (dev-status.xml) file indicating
+The Zest™ Extensions are of varying maturity level and we try to maintain a STATUS (dev-status.xml) file indicating
how good the codebase, documentation and unit tests are for each of the libraries. This is highly subjective and
potentially different individuals will judge this differently, but at least it gives a ballpark idea of the situation
for our users.
http://git-wip-us.apache.org/repos/asf/zest-qi4j/blob/88b203bb/manual/src/docs/userguide/faq.txt
----------------------------------------------------------------------
diff --git a/manual/src/docs/userguide/faq.txt b/manual/src/docs/userguide/faq.txt
index 7aba95f..bd93829 100644
--- a/manual/src/docs/userguide/faq.txt
+++ b/manual/src/docs/userguide/faq.txt
@@ -21,6 +21,6 @@
= Frequently Asked Questions =
Is it possible to use Scala with Zest?::
- Short Answer: Yes. Scala traits can be used as Zest� fragments, and Zest� composites can be used in Scala.
+ Short Answer: Yes. Scala traits can be used as Zest™ fragments, and Zest™ composites can be used in Scala.
http://git-wip-us.apache.org/repos/asf/zest-qi4j/blob/88b203bb/manual/src/docs/userguide/glossary.txt
----------------------------------------------------------------------
diff --git a/manual/src/docs/userguide/glossary.txt b/manual/src/docs/userguide/glossary.txt
index 401b00b..38a1205 100644
--- a/manual/src/docs/userguide/glossary.txt
+++ b/manual/src/docs/userguide/glossary.txt
@@ -24,7 +24,7 @@
== Glossary ==
-There are a lot of concepts in Zest� which may have different meanings in other contexts. So in true DDD-style
+There are a lot of concepts in Zest™ which may have different meanings in other contexts. So in true DDD-style
ubiquitous language, we are here listing the definitions of the terms and concepts that are being used.
[glossary]
@@ -34,7 +34,7 @@ ubiquitous language, we are here listing the definitions of the terms and concep
An Abstract Mixin is an implementation of the <<def-mixin-type>> interface, but is an abstract class and has not
implemented all the methods.
-The Zest� runtime can use multiple <<def-mixin,Mixins>> for each <<def-mixin-type>> interface. It is also possible to let
+The Zest™ runtime can use multiple <<def-mixin,Mixins>> for each <<def-mixin-type>> interface. It is also possible to let
a <<def-generic-mixin>> handle the remaining missing methods.
--
@@ -53,10 +53,10 @@ will not be part of the <<def-invocation-stack>> of those methods.
[[def-application,Application]]Application::
+
--
-Application is the top level concept handled by the Zest� runtime instance. It holds the information about the
+Application is the top level concept handled by the Zest™ runtime instance. It holds the information about the
<<def-layer,Layers>> in the application architecture. See <<def-structure>> for more information.
-There is one and only one Application instance per Zest� Runtime instance.
+There is one and only one Application instance per Zest™ Runtime instance.
--
@@ -120,7 +120,7 @@ CompositeType is the Java interface that declares the composition, from which <<
created.
Composite Type interfaces must be a sub-type of one of the 5 <<def-composite-metatype,Composite Meta Types>> defined in
-Zest� otherwise it can not be instantiated.
+Zest™ otherwise it can not be instantiated.
--
@@ -162,7 +162,7 @@ See <<howto-configure-service>> to learn how to use Configuration Composites.
[[def-constraint,Constraint]]Constraint::
+
--
-Constraints are a kind of validators, which are consulted prior to invoking the method call. Zest� currently only
+Constraints are a kind of validators, which are consulted prior to invoking the method call. Zest™ currently only
supports ParameterConstraints on methods and value constraints on <<def-property,Properties>>, but future versions will
include Constraint types for checking complete method calls and return values.
@@ -235,11 +235,11 @@ For each method, Qi4J will create and re-use an Invocation Stack. It will be bui
<<def-modifier,Modifiers>> and an end-point that will link into the stateful <<def-mixin>>.
It is important to recognize that, for memory footprint reasons, Invocation Stacks are shared across
-<<def-composite,Composites>> of the same <<def-composite-type>>. They are however thread-safe, in that Zest� will never
+<<def-composite,Composites>> of the same <<def-composite-type>>. They are however thread-safe, in that Zest™ will never
bind the same Invocation Stack to more than one <<def-composite>> instance during a method call, but that between method
invocations the <<def-modifier,Modifiers>> in the Invocation Stack can not assume that it is bound to the same
<<def-composite>> instance. Therefor, <<def-modifier,Modifiers>> are not expected to keep state between method
-invocations, and when it needs to do that, then it should reference a <<def-mixin>> via the @This annotation. Zest� will
+invocations, and when it needs to do that, then it should reference a <<def-mixin>> via the @This annotation. Zest™ will
during the binding of the Invocation Stack to the <<def-composite>>, also ensure that all referenced
<<def-mixin,Mixins>> are correctly injected in the Invocation Stack.
--
@@ -248,7 +248,7 @@ during the binding of the Invocation Stack to the <<def-composite>>, also ensure
[[def-layer,Layer]]Layer::
+
--
-Zest� promotes a Layered application design, where Layers can only access lower Layers and not higher Layers or Layers at
+Zest™ promotes a Layered application design, where Layers can only access lower Layers and not higher Layers or Layers at
the same level.
--
@@ -377,17 +377,17 @@ SideEffect is one of the 3 kinds of <<def-modifier,Modifiers>> defined in Zest.
[[def-structure,Structure]]Structure::
+
--
-Zest� promotes a conventional view of application structure, that computer science has been using for decades.
+Zest™ promotes a conventional view of application structure, that computer science has been using for decades.
The definition is as follows;
-* One <<def-application>> per Zest� runtime instance.
+* One <<def-application>> per Zest™ runtime instance.
* One or more <<def-layer,Layers>> per <<def-application>>.
* Zero, one or more <<def-module,Modules>> per <<def-layer>>.
* Zero, one or more Assemblies per <<def-module>>.
The principle of this Structure is to assist the programmer to create well modularized applications, that are easily
-extended and maintained. Zest� will restrict access between <<def-module,Modules>>, so that code can only reach
+extended and maintained. Zest™ will restrict access between <<def-module,Modules>>, so that code can only reach
<<def-composite,Composites>> and Objects in <<def-module,Modules>> (including itself) of the same or lower
<<def-layer,Layers>>.
@@ -424,7 +424,7 @@ immutable and can be compared by value instead of memory reference. Concurrency
the value exists or it doesn't, no need for synchronization. Values are typically very easy to test and very robust to
refactoring.
-Zest� defines values as a primary meta type through the ValueComposite, as we think the benefits of values are great.
+Zest™ defines values as a primary meta type through the ValueComposite, as we think the benefits of values are great.
The ValueComposite is very light-weight compared to the <<def-entitycomposite>>, and its value can still be persisted as
part of an <<def-entitycomposite>> via a <<def-property>>.
http://git-wip-us.apache.org/repos/asf/zest-qi4j/blob/88b203bb/manual/src/docs/userguide/index.txt
----------------------------------------------------------------------
diff --git a/manual/src/docs/userguide/index.txt b/manual/src/docs/userguide/index.txt
index e65328d..683dee0 100644
--- a/manual/src/docs/userguide/index.txt
+++ b/manual/src/docs/userguide/index.txt
@@ -17,7 +17,7 @@
* under the License.
///////////////////////////////////////////////////////////////
-= Zest� v{revnumber} User Guide =
+= Zest™ v{revnumber} User Guide =
:qi4j-version: {revnumber}
:qi4j-buildnumber: {revnumber}
http://git-wip-us.apache.org/repos/asf/zest-qi4j/blob/88b203bb/manual/src/docs/userguide/libraries.txt
----------------------------------------------------------------------
diff --git a/manual/src/docs/userguide/libraries.txt b/manual/src/docs/userguide/libraries.txt
index c6f26b8..284154d 100644
--- a/manual/src/docs/userguide/libraries.txt
+++ b/manual/src/docs/userguide/libraries.txt
@@ -24,7 +24,7 @@
== Overview ==
-The Zest� Libraries are of varying maturity level and we try to maintain a STATUS (dev-status.xml) file indicating
+The Zest™ Libraries are of varying maturity level and we try to maintain a STATUS (dev-status.xml) file indicating
how good the codebase, documentation and unit tests are for each of the libraries. This is highly subjective and
potentially different individuals will judge this differently, but at least it gives a ballpark idea of the situation
for our users.