Return-Path: X-Original-To: apmail-karaf-dev-archive@minotaur.apache.org Delivered-To: apmail-karaf-dev-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 3C0E218569 for ; Wed, 2 Dec 2015 12:45:01 +0000 (UTC) Received: (qmail 70839 invoked by uid 500); 2 Dec 2015 12:44:54 -0000 Delivered-To: apmail-karaf-dev-archive@karaf.apache.org Received: (qmail 70802 invoked by uid 500); 2 Dec 2015 12:44:54 -0000 Mailing-List: contact dev-help@karaf.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@karaf.apache.org Delivered-To: mailing list dev@karaf.apache.org Received: (qmail 70791 invoked by uid 99); 2 Dec 2015 12:44:54 -0000 Received: from mail-relay.apache.org (HELO mail-relay.apache.org) (140.211.11.15) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 02 Dec 2015 12:44:54 +0000 Received: from mail-io0-f177.google.com (mail-io0-f177.google.com [209.85.223.177]) by mail-relay.apache.org (ASF Mail Server at mail-relay.apache.org) with ESMTPSA id 958501A00C5 for ; Wed, 2 Dec 2015 12:44:54 +0000 (UTC) Received: by ioc74 with SMTP id 74so43737543ioc.2 for ; Wed, 02 Dec 2015 04:44:53 -0800 (PST) X-Received: by 10.107.3.227 with SMTP id e96mr3329708ioi.30.1449060293565; Wed, 02 Dec 2015 04:44:53 -0800 (PST) MIME-Version: 1.0 Received: by 10.36.1.129 with HTTP; Wed, 2 Dec 2015 04:44:33 -0800 (PST) In-Reply-To: References: <2F02910E-BDBC-45B8-83C0-7D311E05BC13@leangen.net> <565C1995.5090001@nanthrax.net> <565C1ED9.9080403@die-schneider.net> <5C70AD8D-28F2-4BA9-AF51-6313447CAB19@leangen.net> <565C2DE5.2010903@die-schneider.net> <97C483B3-4EB8-409A-B08C-111799CD32BF@leangen.net> <1449036402060-4043974.post@n3.nabble.com> <0737B14A-4AD5-455A-AEF7-9128B62DEFFF@leangen.net> From: Guillaume Nodet Date: Wed, 2 Dec 2015 13:44:33 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Bndtools & Karaf : the right way To: dev Content-Type: multipart/alternative; boundary=001a113f0c5a0e79ac0525e9a4da --001a113f0c5a0e79ac0525e9a4da Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Also, if the use case is a simple one, we still have the features-generate-descriptor goal in our plugin that can generate simple features descriptors and I we could also add a goal (or enhance the existing one) to generate the features xml from the resource repository. Guillaume 2015-12-02 13:34 GMT+01:00 Guillaume Nodet : > > > 2015-12-02 11:04 GMT+01:00 David Leangen : > >> >> Hi Guillaume, >> >> Thank you very much for looking into this so quickly! >> >> >> So i've just experimented a bit with this repository. >> I've added the following repository to karaf which could easily be >> generated. >> >> > name=3D"enroute-demo"> >> >> file:///Users/gnodet/work/tmp/org.apache.karaf.demos.enroute/cnf/release= /index.xml >> >> >> karaf.identity;filter:=3D"(&(karaf.identity=3Denroute-d= emo)(type=3Dkaraf.feature))" >> >> >> >> >> What do you mean by =E2=80=9Cgenerated=E2=80=9D? Do you mind providing a= few more details? >> > > What could be done is a command that would create the features > repository, given the resource xml repository generated by bnd. It's jus= t > about parsing the repository, finding the "application" bundles, and crea= te > the above blob of xml. Nothing very difficult from a technical pov. > > Again, the real problem is that I think those repositories should be > transitively closed, i.e. they should contain everything needed to actual= ly > install and run the application. It's currently not the case, as it seem= s > that bnd will only generate the xml repository for the bundles in the > project, not their dependencies. > > I think we end up with really two different things here: bndtools is > certainly a nice toolchain to build OSGi bundles. It does not look like = a > runtime deployment mechanism. And that's what karaf features are. > They should contain enough information for the whole application to be > deployed, eventually the container to be modified (karaf provides > "profiles" which may contain non ConfigAdmin configuration, libraries to > add to the class path, etc...) > It's one thing to generate the bundles, it's a different one to deploy > them in a system, manage the lifecycle of the applications, upgrade > applications, etc... > > The more I think about it, the less I think it's a good idea to have too > much support for applications. It will lack support for some features at= a > later point, and those have been already solved and would only support > simple use cases. > Imho, if you plan on deploying your bundles in Karaf, you should generate > a feature inside your build. For the above, it's just a matter of adding= a > dependency on the felix scr feature and a bundle dependency on the other > extender. > > Anyway, once the 4.0.x branch has been created, I'll push what I have so > far to master, that will allow you to use the eleme= nt > inside features and fix a bunch of other problems related to deploying > resources from those repositories. > > >> >> >> After having fixed a few problems in Karaf, I was at a point where I >> couldn't deploy the feature, because the above feature is not transitive= ly >> closed. It requires 2 extenders (osgi.component >> and osgi.enroute.configurer), but those are not provided in the xml. >> I suppose the information is somewhat given from the list below: >> >> https://github.com/dleangen/org.apache.karaf.demos.enroute/blob/master/o= rg.apache.karaf.demos.enroute.application/org.apache.karaf.demos.enroute.bn= drun#L11-L22 >> >> But those informations should appear somewhere, else you can't figure >> what to deploy in order to solve those requirements. >> >> >> Hmmm=E2=80=A6 >> >> In enRoute, these just get resolved, so I have never really thought abou= t >> it. >> >> My main worry now is about those un satisfied requirements. >> If the generated xml repository only contains the bundles that you are >> writing, we need a way to give a list of bundles that will actually solv= e >> the requirements that are not satisfied by the generated bundles (such a= s >> the 2 extenders above), but it could be different requirements on packag= es, >> services, etc=E2=80=A6 >> >> >> Maybe it could be a standard "enRoute" repository that we can provide as >> or global resource repository ? >> >> >> I personally think this is a great idea! :-) >> >> >> Cheers, >> =3DDavid >> >> > --001a113f0c5a0e79ac0525e9a4da--