Return-Path: Delivered-To: apmail-incubator-harmony-dev-archive@www.apache.org Received: (qmail 83367 invoked from network); 13 Feb 2006 13:48:07 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 13 Feb 2006 13:48:07 -0000 Received: (qmail 64007 invoked by uid 500); 13 Feb 2006 13:48:02 -0000 Delivered-To: apmail-incubator-harmony-dev-archive@incubator.apache.org Received: (qmail 63954 invoked by uid 500); 13 Feb 2006 13:48:02 -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 63942 invoked by uid 99); 13 Feb 2006 13:48:02 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 13 Feb 2006 05:48:02 -0800 X-ASF-Spam-Status: No, hits=3.9 required=10.0 tests=RCVD_IN_BL_SPAMCOP_NET,RCVD_IN_SORBS_WEB,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (asf.osuosl.org: 217.158.94.220 is neither permitted nor denied by domain of t.p.ellison@gmail.com) Received: from [217.158.94.220] (HELO cirrus.purplecloud.com) (217.158.94.220) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 13 Feb 2006 05:48:01 -0800 Received: (qmail 73060 invoked from network); 13 Feb 2006 13:47:40 +0000 Received: from blueice4n2.uk.ibm.com (HELO ?9.20.183.163?) (195.212.29.92) by smtp.purplecloud.net with (DHE-RSA-AES256-SHA encrypted) SMTP; 13 Feb 2006 13:47:40 +0000 Message-ID: <43F08DFB.7030907@gmail.com> Date: Mon, 13 Feb 2006 13:47:39 +0000 From: Tim Ellison User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: harmony-dev@incubator.apache.org Subject: Re: Location for API extensions References: <46d21a9a0602082352r4f90920ax950854c890480e2f@mail.gmail.com> <43EC5C04.4050100@gmail.com> <46d21a9a0602100152w2d51dff8n655f52d3e2f1663a@mail.gmail.com> <20060210110006.GH31375@bali.sjc.webweaving.org> <43F076FE.9070105@gmail.com> <906dd82e0602130426p6054b9fbt72742289dd94b8ba@mail.gmail.com> <46d21a9a0602130454g679c9127x58379b749113c86a@mail.gmail.com> In-Reply-To: <46d21a9a0602130454g679c9127x58379b749113c86a@mail.gmail.com> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 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 Anton Avtamonov wrote: > Hi Tim, > > Lemme join to Mikhail's words: very good! Thank you! > I'm sure it will simplify the contribution process. Of course, we have > committers who control the process, no doubts; however for me (and I > think not for me only) it is much simplier to have the guideline of > what structure is expected. I appreciate your efforts to get the code right before contribution. I'm very pragmatic though, and would rather have functional code that solves people's problems ahead of pretty layout! I expect that we will migrate towards compliance with our own guidelines over a period of time . > Could we call *anything_alse* somehow :-)? Personally I would prefer > *external* as opposite to *internal*, but I expect nobody will agree. I disagree ;-) (just to prove you right). IMHO besides being esthetically pleasing it makes it easy to catch references to internal code. > Let's me also support Mikhail in his comments: > > On 2/13/06, Mikhail Loenko wrote: >> Looks very good! >> >> I have two comments/questions. >> >> 1. I thought we agreed that *some* tests should be in the same package as >> implementations. How this fits together with a special package name for tests? > > Yeah, looks like it will cause visibility problems, won't it? Sorry, I think this is a simple misunderstanding -- the guidelines are only for the org.apache.harmony packages. >> 2. Does not it sound too strict: "module developers who modify code that is not >> in an internal package must do so in a manner that ensures Java binary >> compatibility"? How about "... should avoid breaking Java binary compatibility >> and must check that the change does not break other modules" > > Also agree. In general, binary compatibility should be supported, > however it could be very complicated to eastablish proper interfaces > from the beginning... If you are unsure what to expose, then make everything internal until there is a need to make it visible to other module developers. These interfaces/dependencies likely already exist within the code so this only makes them explicit not more difficult. > Btw, is it right that the module contributor himself can decide what > to put into functionality available for other modules? Sure, but if I'm writing jar support in ARCHIVE and I need some internal-API to help me implement, ooh say, signature verification from SECURITY then I know where to come :-) Regards, Tim -- Tim Ellison (t.p.ellison@gmail.com) IBM Java technology centre, UK.