; Mon, 24 Nov 2014 22:42:17 +0000 (UTC) Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Subject: svn commit: r930358 [6/10] - in /websites/staging/ace/trunk/content: ./ dev-doc/ docs/ docs/analysis/ docs/analysis/src/ docs/design/ docs/design/src/ docs/use-cases/ user-doc/ Date: Mon, 24 Nov 2014 22:42:14 -0000 To: commits@ace.apache.org From: buildbot@apache.org X-Mailer: svnmailer-1.0.9 Message-Id: <20141124224217.6E3CA2388C27@eris.apache.org> X-Virus-Checked: Checked by ClamAV on apache.org Added: websites/staging/ace/trunk/content/docs/setup-dev-environment.html ============================================================================== --- websites/staging/ace/trunk/content/docs/setup-dev-environment.html (added) +++ websites/staging/ace/trunk/content/docs/setup-dev-environment.html Mon Nov 24 22:42:13 2014 @@ -0,0 +1,394 @@ + + + + Setting up a development environment + + + + + + + + + + + + + + + +

Home » Docs

Setting up a development environment

Everything you need to know to start developing Apache ACE can be found here.

Obtaining the sources

There are two ways to obtain a copy of the source code. You can either download one of the +source releases, or checkout the code from subversion.

Download the sources

Point your browser to: http://ace.apache.org/download.html

On that page you will find, amongst others, a link to the latest released sources, plus an +archive containing all binary third-party dependencies. The page will automatically select +a download mirror close to you. Download both the source and dependencies archive and then +type:

$ unzip apache-ace-1.0.0-src.zip
+$ unzip apache-ace-1.0.0-deps.zip
+

+ + +

Note that when unzipping the second archive, you will get some warnings about overlapping +files. Those are the required NOTICE and LICENSE files, which are in the same location in +both archives. Just overwriting them is fine.

Checkout from subversion

$ svn co http://svn.apache.org/repos/asf/ace/trunk apache-ace
+

+ + +

In both cases you end up with a copy of the source code.

Building the sources

There are two ways to build the sources. You can either run a command line build or use +Eclipse with Bndtools to build everything. If you want to actively start developing, we +strongly recommend you use Eclipse with Bndtools as this is by far the most convenient way +to build and run Apache ACE within a development environment.

Eclipse with Bndtools

Prerequisites

For developing ACE using Eclipse, you need:

A recent Java JDK, at least Java 6;
A recent Eclipse, for example, Eclipse Juno with the following plugins:
Subclipse;
BndTools;
TestNG.

For building or exporting the compiled artifacts of ACE without Eclipse, you only need +Apache ANT version 1.8+ installed.

Eclipse set up

When firing up Eclipse, make sure to either create a new workspace and check out the +sources according to the instructions below, or choose the root folder where you have +previously checked out or extracted your copy of the sources. This is important, as +otherwise Bndtools will not function correctly.

Checking out the latest sources

If you created a new workspace above, you need to grab the latest sources from ACE's +subversion repository. To do this, open up the "SVN Repository Exploring" perspective, and +add the following URL as new SVN repository using the yellow add-icon in the "SVN +Repositories" view:

https://svn.apache.org/repos/asf/ace/trunk/
+

+ + +

After this, expand the newly created tree node named after the SVN URL, and select all +individual projects underneath. Note: do not (only) select the root node, as +this won't let you properly import the individual projects.

Right click on the selected (sub)projects, and choose "Checkoutâ¦" from the context menu. +Leave all default settings as-is and click "finish". Now relax and wait until the checkout +is completed, and all projects are imported into your workspace.

Switching back to the "Bndtools" perspective should give you a long list of imported +projects.

Importing existing projects

If you created a workspace in a folder that already contained the sources, you need to +import these projects into the workspace. From the main menu in Eclipse, choose: "File +-> Import..." and then select "General -> Existing projects into workspace..." and +select your workspace folder. A list of projects should show up now. Import them all, wait +until Eclipse has built the project and you're ready to start.

