Author: jawi
Date: Tue Nov 25 07:43:17 2014
New Revision: 1641536
URL: http://svn.apache.org/r1641536
Log:
Some textual updates & pointers added.
Modified:
ace/site/trunk/content/docs.mdtext
ace/site/trunk/content/docs/ace-roles.mdtext
ace/site/trunk/content/docs/history-and-background.mdtext
ace/site/trunk/content/docs/user-guide.mdtext
Modified: ace/site/trunk/content/docs.mdtext
URL:
http://svn.apache.org/viewvc/ace/site/trunk/content/docs.mdtext?rev=1641536&r1=1641535&r2=1641536&view=diff
==============================================================================
--- ace/site/trunk/content/docs.mdtext (original)
+++ ace/site/trunk/content/docs.mdtext Tue Nov 25 07:43:17 2014
@@ -6,7 +6,8 @@ terminology, allowing precise control ov
features are:
* being able to deploy software to many different targets;
-* atomic upgrades: if an upgrade fails for a target, it is automatically
rolled back to the former state;
+* atomic upgrades: if an upgrade fails for a target, it is automatically
rolled back to
+ the former state;
* deploy different configurations for different targets;
* smart redeployments of only the changed artifacts to your targets;
* complete control on the deployment strategy for your targets.
@@ -25,29 +26,42 @@ background](/docs/history-and-background
Resources that go into more detail on using Apache ACE:
* read all about using Apache ACE in the [users guide](/docs/user-guide.html);
-* to manage users using ACE's web UI, read the [user management
guide](/docs/user-management-guide.html);
+* to manage users using ACE's web UI, read the [user management
+ guide](/docs/user-management-guide.html);
* [information about the various roles used in Apache
ACE](/docs/ace-roles.html);
* accessing Apache ACE [using the Gogo shell](/docs/shell-api.html);
* accessing Apache ACE from [its REST API](/docs/rest-api.html);
-* to handle a large number of targets, you can make use of [intermediate relay
servers](/docs/configuring-relay-servers.html);
-* configuring ACE authentication is described in the [authentication
guide](/docs/ace-authentication.html);
-* configuring ACE to use two-way SSL is described in [using client
certificates](/docs/using-client-certificates.html);
-* various deployment strategies for Apache ACE are described in the [ACE
deployment strategies document](/docs/ace-deployment-strategies.html);
+* to handle a large number of targets, you can make use of [intermediate relay
+ servers](/docs/configuring-relay-servers.html);
+* configuring ACE authentication is described in the [authentication
+ guide](/docs/ace-authentication.html);
+* configuring ACE to use two-way SSL is described in [using client
+ certificates](/docs/using-client-certificates.html);
+* various deployment strategies for Apache ACE are described in the [ACE
deployment
+ strategies document](/docs/ace-deployment-strategies.html);
## Developing for Apache ACE
There are several resources available on extending and developing for Apache
ACE, such as:
-* [setting up an development environment for developing for Apache
ACE](/docs/setup-dev-environment.html);
-* more details on writing unit and/or integration tests can be found in [this
document](/docs/writing-tests.html);
-* all about the coding style and guidelines can be found in the [coding
standards](/docs/coding-standards.html);
-* guidelines for releasing Apache ACE can be found in [the release
guide](/docs/release-guide.html);
-* more information about the architectural principals can be found in [the
architectural guide](/docs/architecture.html);
-* if you are interested in performing load tests, or want to get started with
automating ACE deployments, read all about it in our [test script
document](/docs/test-script.html);
+* [setting up an development environment for developing for Apache
+ ACE](/docs/setup-dev-environment.html);
+* more details on writing unit and/or integration tests can be found in [this
+ document](/docs/writing-tests.html);
+* all about the coding style and guidelines can be found in the [coding
+ standards](/docs/coding-standards.html);
+* guidelines for releasing Apache ACE can be found in [the release
+ guide](/docs/release-guide.html);
+* more information about the architectural principals can be found in [the
architectural
+ guide](/docs/architecture.html);
+* if you are interested in performing load tests, or want to get started with
automating
+ ACE deployments, read all about it in our [test script
+ document](/docs/test-script.html);
* various use cases are described on the [use cases page](/docs/use-cases);
* [adding support for new types of
artifacts](/docs/adding-custom-artifact-types.html);
-* detailed analysis documentation giving background information on some
development principles currently used:
+* detailed analysis documentation giving background information on some
development
+ principles currently used:
* [audit log analysis](/docs/analysis/auditlog-analysis.html);
* [bundle repository
analysis](/docs/analysis/bundlerepository-analysis.html);
* [security analysis](/docs/analysis/security-analysis.html);
Modified: ace/site/trunk/content/docs/ace-roles.mdtext
URL:
http://svn.apache.org/viewvc/ace/site/trunk/content/docs/ace-roles.mdtext?rev=1641536&r1=1641535&r2=1641536&view=diff
==============================================================================
--- ace/site/trunk/content/docs/ace-roles.mdtext (original)
+++ ace/site/trunk/content/docs/ace-roles.mdtext Tue Nov 25 07:43:17 2014
@@ -1,18 +1,23 @@
Title: Roles
-These are the different roles in the system. Users of the system can be
assigned one or more roles. The roles are also used in the different [use
cases](use-cases/).
+These are the different roles in the system. Users of the system can be
assigned one or
+more roles. The roles are also used in the different [use
cases](/docs/use-cases/).
## Release Manager
-The release manager manages the software configuration, linking artifacts to
features and features to distributions.
+The release manager manages the software configuration, linking artifacts to
features and
+features to distributions.
## Target Manager
-The target manager manages the total population of targets and assigns them to
target operators.
+The target manager manages the total population of targets and assigns them to
target
+operators.
## Target Operator
-The target operator manages a (limited) set of targets designated to him by
the target manager. He is responsible for accepting changes to the software
configuration for those targets.
+The target operator manages a (limited) set of targets designated to him by
the target
+manager. He is responsible for accepting changes to the software configuration
for those
+targets.
## Remote Target Operator
@@ -24,7 +29,8 @@ The license manager manages the relation
## Administrator
-The administrator manages the users, system settings, rights and security
certificates for the whole ecosystem.
+The administrator manages the users, system settings, rights and security
certificates for
+the whole ecosystem.
## Target
@@ -32,12 +38,15 @@ A target runs the management agent that
## Server
-The server manages all the metadata that expresses what artifacts should be
installed on what targets over time. It also contains an OBR for managing the
actual artifacts.
+The server manages all the metadata that expresses what artifacts should be
installed on
+what targets over time. It also contains an OBR for managing the actual
artifacts.
## Relay server
-The relay server acts as a cache for the server. It synchronizes with the
server and might only contain a subset of the metadata to service a subset of
the targets.
+The relay server acts as a cache for the server. It synchronizes with the
server and might
+only contain a subset of the metadata to service a subset of the targets.
## Software Developer
The software developer provides artifacts that will be added to the OBR.
+
Modified: ace/site/trunk/content/docs/history-and-background.mdtext
URL:
http://svn.apache.org/viewvc/ace/site/trunk/content/docs/history-and-background.mdtext?rev=1641536&r1=1641535&r2=1641536&view=diff
==============================================================================
--- ace/site/trunk/content/docs/history-and-background.mdtext (original)
+++ ace/site/trunk/content/docs/history-and-background.mdtext Tue Nov 25
07:43:17 2014
@@ -1,4 +1,4 @@
-Title: Introduction
+Title: History and background
Since its birth in 1999, OSGi has steadily been gaining popularity as the
component model
of choice for Java. Originally designed as a framework for home gateways and
other
@@ -24,12 +24,12 @@ Apache ACE is a software distribution fr
and consists of three major subsystems:
1. dependency management, which handles the complexity of managing the
dependencies
-between component, aggregating them into features and distributions and
associating those
-to targets;
+ between component, aggregating them into features and distributions and
associating
+ those to targets;
2. deployment management, which ensures that the right components get
installed onto the
-right targets in a robust and scalable way;
+ right targets in a robust and scalable way;
3. feedback management, which collects life cycle feedback on the target and
aggregates
-that on a central server.
+ that on a central server.
A typical topology consists of:
@@ -40,5 +40,8 @@ A typical topology consists of:
The Apache ACE software, which consists of a set of OSGi bundles, gets
deployed on a
server. A target can be any OSGi framework (Apache Felix, Equinox or
Knopflerfish) with
the Apache ACE management agent installed. This agent will connect to the
server, identify
-itself and poll for updates.
+itself and poll for updates. If an update is found, the agent will download
and install it
+using the Deployment Admin specifiction, allowing for rollbacks to the
previous installed
+version in case the installation fails.
+
Modified: ace/site/trunk/content/docs/user-guide.mdtext
URL:
http://svn.apache.org/viewvc/ace/site/trunk/content/docs/user-guide.mdtext?rev=1641536&r1=1641535&r2=1641536&view=diff
==============================================================================
--- ace/site/trunk/content/docs/user-guide.mdtext (original)
+++ ace/site/trunk/content/docs/user-guide.mdtext Tue Nov 25 07:43:17 2014
@@ -29,13 +29,12 @@ repository, like the Maven repository or
versions of artifacts[^1]. You can use either the default OBR supplied by ACE
or an
external one, such as [Sonatype's
Nexus](http://books.sonatype.com/nexus-book/reference/osgi-sect-hosted.html)
for storing
-your artifacts.
-As the OBR is the *single source* for all artifacts, and therefore the
software that is
-deployed on a target, ACE is able to calculate how to upgrade a target from
one version to
-another version. This is possible because *all* changes made to (the metadata
of) ACE are
-stored in an internal versioned database. In other words, ACE always keeps a
full history
-and audit trail for all changes, making it possible to go back and forth
between versions
-deployed on each target.
+your artifacts. As the OBR is the *single source* for all artifacts, and
therefore the
+software that is deployed on a target, ACE is able to calculate how to upgrade
a target
+from one version to another version. This is possible because *all* changes
made to (the
+metadata of) ACE are stored in an internal versioned database. In other words,
ACE always
+keeps a full history and audit trail for all changes, making it possible to go
back and
+forth between versions deployed on each target.
## Use cases and workflow
@@ -81,11 +80,11 @@ After that, he can repurpose it again. A
dedicated targets for the purpose of acceptance testing.
When all acceptance tests are successful, the new version of your software
needs to be
-deployed on several production environments, which is done by you, the release
manager. As
-most production environments only differ in a few details, such as IP
addresses and maybe
-the database credentials, you use the template engine of ACE to make specific
-configuration files for each production target. This way, you can easily scale
up your
-production environment by defining new targets and provide them with the
necessary
+deployed on several production environments, which is done by you, the release
+manager[^2]. As most production environments only differ in a few details,
such as IP
+addresses and maybe the database credentials, you use the template engine of
ACE to make
+specific configuration files for each production target. This way, you can
easily scale up
+your production environment by defining new targets and provide them with the
necessary
configuration values.
### Workflow
@@ -94,29 +93,29 @@ Apache ACE can be used in many different
new users to comprehend to use ACE to its full extent. By default, that is,
without any
configuration, the workflow of ACE is as follows (see also figure 1):
-1. a "release manager" (either you, or somebody designated to that role),
ensures that the
-targets are defined. This is where the software is deployed and running. You
can predefine
-each target using the ACE web UI, or start each target (and configure them
properly to
-contact your ACE server) and make them appear automatically in your workspace
(you might
-need to refresh your workspace before targets appear in the web UI);
+1. a release manager[^2], ensures that the targets are defined. This is where
the software
+ is deployed and running. You can predefine each target using the ACE web
UI, or start
+ each target (and configure them properly to contact your ACE server) and
make them
+ appear automatically in your workspace (you might need to refresh your
workspace before
+ targets appear in the web UI);
2. the release manager defines the features and distributions that need to be
deployed. In
-the simplest case, you can define only one feature and distribution, but go
also define
-much more fine-grained features and distributions if needed. The easiest way
to define
-features and distributions and to link them to each other is by using the ACE
web UI. This
-allows you to simply use the "add" buttons and drag-and-drop to achieve this;
+ the simplest case, you can define only one feature and distribution, but go
also define
+ much more fine-grained features and distributions if needed. The easiest
way to define
+ features and distributions and to link them to each other is by using the
ACE web UI.
+ This allows you to simply use the "add" buttons and drag-and-drop to
achieve this;
3. the artifacts are added to your OBR. This can be done by uploading them
through on of
-the ACE clients, for example, the web UI. Once uploaded, the artifacts need to
be linked
-to features in order to be deployed to targets. Again, the ACE web UI makes
this easy by
-simply using drag-and-drop to link artifacts to features;
+ the ACE clients, for example, the web UI. Once uploaded, the artifacts need
to be
+ linked to features in order to be deployed to targets. Again, the ACE web
UI makes this
+ easy by simply using drag-and-drop to link artifacts to features;
4. the next time the target contacts the ACE server, it will retrieve the
configured
-distribution(s);
+ distribution(s);
5. If you linked artifacts to features using the ACE web UI, it will create
"wildcard"
-assocations, meaning that it will automatically use the latest version
available for each
-artifact. This means that if you update *existing* artifacts in the OBR, ACE
will
-automatically deploy them to all affected targets. If you add new artifacts,
you need to
-link them to existing or new features and distributions to deploy them.
+ assocations, meaning that it will automatically use the latest version
available for
+ each artifact. This means that if you update *existing* artifacts in the
OBR, ACE will
+ automatically deploy them to all affected targets. If you add new
artifacts, you need
+ to link them to existing or new features and distributions to deploy them.
-<a href="simple-workflow.png" target="_blank"><img src="simple-workflow.png"
height="250px" title="Figure 1: Typical ACE workflow." /></a>
+<a href="simple-workflow.png" target="_blank"><img src="simple-workflow.png"
width="149" height="250" title="Figure 1: Typical ACE workflow." /></a>
**Figure 1**: A graphical overview of a typical workflow of ACE (click on
image to see full size).
<!-- TODO: describe how you can extend/customize the workflow -->
@@ -132,12 +131,12 @@ familiar with it, you'll see that it is
After logging in, the main window consists of two main areas:
1. The control area at the top of the screen, where you can perform actions
like
-retrieving the latest repository changes, revert the changes you've made
locally, add new
-artifacts, and so on;
+ retrieving the latest repository changes, revert the changes you've made
locally, add
+ new artifacts, and so on;
2. The resource area, consisting of (up to) four columns showing the current
artifacts,
-features, distributions and targets that are known to ACE. When you select an
entity here,
-the associated entities in other columns will automatically be highlighted,
giving you an
-instant overview of the links within the system.
+ features, distributions and targets that are known to ACE. When you select
an entity
+ here, the associated entities in other columns will automatically be
highlighted,
+ giving you an instant overview of the links within the system.
Apache ACE allows for concurrent use at every aspect. Many targets can request
different
versions of software that need to be served, while at the same time one or
more users are
@@ -173,9 +172,9 @@ the list of selected artifacts) and a li
allows you to upload artifacts, and offers two options to do so:
1. by uploading the individual artifacts by pressing the "Upload" button and
selecting the
-artifact from the file chooser dialog, or;
+ artifact from the file chooser dialog, or;
2. by using drag-and-drop: select all artifacts in an Explorer or Finder and
drag them
-onto the "Upload artifact" area. This way, you can upload multiple artifacts
in one go.
+ onto the "Upload artifact" area. This way, you can upload multiple
artifacts in one go.
If you try to upload an artifact that is not recognized by ACE, a failure
notification is
displayed noting that that particular artifact is not uploaded (see figure 5).
Adding
@@ -216,10 +215,10 @@ name of the feature or distribution and
To define a new target in the ACE web UI, you can do either:
1. pre-register a target by clicking the "+" button above the targets column
and entering
-the name of the new target. This allows you to associate software to this
target before it
-has ever been started or seen by the server; or,
+ the name of the new target. This allows you to associate software to this
target before
+ it has ever been started or seen by the server; or,
2. you can register a target that is already running and has already tried to
fetch
-software from the ACE server. The details on this will be discussed later on.
+ software from the ACE server. The details on this will be discussed later
on.
After a feature, distribution or target is created, you can edit its
properties by double
clicking it. For features and distributions, this means you can alter their
description,
@@ -268,7 +267,7 @@ associated to the feature.
Creating dynamic associations is currently only supported for bundle
artifacts. For other
types of artifacts, such as configuration files, only static associations can
be
-created[^2].
+created[^4].
### Configuring the server
@@ -305,10 +304,10 @@ available in the ACE source repository a
The management agent, or agent for short, does the following:
1. it uploads the audit log of the target to the ACE server. The audit log
contains all
-changes in bundle and framework state, such as the starting and stopping of
the framework
-and (de)installation of bundles;
+ changes in bundle and framework state, such as the starting and stopping of
the
+ framework and (de)installation of bundles;
2. it check whether or not software updates are available. If so, it will
download it and
-install this update automatically.
+ install this update automatically.
To run a target, you need to issue the following command:
@@ -324,7 +323,7 @@ To run a target, you need to issue the f
### Target configuration
The agent can be configured by supplying its options as commandline parameters
(e.g.
-<tt>-Dname=value</tt>). A list of most used options are[^7]:
+<tt>-Dname=value</tt>). A list of most used options are[^8]:
<tt>agent.identification.agentid</tt>
: defines the name to uniquely identify a target on the ACE server. In case
this option is
@@ -419,7 +418,7 @@ you have lots of targets. Besides that,
so you need to create unique file names for your configuration files for each
change you
make. Fortunately, ACE provides an easier way to solve this problem: a
template engine.
-All configuration files[^4] can be regarded as templates, in which variables
are replaced
+All configuration files[^5] can be regarded as templates, in which variables
are replaced
with values supplied by ACE. In fact, the values are definable per target,
distribution,
feature or artifact and ACE will collect all tags of entities that are
associated with a
specific target. To define variables and their replacement values (or "tags")
for, for
@@ -451,7 +450,7 @@ be replaced. The <tt>context.</tt> (incl
after this prefix is user-definable and considered as variable name. In this
example, two
variables are expected: <tt>address</tt> and <tt>port</tt>. The values for
these variables
can be added to entities by using the "Tag Editor", available when you double
click on an
-artifact, feature, distribution or target in the web UI[^5]. It does not
really matter on
+artifact, feature, distribution or target in the web UI[^6]. It does not
really matter on
what entity the variables are actually defined, but in most cases they are
either defined
on a distribution and/or target.
@@ -472,7 +471,7 @@ And similar tags on "target-2":
<img src="ace_target_tag_editor.png" width="600px" title="Figure 8: Using the
Tag Editor of a target to supply configuration variables." />
**Figure 8**: Using the Tag Editor of a target to supply configuration
variables.
-Under the covers, ACE uses Velocity[^6] to parse the template. This means
that, apart from
+Under the covers, ACE uses Velocity[^7] to parse the template. This means
that, apart from
variable substitution, you can also use other Velocity macros and create more
complex
configurations that might contain conditional sections, loops and other
features Velocity
provides. See the Velocity documentation for more information on how to use
this
@@ -495,21 +494,24 @@ everything you do is reproducible. One t
the way that Maven handles snapshot versions. A snapshot can contain anything.
In stead we
usually use the version qualifier to append a timestamp in such scenarios.
-[^2]: This is a limitation of the current web UI. It is possible to create more
+[^2]: To read more about the various roles used in Apache ACE, see [this
+page](/docs/ace-roles.html);
+
+[^3]: This is a limitation of the current web UI. It is possible to create more
sophisticated associations by using the REST API or the Gogo shell commands.
-[^3]: Do not forget to store your changes!
+[^4]: Do not forget to store your changes!
-[^4]: In fact any artifact can be considered as an template, but by default
ACE only
+[^5]: In fact any artifact can be considered as an template, but by default
ACE only
considers configuration files.
-[^5]: In other UIs, such as the Gogo shell, you need to supply these tags
manually.
+[^6]: In other UIs, such as the Gogo shell, you need to supply these tags
manually.
-[^6]: Apache Velocity is an engine that can generate documents by combining a
template
+[^7]: Apache Velocity is an engine that can generate documents by combining a
template
with a context that contains variables. To learn more about it, visit the
[Velocity
website](http://velocity.apache.org/).
-[^7]: A complete list of recognised options can be found in
+[^8]: A complete list of recognised options can be found in
[<tt>org.apache.ace.agent.AgentConstants</tt>](https://svn.apache.org/repos/asf/ace/trunk/org.apache.ace.agent/src/org/apache/ace/agent/AgentConstants.java).
