Return-Path: X-Original-To: apmail-ace-users-archive@minotaur.apache.org Delivered-To: apmail-ace-users-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 20E25105EB for ; Fri, 20 Dec 2013 07:38:36 +0000 (UTC) Received: (qmail 93089 invoked by uid 500); 20 Dec 2013 07:38:35 -0000 Delivered-To: apmail-ace-users-archive@ace.apache.org Received: (qmail 92065 invoked by uid 500); 20 Dec 2013 07:38:31 -0000 Mailing-List: contact users-help@ace.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: users@ace.apache.org Delivered-To: mailing list users@ace.apache.org Received: (qmail 92057 invoked by uid 99); 20 Dec 2013 07:38:30 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 20 Dec 2013 07:38:30 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=5.0 tests=RCVD_IN_DNSWL_NONE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: local policy includes SPF record at spf.trusted-forwarder.org) Received: from [194.109.24.33] (HELO smtp-vbr13.xs4all.nl) (194.109.24.33) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 20 Dec 2013 07:38:25 +0000 Received: from [10.0.0.33] (planetmarrs.xs4all.nl [82.95.193.148]) (authenticated bits=0) by smtp-vbr13.xs4all.nl (8.13.8/8.13.8) with ESMTP id rBK7c1PB070154 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 20 Dec 2013 08:38:02 +0100 (CET) (envelope-from marcel.offermans@luminis.nl) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) Subject: Re: ace setup From: Marcel Offermans In-Reply-To: <52B31935.6040703@gmx.de> Date: Fri, 20 Dec 2013 08:38:01 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <6019BD83-5E14-4E51-8B8C-A3573E4FE3AA@luminis.nl> References: <52B19D1D.4080407@gmx.de> <427BBE76-2DD4-4928-B5A5-8D507FB91D1A@luminis.nl> <52B31935.6040703@gmx.de> To: "" X-Mailer: Apple Mail (2.1822) X-Virus-Scanned: by XS4ALL Virus Scanner X-Virus-Checked: Checked by ClamAV on apache.org Hello Marco, On 19 Dec 2013, at 17:05 , Marco Westermann = wrote: > thank you for your answer. Yes, I already watched that video and liked = the way you are describing in the video. But as you said: there are = still some questions. I will try to ask concrete questions where I have = problems. >=20 > At the moment I think of the following scenario: >=20 > I setup an OBR like karaf OBR on my server and configure my bundles so = they are pushed to the OBR. >=20 > That leads me to my first question: what do I have to do to setup ace = that it uses repository on server xyz. Or in other words: where do I = configure ace what repo to use. > If I'm right pushing to my remote OBR wouldn't be enough as I also = have to provide ace with meta-informations about my bundle. So I would = have to tell ace that there is a new artifact available ?! This may be = done about a gogo shell script ?! Yes. Let me start by stating that for ACE, an artifact (bundle, configuration = file, whatever) is just an object with some metadata. For artifacts, the = most important properties are the type of artifact and its URL. The = latter points to where the artifact is stored, and when a target = requests an update, such URLs are used to fetch the correct artifacts. So, in theory, anything that provides artifacts via a URL can act as an = =93OBR=94 for ACE (you can even use file:/// URLs but in general I would = not recommend that). To tell ACE about an artifact, you have to define it. Manipulating = artifacts, features, etc. in general is done by the ACE client, and for = that client we provide three different interfaces: a WebUI, a REST UI = and a Gogo Shell UI. We tend to use the shell the most when automating = things, because the scripting language is quite powerful. If you, = through any of these client interfaces, fill out the URL and other = metadata by hand, you don=92t even need to configure an OBR. Now, the ACE client can be configured to work with an OBR. In the =93conf=94= folder (of run-client, if you=92re running ACE from Eclipse, or your = client distribution otherwise) you can configure where this OBR is. = Actually, within Eclipse, also look at the client.bndrun as it contains = a variable for the OBR location. If you do that, for example in the = WebUI you can upload bundles to such an OBR directly from your browser. = There is one requirement though, since the OBR specification does not = specify any way of =93uploading=94 artifacts to an OBR, in ACE we = extended that spec a bit by adding a REST interface for that. In other = words, for uploading to work, you need to use =93our=94 OBR. = Contributions in this area, to make such a feature work for Nexus for = example, would be welcome. > If until here everything would work I would have my bundles in ace so = I can configure features, distributions and targets etc. >=20 > Then my next problem would be: >=20 > My OSGI bundles use other external bundles available in maven central = ( my bundles use camel, activemq, cxf etc ) >=20 > is it possible that ace can provide my target(s) with these bundles, = too without manually adding the bundles to ace. ( maybe by proxying = maven central with my own obr ?!) Yes, see above, as long as you can provide an URL to such bundles, you = can use them. > And the last question for today: >=20 > I cannot find detailed instructions on how to tell ace where my = targets are. I have some instances of karaf running on different = servers. How would I configure that ace knows how to provide my karaf = instance. I think I've read that I need to install an ace bundle to the = target container but I cannot figure out what bundle I need and how to = configure it. On the target you need to run a management agent bundle. This is an = ordinary bundle. It can be configured with, amongst other things, a = =93target ID=94 (which is the ID that shows up in the target column of = ACE) and a URL to the ACE server (these properties are called = identification and discovery and can be provided as system properties). Technically, the ACE server does not need to know where the targets are, = as the targets poll the server for updates. Greetings, Marcel