RFR: 7141675 Fix jcheck issues in .m sources (original) (raw)

Scott Kovatch scott.kovatch at oracle.com
Wed Feb 1 08:27:45 PST 2012

Sadly, it doesn't, as far as I can tell. I have been using BBEdit or TextMate for Obj-C files for just that reason.

I haven't tried AppCode from JetBrains yet.

-- Scott K.

Sent from my iPad

On Feb 1, 2012, at 8:01 AM, Leonid Romanov <leonid.romanov at oracle.com> wrote:

Btw, how does one strip trailing whitespaces/empty lines in XCode?

On 01.02.2012, at 19:17, Daniel D. Daugherty wrote:

That will be a problem. If jcheck is changed in such a way that an already committed changeset would be rejected, then it has to be added to the whitelist. Otherwise, a fresh clone will fail when jcheck processes the now offending changeset...

Yes, this implies that jcheck has a scaling problem. As more changesets are added to a repo, the more work jcheck has to do... eventually all compute cycles will be consumed by jcheck... :-) Dan

On 2/1/12 7:44 AM, Michael McMahon wrote: Yes, that could be a problem. I think they will have to be added to the whitelist. - Michael On 01/02/12 13:32, Weijun Wang wrote: I'm wondering if jcheck is updated to include these .m files, will it reject the old changesets where the .m files contain trailing whitespaces? Or, should those changesets be added into the whitelist?

Thanks Max

On 02/01/2012 08:25 PM, Anthony Petrov wrote: Hi Michael, The patch looks fine to me. It would be great to update jcheck as well so that the formatting requirements be enforced for further putbacks. -- best regards, Anthony On 2/1/2012 3:56 PM, Michael McMahon wrote: This change is just to fix some white-space/tab problems that crept into some objective C files whose filename (extension .m) is not currently known to jcheck. http://cr.openjdk.java.net/~michaelm/7141675/webrev.1/ There is nothing to see in the webrev as white-space diferences are ignored. But the patch shows the actual changes. Thanks Michael.

More information about the macosx-port-dev mailing list