Coding guidelines

If you want to develop for ACE, you might want to import the code templates and formatter +rules for ACE. The formatter can be found in the etc folder in subversion, and you can +import it into Eclipse as your default formatter for this workspace.

Running & debugging

One of the benefits of the migration to BndTools is that we can now directly run ACE from +Eclipse with almost zero effort. In fact, it is even possible to directly debug or profile +ACE from Eclipse. By convention, all runnable projects start with "run-" and contain a +".bndrun" file.

ACE server

To run or debug the ACE server, you open up the "server.bndrun" file in the +"run-server" project. This will present you with a view in which you can directly choose +to run it (use "Run OSGi") or debug it (use "Debug OSGi"). Alternatively, you can right +click on "server.bndrun" and choose either "Run As -> Bnd OSGi Run Launcher" or "Debug +As -> Bnd OSGi Run Launcher".

ACE obr

To run or debug the ACE obr, you open up the "obr.bndrun" file in the "run-obr" +project. This will present you with a view in which you can directly choose to run it (use +"Run OSGi") or debug it (use "Debug OSGi"). Alternatively, you can right click on +"obr.bndrun" and choose either "Run As -> Bnd OSGi Run Launcher" or "Debug As -> Bnd +OSGi Run Launcher".

ACE client

To run or debug the ACE client, you open up the "client.bndrun" file in the +"run-client" project. This will present you with a view in which you can directly choose +to run it (use "Run OSGi") or debug it (use "Debug OSGi"). Alternatively, you can right +click on "client.bndrun" and choose either "Run As -> Bnd OSGi Run Launcher" or "Debug +As -> Bnd OSGi Run Launcher".

ACE server-allinone

To run or debug the "all in one" ACE server, you open up the +"server-allinone.bndrun" file in the "run-server-allinone" project. This will +present you with a view in which you can directly choose to run it (use "Run OSGi") or +debug it (use "Debug OSGi"). Alternatively, you can right click on +"server-allinone.bndrun" and choose either "Run As -> Bnd OSGi Run Launcher" or "Debug +As -> Bnd OSGi Run Launcher".

ACE target

You can also directly run a target from Eclipse. Doing this is almost equal as running the +ones described in the previous sections. The only difference is that for running a target, +you need to use the "target.bndrun" file from the "run-target" project.

Unit tests

ACE uses TestNG for its unit tests. To run a single test or a package of tests, use "Run +As -> TestNG Test" or "Debug As -> TestNG Test".

Integration tests

The integration tests of ACE are placed in separate projects that are -by convention- +named with a '.itest' suffix. These integration tests use BndTools to get an OSGi +framework up and running. To run one or all integration tests, use "Run As -> OSGi +JUnit Test" or "Debug As -> OSGi JUnit Test".

Command line build

Prerequisites

For developing ACE using Ant, you need:

A recent Java JDK, at least Java 6;
Apache ANT version 1.8+.

Building

The command line build for Apache ACE is based on Ant, and generated automatically when +using the Bndtools plugin in Eclipse.

The build is structured as a flat hierarchy of projects, and you can go into any of these +projects to build just that project and its dependencies. There are two special projects:

cnf -- Which is collection of repositories that contain all the required dependencies +for building and running Apache ACE;
build -- A project that depends on all other projects and is used to build +everything.

So, to build Apache ACE, we issue the following commands:

$ cd build
+$ ant
+

+ + +

In the end, this leaves us with a set of bundles (in the generated folder of each +project).

The following targets are available:

clean -- Cleans up any files in the current project that were generated during a build;
build -- Build the current project;
test -- Run the integration tests in the current project;
testng -- Run the unit tests in the current project;
deepclean -- Cleans up any files in the current project and all its dependencies;
deeptestng -- Runs the unit tests in the current project and all its dependencies;
deeptest -- Runs the integration tests in the current project and all its dependencies.

There actually are a few more, but these are the most important ones.

How to...

