From open-jpa-dev-return-63-apmail-incubator-open-jpa-dev-archive=incubator.apache.org@incubator.apache.org Fri Jun 02 19:56:32 2006 Return-Path: Delivered-To: apmail-incubator-open-jpa-dev-archive@locus.apache.org Received: (qmail 82605 invoked from network); 2 Jun 2006 19:56:32 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 2 Jun 2006 19:56:32 -0000 Received: (qmail 9772 invoked by uid 500); 2 Jun 2006 19:56:32 -0000 Delivered-To: apmail-incubator-open-jpa-dev-archive@incubator.apache.org Received: (qmail 9732 invoked by uid 500); 2 Jun 2006 19:56:32 -0000 Mailing-List: contact open-jpa-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: open-jpa-dev@incubator.apache.org Delivered-To: mailing list open-jpa-dev@incubator.apache.org Delivered-To: moderator for open-jpa-dev@incubator.apache.org Received: (qmail 86412 invoked by uid 99); 2 Jun 2006 18:44:15 -0000 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: local policy) Mime-Version: 1.0 (Apple Message framework v750) In-Reply-To: <2A86AFBC-206D-4D7C-BF94-753B09EDCB9C@SUN.com> References: <2A86AFBC-206D-4D7C-BF94-753B09EDCB9C@SUN.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9FDA7083-DDA3-41D7-BD07-8B5B34BB4A91@mac.com> Content-Transfer-Encoding: 7bit From: Abe White Subject: Re: java.util.concurrent Date: Fri, 2 Jun 2006 11:43:27 -0700 To: open-jpa-dev@incubator.apache.org X-Mailer: Apple Mail (2.750) X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N > Consistency is good. I look forward to helping out. By the way, it > might be good to take a look at the OpenJPA coding guidelines at > http://incubator.apache.org/openjpa/ which I made up (based on the > Geronimo standards. The guidelines can be changed to suit our > project, but please take a look. Actually, the coding standards link from the above page goes directly to the Geronimo project standards. You seem to imply that maybe you meant to copy their standards into our own document?. Anyway, currently we have a formatter that produces code with the following significant differences from the linked guidelines: - Uses package.* imports, rather than importing every class. I personally favor this approach because dependencies tend to be package-level anyway, and it's what we've historically used with Kodo. - Indents line continuations one logical tab (4 spaces), rather than indenting 2 tabs or attempting to align the continued line with the previous (for example, aligning method parameter declarations). - The formatter retains inconsistencies in our existing source. I believe the only noticeable one is that the SolarMetric developers all like to break continued lines at different points (before opening paren, after opening paren, before dot in call chain, after dot, etc). We tried the free version of Jalopy and it didn't work well for us, so the formatter I'm referring to is an in-house formatter I wrote that doesn't create a syntax tree -- it just looks for certain SolarMetric formatting constructs with regexps and changes them to be more Sun-like in style. So if we want a different style, we'll probably have to see about purchasing a commercial formatter, since my regexp approach is very limited.