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 <g>. > 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 <[EMAIL PROTECTED]> 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 ([EMAIL PROTECTED]) IBM Java technology centre, UK.