...use my favorite IDE (not Eclipse)?

Unfortunately, the easy answer is "no". Until somebody ports Bndtools to your favorite +IDE, you either have to use Eclipse, or a combination of your IDE and manual builds using +Ant (though not recommended). If you insist, please do make sure you manually generate the +proper metadata for Eclipse.

...build this thing in Eclipse?

Normally, you don't. Seriously. If "Build Automatically" is enabled, as soon as you hit +save after changing a line of code, BndTools will automatically build your bundle for you. +In fact, if your server if already running, Bndtools will even redeploy all changed +bundles to it automatically.

...get rid of all those red crosses in Eclipse?

If Eclipse complaints about missing test libraries, you probably forgot to install the +TestNG plugin. If this plugin is installed, it will automatically cause your projects to +get the required dependency to the TestNG library. Without this plugin, Eclipse won't have +the required library and fails to compile the code correctly.
+In case you are importing the projects into Eclipse for the first time, it takes a while +and a couple of builds to get rid of all build errors. If the problem does not go away, +please drop a line on the mailing lists to get +additional help.

...create a distributable archive

The next step is to create an archive for the server, so we end up with something we can +actually run:

$ cd build
+$ ant package-bin
+

+ + +

Now, in the generated folder, an archive will have been created. You can unzip this +archive, which should expose a couple of subfolders with the same names as the runnable +projects that you can go into and run. You can start the "all in one" server like this:

$ cd apache-ace-1.0.0-bin
+$ unzip apache-ace-1.0.0-bin/.zip
+$ cd server-allinone/
+$ java -jar server-allinone.jar
+

+ + +

For other projects, the steps are similar to this: just go into the correct folder and +launch the jar file.

...add an OSGi bundle

The easiest way to add an OSGi bundle, is to drag it onto the "Local Repository" entry in +the "Repositories" view, or to use the "Add files to repository" toolbar icon. Bndtools +will analyze the files you try to add and show their metadata if they're indeed valid +bundles.

The bundles will end up in the local repository inside the cnf project.

...add a Java library

If you want to add a library that does not contain any OSGi metadata, you can follow the +steps below to add it to the "Library Repository" so it can be used in all other projects +within Apache ACE. If your library does have sensible OSGi metadata, please follow the +"...add an OSGi bundle" instructions above.

Copy the library to the right location. The jar file for the library should be copied +to the following location: cnf/lib/foo/foo-1.0.0.jar. Note that the directory +name should be equal to the basename of the added JAR file, that is, everything before +the version-string of the JAR;
+
Update the repository.xml. After making changes to anything in cnf/lib/ you +need to update the index file that describes the contents of the repository. To do this +enter the following commands:
+
```
$ cd cnf
+$ ant build
+$ java -cp bin org.apache.ace.bnd.LibraryIndexer
+
```
+ + +

+ +

+ + Added: websites/staging/ace/trunk/content/docs/shell-api.html ============================================================================== --- websites/staging/ace/trunk/content/docs/shell-api.html (added) +++ websites/staging/ace/trunk/content/docs/shell-api.html Mon Nov 24 22:42:13 2014 @@ -0,0 +1,260 @@ + + + + Client Shell API + + + + + + + + + + + + + + + +

Home » Docs

Client Shell API

Introduction

To script the interaction with ACE, you can use its shell based client API. Typical use cases include the tight integration of ACE into your development or automated build process, the creation of a custom user interface, or interactive use for those who prefer a shell over a GUI.

The shell commands extend the standardized OSGi shell, using the GoGo implementation from Apache Felix. This page does not aim to give an overview of all commands available in that shell, so please consult the documentation of the GoGo shell itself in case you're not familiar with it.

Overview

Before we dive into the various shell commands, let's start with an overview of how all of this works. Everything in ACE is an entity. For example, an artifact or a feature is an entity, but also the association between an artifact and a feature is. Entities have properties and tags. Properties are the "fixed" attributes that make up a specific type of entity. For example a feature has a name and a description. If you know the type of entity, its properties are also known. Tags on the other hand are attributes that a user can freely add and refer to.

