Return-Path: Delivered-To: apmail-geronimo-dev-archive@www.apache.org Received: (qmail 51557 invoked from network); 9 Dec 2009 18:43:48 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 9 Dec 2009 18:43:48 -0000 Received: (qmail 71643 invoked by uid 500); 9 Dec 2009 18:43:47 -0000 Delivered-To: apmail-geronimo-dev-archive@geronimo.apache.org Received: (qmail 71545 invoked by uid 500); 9 Dec 2009 18:43:47 -0000 Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: Reply-To: dev@geronimo.apache.org List-Id: Delivered-To: mailing list dev@geronimo.apache.org Received: (qmail 71537 invoked by uid 99); 9 Dec 2009 18:43:47 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 09 Dec 2009 18:43:47 +0000 X-ASF-Spam-Status: No, hits=-2.6 required=5.0 tests=BAYES_00 X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of linsun.unc@gmail.com designates 209.85.220.226 as permitted sender) Received: from [209.85.220.226] (HELO mail-fx0-f226.google.com) (209.85.220.226) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 09 Dec 2009 18:43:45 +0000 Received: by fxm26 with SMTP id 26so7108540fxm.39 for ; Wed, 09 Dec 2009 10:43:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=aChwvdClLedifXuo4v4Qm6p4Op1mNzw1oNFEWNta/l4=; b=W8b5hqF2mux2KszCUPvbTlGu9QGMvAf0Zi5Yu2kcaJnRE+6OHOrfKswVrlx3yyKVb0 0H7XZUzmrUQtil7pUm1hdtmdyQHwhe/ng2AMTooDPMdwAyfay2YLV5aB6K3mu7aUfnzV bs2slEaJ6nAgrG9W+mpp4ebnCCf1d+FhHhf4U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=WveBnfxljTi5UJjUo0Z3Nlhf5RsQumbtpeWa47heMX7d3KGJfU9b8sNyXC8/n4kQvj 4+jEmLOiMKrUQAyN4lJin2ty17oz2PjerSXrYu0pH0rUaRABlzPkoSqge9O8+J3j/ejw 42uiOaTm5PrRlnbAFcVmO8l2eeP3nqHLCCmmU= MIME-Version: 1.0 Received: by 10.223.18.137 with SMTP id w9mr2099151faa.61.1260384203669; Wed, 09 Dec 2009 10:43:23 -0800 (PST) In-Reply-To: <4B1FEBDD.6030904@gmail.com> References: <5eb405c70912082027i139d6c3ax4a46dc279fd7455@mail.gmail.com> <4B1FEBDD.6030904@gmail.com> Date: Wed, 9 Dec 2009 13:43:23 -0500 Message-ID: Subject: Re: Understanding the "partial=true; mandatory:=partial" trick From: Lin Sun To: dev@geronimo.apache.org, rickmcg@gmail.com Content-Type: text/plain; charset=ISO-8859-1 Interesting. I used other mandatory attribute without Require-Bundle fine before. And "partial" here is just same as other mandatory attribute, right? Anyway this should be something quick to try to see if we could avoid Require-Bundle Lin On Wed, Dec 9, 2009 at 1:26 PM, Rick McGuire wrote: > Everything I've seen about using partial=true in the core specification also > indicates that Require-Bundle is necessary to get everything wired up > together. I don't see anything in the core specification that indicates > partial=true has any meaning on an Import-Package. Section 3.12.1 > specifically states: > > "...only bundles using the Require-Bundle header can have split packages." > > Which pretty much states that Require-Bundle needs to be used. > > Rick > > >> Lin >> >> On Tue, Dec 8, 2009 at 11:27 PM, Jarek Gawor wrote: >> >> >>> >>> The best solution is of course the remove the split package problem in >>> the first place. But if that's not possible, another solution is to >>> combine the mandatory attribute trick with Require-Bundle. That is, >>> bundle 1 exports package X with some mandatory attribute and bundle 2 >>> has Require-Bundle on bundle 1 (and also exports package X). So all >>> imports on package X would always be wired to bundle 2 and bundle 2 >>> would have access to all classes in package X. Do I have that right? >>> >> >> > >