Return-Path: Delivered-To: apmail-incubator-oscar-dev-archive@www.apache.org Received: (qmail 26782 invoked from network); 19 Sep 2005 17:51:29 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 19 Sep 2005 17:51:29 -0000 Received: (qmail 14889 invoked by uid 500); 19 Sep 2005 17:51:28 -0000 Delivered-To: apmail-incubator-oscar-dev-archive@incubator.apache.org Received: (qmail 14808 invoked by uid 500); 19 Sep 2005 17:51:28 -0000 Mailing-List: contact oscar-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: oscar-dev@incubator.apache.org Delivered-To: mailing list oscar-dev@incubator.apache.org Received: (qmail 14768 invoked by uid 99); 19 Sep 2005 17:51:27 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 19 Sep 2005 10:51:27 -0700 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received: from [130.237.222.115] (HELO smtp.nada.kth.se) (130.237.222.115) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 19 Sep 2005 10:51:36 -0700 X-Authentication-Info: The sender was authenticated as danielf using PLAIN at smtp.nada.kth.se Received: from [85.226.148.180] (c-b494e255.188-1-64736c14.cust.bredbandsbolaget.se [85.226.148.180]) (authenticated bits=0) by smtp.nada.kth.se (8.12.11/8.12.11) with ESMTP id j8JHpLx0020335 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 19 Sep 2005 19:51:22 +0200 (MEST) Message-ID: <432EFB94.3050800@nada.kth.se> Date: Mon, 19 Sep 2005 19:55:32 +0200 From: Daniel Fagerstrom User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: oscar-dev@incubator.apache.org Subject: Re: Felix M2 Plugin feedback References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N Jeff McAffer wrote: > Daniel Fagerstrom wrote on 09/19/2005 05:11:12 AM: ... >>Another question: how should we handle dependencies? ... > All of this to illustrate that matching the compile-time structure to the > runtime structure is quite important. Now I remember that I have asked this before and that you answered: > Yes. One of the design points we put in a couple of releases ago was an > explicit separate State/Resolver API that tooling and installers can use > to model and explore prospective configurations of bundles. This is the > exact resolver that the framework uses. No claims that it is perfect but > check out org.eclipse.osgi.service.resolver. It covers many usecases. I don't know enough about OSGi framework implementation to have any opinion about the API. But it would IMO make sense to reuse the work from Eclipse or cooperate with Eclipse on this. If we where to use the org.eclipse.osgi.service.resolver APIs and your implementation of it, is it possible to use standalone or does it require large part of the Eclipse OSGi framework? Also it is not obvious for me how to go from a couple of bundles and an implementation of the State API to a classloader suited for compiling a bundle depending on the bundles. /Daniel