Sessions and Workspaces

The client, independent of whether you're using the WebUI, REST or shell, always works in the same way. You start out by creating a session or workspace that you can then start editing. Once you're happy with your changes, you commit them back to the server.

Creating a session in the shell is done like this:

w = (cw)
+

+ + +

The "cw" (create workspace) command checks out and returns a new workspace. We assign that result to a variable, because +all our subsequent commands operate on the workspace. Optionally, when creating the workspace, we can provide several parameters:

w = (cw [showunregisteredtargets=false])
+w = (cw european dutch dutch)
+w = (cw european dutch dutch [showunregisteredtargets=false])
+

+ + +

The three names (european dutch dutch) are names of repositories. ACE supports a flexible multi-tenancy mechanism that allows you to specify customer or tenant names for all the different repositories. In this example, we checkout a european store repository, and a dutch target and deployment repository. Most people will probably start out with a single workspace with default repositories.

The map (maps are entered like this: [key1=val1 key2=val2 key3=val3]) contains an optional set of configuration properties for the workspace. At the moment, the only property there is is "showunregisteredtargets" which determines if the workspace will contain targets that have not been registered. It finds those by scanning all audit logs. By default, they are included but in some use cases you might not want them to be visible. In such cases, rather than filtering them out of your results, you can completely remove them, which saves quite a bit of processing time as well.

When you're done with your workspace, you can clean it up like this:

rw $w
+

+ + +

This will remove the workspace from memory. Note that any changes will be lost, unless you commit the workspace first:

$w commit
+

+ + +

This is actually not a shell command we explicitly created. Instead, the shell is smart enough to scan an instance (our workspace $w) for methods and tries to invoke those. It also parses arguments as we will soon see.

Let's start creating some entities:

$w cf feature-base
+$w cd dist-core
+$w cf2d "(name=feature-base)" "(name=dist-core)"
+

+ + +

This gives us a feature, a distribution and the association between the two. Associations have a left and right hand side, and both are OSGi filters. This means you can create quite complex associations, but in this case we use a simple condition that matches only a single feature and distribution. If you want to see what you've created, you can list all entities of a certain type like this:

$w lf
+$w ld
+$w lf2d
+

+ + +

Lists all features, distributions and feature to distribution associations. These list commands accept a filter condition as well:

$w lf "(name=feature-*)"
+

+ + +

Lists all features whose name start with "feature-". Let's proceed by adding a bundle. Bundles are a specific type of artifact and there are several ways to add them. The easiest one, most of the time, is:

$w ca file:///path/to/some/bundle.jar true
+

+ + +

This will create an artifact, using the URL you specified. Because the second parameter was set to true, it will upload the artifact from that URL to the OBR. It will also extract all necessary metadata from the artifact: it recognizes the type and then uses type specific extraction mechanisms.

If you really want to, you can also create the bundle yourself and specify all the metadata manually:

