From harmony-dev-return-1802-apmail-incubator-harmony-dev-archive=incubator.apache.org@incubator.apache.org Mon Jul 25 14:31:42 2005 Return-Path: Delivered-To: apmail-incubator-harmony-dev-archive@www.apache.org Received: (qmail 88616 invoked from network); 25 Jul 2005 14:31:41 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 25 Jul 2005 14:31:41 -0000 Received: (qmail 83655 invoked by uid 500); 25 Jul 2005 14:31:30 -0000 Delivered-To: apmail-incubator-harmony-dev-archive@incubator.apache.org Received: (qmail 83597 invoked by uid 500); 25 Jul 2005 14:31:30 -0000 Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: harmony-dev@incubator.apache.org Delivered-To: mailing list harmony-dev@incubator.apache.org Received: (qmail 83584 invoked by uid 99); 25 Jul 2005 14:31:29 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 25 Jul 2005 07:31:29 -0700 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received-SPF: error (asf.osuosl.org: local policy) Received: from [216.104.160.39] (HELO mx-out.daemonmail.net) (216.104.160.39) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 25 Jul 2005 07:31:18 -0700 Received: from localhost.daemonmail.net (localhost.daemonmail.net [127.0.0.1]) by mx-out.daemonmail.net (8.13.1/8.12.9) with SMTP id j6PET6Dl057501 for ; Mon, 25 Jul 2005 07:29:06 -0700 (PDT) (envelope-from heavy@ungoverned.org) Received: from [24.180.252.202] (via account 16414) by mx-out.daemonmail.net with ESMTP id MZP249h5 authenticated by SMTP; Mon, 25 Jul 2005 07:29:05 -0700 (PDT) Message-ID: <42E4F768.7050801@ungoverned.org> Date: Mon, 25 Jul 2005 10:30:00 -0400 From: "Richard S. Hall" User-Agent: Mozilla Thunderbird 1.0.2-6 (X11/20050513) X-Accept-Language: en-us, en MIME-Version: 1.0 To: harmony-dev@incubator.apache.org Subject: Re: Class library componentization References: <42E0C381.7060201@gmail.com> <42E4C632.8070805@gmail.com> <5258232B-9BC8-42BB-9A3F-297923C42E08@apache.org> In-Reply-To: <5258232B-9BC8-42BB-9A3F-297923C42E08@apache.org> 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 Geir Magnusson Jr. wrote: > I assume that what we really need is two kinds of component export, > the public app level API (java.util.*) and a public-yet-not-for-app- > but-fellow-traveler API, such as what other conspiring modules would > export to each other to provide the full public API. > > Kinda like "friend API" w/o the horror of having to declare who your > friends are... You can achieve this sort of effect with some of the new constructs proposed for OSGi R4, since you can include/exclude classes from exported packages and then use mandatory attributes to restrict visibility. It is probably not the cleanest way of doing this, but it does work. > Sure - Can we also version the supported public-for-friend API in > some way? (I need to go read the OSGi spec...) No, there is only one package version. So, if they have the same package name, then they can only have one version. If you want multiple versions, then you have to have multiple separate packages. There are some ways to cheat on this perhaps, since a package can be exported multiple times, but it would be ugly. Perhaps what OSGi needs is general version attribute support, so that people can attach arbitrary version attributes for this type of thing. Or better yet, a general dependency model. All of this, however, would start to greatly complicate the framework implementation. -> richard