You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@ace.apache.org by ja...@apache.org on 2014/11/25 08:43:17 UTC

svn commit: r1641536 - in /ace/site/trunk/content: docs.mdtext docs/ace-roles.mdtext docs/history-and-background.mdtext docs/user-guide.mdtext

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).