$w ca [mimetype=application/vnd.osgi.bundle artifactName=org.foo Bundle-Name=org.foo Bundle-SymbolicName=org.foo Bundle-Version=1.0.0 url=http://localhost:8080/obr/org/foo/org.foo-1.0.0.jar processorPid=]
+$w ca2f "(Bundle-SymbolicName=org.foo)" "(name=feature-base)"
+

+ + +

This creates the bundle. The "url" is an important attribute as it tells ACE where to get the bundle from. In this example we assume it can already be found in the OBR at that location. We also create an association. On the bundle side, we use a filter that only specifies the symbolic name of the bundle. So what happens if there is more than one version of such a bundle available? To understand that, we need to explain a few more things about associations.

First of all, assocations have a cardinality for both sides. If you don't specify the cardinality, it defaults to "1:1". So what happens if you specify a filter that returns more than one entity? Two things. First of all, the list of entities is sorted in an order that is specific to the type of entity. Bundles are sorted by version, highest first. Finally, the cardinality is used to determine how many entities from the list to return. So in this case, from all the bundles with the same symbolic name, the bundle with the highest version is selected.

You can use this to create features that automatically update to the highest version of a bundle, or if you're more specific, are fixed to a version or version range. Combined with semantic versioning this gives you a powerful way to for example create a feature where bugfixes or backward compatible changes will automatically be upgraded, but major changes require human intervention.

Let's proceed to create a target:

$w ct target-1
+$w cd2t "(name=dist-core)" "(id=target-1)"
+

+ + +

This creates the target and associates it with the "dist-core" distribution.

Deleting entities is also quite easy. You first need to get hold of the entity you want to delete though, which can be done like this:

targetlist = ($w lt "(id=target-1)")
+

+ + +

This gives you a list of targets, but since the filter is very specific, the list will only contain one entity. The shell now has a helper command to fetch the first item from the list:

t1 = (first $targetlist)
+$w dt $t1
+

+ + +

Fetches the first and only target in the list and assigns it to a variable called "t1". Subsequently deletes the target from the workspace. Deleting other entities is done in a similar way.

+ +

+ + Added: websites/staging/ace/trunk/content/docs/simple-workflow.png ============================================================================== Binary file - no diff available. Propchange: websites/staging/ace/trunk/content/docs/simple-workflow.png ------------------------------------------------------------------------------ svn:mime-type = image/png Added: websites/staging/ace/trunk/content/docs/test-script.html ============================================================================== --- websites/staging/ace/trunk/content/docs/test-script.html (added) +++ websites/staging/ace/trunk/content/docs/test-script.html Mon Nov 24 22:42:13 2014 @@ -0,0 +1,200 @@ + + + + Test Script + + + + + + + + + + + + + + + +

Home » Docs

Test Script

Besides all our automated tests, sometimes it is useful to run some tests by hand to get a feel for the performance of Apache ACE and tweak it for specific scenarios. To aid in setting up and running such tests, an Ant script was made that allows you to:

Configure it to create a runnable server, a collection of targets or both.
Run every configured node.
Cleanup afterwards.

Typical use cases include running a set of targets and a server on the same box, or having two or more boxes and distributing server and (groups of) targets over both. The script, which is located in the ace-test project folder, assumes you have a full checkout of ACE and that you have actually already built the code (mvn -DskipTests=true clean install or something similar). It also assumes you have a recent version of Ant on your machine.

Before using the script, there are several variables that you can configure that influence its behaviour:

with-server - when defined, will run an ACE server;
with-targets - when defined, will run a number of targets;
targets - a comma separated list of target names ("target-" will be used as prefix for all of them);
server-host - the discovery URL for the server to use with the targets
version - the ACE version to use (should match whatever version of the code you checked out).

To run:

ant unzip will unzip all required code into folders under the current directory;
ant run will run all nodes (and at least on Linux and Mac OS X stop them again when you hit Ctrl-C);
ant rm will delete all folders and files created in steps 1 and 2.

For example, to run the ACE management server with 10 targets, we should do the following:

[localhost:~/]$ ant -Dtargets=1,2,3,4,5,6,7,8,9,10 unzip run
+...(CTRL+C)...
+[localhost:~/]$ ant -Dtargets=1,2,3,4,5,6,7,8,9,10 rm
+

+ +

+ + Added: websites/staging/ace/trunk/content/docs/use-cases/index.html ============================================================================== --- websites/staging/ace/trunk/content/docs/use-cases/index.html (added) +++ websites/staging/ace/trunk/content/docs/use-cases/index.html Mon Nov 24 22:42:13 2014 @@ -0,0 +1,204 @@ + + + + Use Cases + + + + + + + + + + + + + + + +

Home » Docs » Use-cases

Use Cases

The view below shows all the major use cases of Apache ACE. If you scroll down +you will also see a list of use cases, described in more detail when you click on +a use case.

List

+ +

+ + Added: websites/staging/ace/trunk/content/docs/use-cases/uc-01.html ============================================================================== --- websites/staging/ace/trunk/content/docs/use-cases/uc-01.html (added) +++ websites/staging/ace/trunk/content/docs/use-cases/uc-01.html Mon Nov 24 22:42:13 2014 @@ -0,0 +1,188 @@ + + + + Use Case 01 - Checkout + + + + + + + + + + + + + + + +

Home » Docs » Use-cases

Use Case 01 - Checkout

Check out data from a repository.

Flow

Basic Flow

Editor asks discovery service for a location of a server for a certain repository.
Editor contacts the repository to ask for a list of versions.
Editor checks out the latest version of the repository.

Alternative Flows

Server cannot be found.
Repository does not exist.
Latest version could not be checked out.

+ +

+ + Added: websites/staging/ace/trunk/content/docs/use-cases/uc-02.html ============================================================================== --- websites/staging/ace/trunk/content/docs/use-cases/uc-02.html (added) +++ websites/staging/ace/trunk/content/docs/use-cases/uc-02.html Mon Nov 24 22:42:13 2014 @@ -0,0 +1,190 @@ + + + + Use Case 02 - Commit + + + + + + + + + + + + + + + +

Home » Docs » Use-cases

Use Case 02 - Commit

Check out data from a repository.

Flow

Basic Flow

Editor asks discovery service for a location of a server for the repository.
Editor sends the modified repository the server, together with the version number this edit was based on.
Server reports back that the commit was successful.

Alternative Flows

Server cannot be found.
Repository does not exist.
Commit failed because of a merge conflict.

Details

When a commit fails because of a merge conflict, the client is expected to check out the newly added version and (with or without interaction from a user) merge all changes and then try again. This is explained in UC-03 Resolve merge conflict.

+ +

+ + Added: websites/staging/ace/trunk/content/docs/use-cases/uc-03.html ============================================================================== --- websites/staging/ace/trunk/content/docs/use-cases/uc-03.html (added) +++ websites/staging/ace/trunk/content/docs/use-cases/uc-03.html Mon Nov 24 22:42:13 2014 @@ -0,0 +1,190 @@ + + + + Use Case 03 - Resolve merge conflict + + + + + + + + + + + + + + + +

Home » Docs » Use-cases

Use Case 03 - Resolve merge conflict

Resolve merge conflicts and commit an updated version to a repository.

This use case extends commit.

Flow

Basic Flow

When the UC commit scenario fails because someone else committed a version while you were editing yours, the flow continues like this:

Editor fetches the latest version and now has three versions locally: the original version he started with, the working copy he is trying to commit and this latest version.
Editor reviews the three way diff and updates the working copy.
Editor tries to commit the working copy again, now referencing the latest version again. This is the normal commit use case.

Alternative Flows

None.

Details

This use case interacts with the commit use case and the user can go back and forward between the two as long as new merge conflicts pop up.

+ +

+ + Added: websites/staging/ace/trunk/content/docs/use-cases/uc-04.html ============================================================================== --- websites/staging/ace/trunk/content/docs/use-cases/uc-04.html (added) +++ websites/staging/ace/trunk/content/docs/use-cases/uc-04.html Mon Nov 24 22:42:13 2014 @@ -0,0 +1,193 @@ + + + + Use Case 04 - Check for update + + + + + + + + + + + + + + + +

Home » Docs » Use-cases

Use Case 04 - Check for update

Check for an updated set of artifacts for a gateway.

Flow

Pre-conditions

A target with an OSGi framework and our management agent.

Basic flow

Target retrieves its own identity.
Target asks the discovery service for the location of a server.
Target polls the server for a list of versions.
If there is a version that is newer than the currently installed version, poll for this update.
Install the update.
Report back to the server.

Alternative flows

If no server can be found, do nothing.
If there is no newer version, do nothing.
If the update cannot be installed, roll back to the previous version.

+ +