From sflaniga at redhat.com Tue Oct 1 02:41:51 2013 From: sflaniga at redhat.com (Sean Flanigan) Date: Tue, 01 Oct 2013 12:41:51 +1000 Subject: [zanata-devel] The great Zanata reformat of 2013 In-Reply-To: <52453F05.7080509@redhat.com> References: <52453F05.7080509@redhat.com> Message-ID: <524A366F.2030507@redhat.com> On 2013-09-27 18:17, Sean Flanigan wrote: > Hi All, > > I have just committed the reformat for zanata-server, the last of the > main Zanata repos. I already formatted parent, api, common and client > earlier. > > All the formatter profiles I used can be found in the zanata-parent repo: > * eclipse-code-formatter*.xml: Eclipse code formatter profiles for Java > and JavaScript. NB: these can (and should) be used with the IntelliJ > plugin too: http://plugins.jetbrains.com/plugin/?idea&id=6546 > * intellij-code-style-settings.jar: IntelliJ code style settings for > other file types (XML, Groovy, etc) > > I also have some Eclipse settings for these which should be reasonably > close, but I haven't extracted them yet. > > I have also configured Checkstyle with a few whitespace checks. This is > now active for most of the Jenkins builds, including pull request > builds. Unfortunately, I had to disable the indent check, because it > couldn't handle lines which have been broken and then indented an extra > level. > > So please make sure you use the correct indenting for each file, or we > might have to reject your pull request: > https://github.com/zanata/zanata-server/wiki/Coding-Guide > > > Important note > -------------- > > > If you have any outstanding branches/pull requests for zanata-server: > > To minimise conflicts when merging, don't reformat your changes right > away. Please use this procedure in your feature branch: > > > $ git fetch > > # VERY, VERY IMPORTANT: merge everything *before* the reformat > $ git merge 4bcf574b8a^ > > # Now, merge the reformat itself, but ignore reformatting where it conflicts > $ git merge 4bcf574b8a -s recursive -X ours The above step is more dangerous than I thought - when reformatting is involved git sometimes fails to detect semantic conflicts. (In one case this led to two identical fields, and one missing field.) If you have really good test coverage, this might be okay, but otherwise read on... If you have a small to medium change, it's probably best to do a normal merge here, and just deal with the conflicts. The merge option -Xignore-all-space should cut down on the conflicts here. If you have a larger change, you could try the recursive/ours merge, but then replace your modified files using the first merge node above ("Merge from '4bcf574b8a^'"). It's a bit error-prone, so I would recommend the other option if possible. Either way, I hope the code you changed has good test coverage! > > # NB: At this point, use your IDE to reformat your *modified* files > only! Please inspect the result visually. > > # optional: > $ git merge origin/master > > # finally: > $ git push your feature branch > > Then we will review the merge to make sure it looks okay. > > Let me know if that procedure doesn't work for you, and we'll sort > something out. > > Sean. > > > PS if you want to review your changes across branches more easily, try this: > > git config --global alias.wdiff "diff --color-words --ignore-all-space" > > This creates a new "git wdiff" command which ignores whitespace. > > -- Sean Flanigan Senior Software Engineer Engineering - Internationalisation Red Hat -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 295 bytes Desc: OpenPGP digital signature URL: From sflaniga at redhat.com Tue Oct 1 02:44:18 2013 From: sflaniga at redhat.com (Sean Flanigan) Date: Tue, 01 Oct 2013 12:44:18 +1000 Subject: [zanata-devel] The great Zanata reformat of 2013 In-Reply-To: <524A366F.2030507@redhat.com> References: <52453F05.7080509@redhat.com> <524A366F.2030507@redhat.com> Message-ID: <524A3702.9020400@redhat.com> On 2013-10-01 12:41, Sean Flanigan wrote: > On 2013-09-27 18:17, Sean Flanigan wrote: >> Hi All, >> >> I have just committed the reformat for zanata-server, the last of the >> main Zanata repos. I already formatted parent, api, common and client >> earlier. >> >> All the formatter profiles I used can be found in the zanata-parent repo: >> * eclipse-code-formatter*.xml: Eclipse code formatter profiles for Java >> and JavaScript. NB: these can (and should) be used with the IntelliJ >> plugin too: http://plugins.jetbrains.com/plugin/?idea&id=6546 >> * intellij-code-style-settings.jar: IntelliJ code style settings for >> other file types (XML, Groovy, etc) >> >> I also have some Eclipse settings for these which should be reasonably >> close, but I haven't extracted them yet. >> >> I have also configured Checkstyle with a few whitespace checks. This is >> now active for most of the Jenkins builds, including pull request >> builds. Unfortunately, I had to disable the indent check, because it >> couldn't handle lines which have been broken and then indented an extra >> level. >> >> So please make sure you use the correct indenting for each file, or we >> might have to reject your pull request: >> https://github.com/zanata/zanata-server/wiki/Coding-Guide >> >> >> Important note >> -------------- >> >> >> If you have any outstanding branches/pull requests for zanata-server: >> >> To minimise conflicts when merging, don't reformat your changes right >> away. Please use this procedure in your feature branch: >> >> >> $ git fetch >> >> # VERY, VERY IMPORTANT: merge everything *before* the reformat >> $ git merge 4bcf574b8a^ >> >> # Now, merge the reformat itself, but ignore reformatting where it conflicts >> $ git merge 4bcf574b8a -s recursive -X ours > > The above step is more dangerous than I thought - when reformatting is > involved git sometimes fails to detect semantic conflicts. (In one case > this led to two identical fields, and one missing field.) If you have > really good test coverage, this might be okay, but otherwise read on... > > If you have a small to medium change, it's probably best to do a normal > merge here, and just deal with the conflicts. The merge option > -Xignore-all-space should cut down on the conflicts here. Correction: use "-Xignore-space-change", not -Xignore-all-space > If you have a larger change, you could try the recursive/ours merge, but > then replace your modified files using the first merge node above > ("Merge from '4bcf574b8a^'"). It's a bit error-prone, so I would > recommend the other option if possible. > > Either way, I hope the code you changed has good test coverage! > >> >> # NB: At this point, use your IDE to reformat your *modified* files >> only! Please inspect the result visually. >> >> # optional: >> $ git merge origin/master >> >> # finally: >> $ git push your feature branch >> >> Then we will review the merge to make sure it looks okay. >> >> Let me know if that procedure doesn't work for you, and we'll sort >> something out. >> >> Sean. >> >> >> PS if you want to review your changes across branches more easily, try this: >> >> git config --global alias.wdiff "diff --color-words --ignore-all-space" >> >> This creates a new "git wdiff" command which ignores whitespace. >> >> > > -- Sean Flanigan Senior Software Engineer Engineering - Internationalisation Red Hat -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 295 bytes Desc: OpenPGP digital signature URL: From sflaniga at redhat.com Tue Oct 22 23:26:12 2013 From: sflaniga at redhat.com (Sean Flanigan) Date: Wed, 23 Oct 2013 09:26:12 +1000 Subject: [zanata-devel] Fwd: XOM update from version 1.0 to 1.2.10 In-Reply-To: <5266A3FA.7070802@redhat.com> References: <5266A3FA.7070802@redhat.com> Message-ID: <52670994.4070805@redhat.com> Being able to use XOM 1.2 (and org.zanata.xml.StreamSerializer) in the client sounds good to me! -------- Original Message -------- Subject: XOM update from version 1.0 to 1.2.10 Date: Tue, 22 Oct 2013 18:12:42 +0200 From: Mikolaj Izdebski To: eucalyptus-owner at fedoraproject.org, json-lib-owner at fedoraproject.org, maven-eclipse-plugin-owner at fedoraproject.org, owasp-esapi-java-owner at fedoraproject.org, saxon-owner at fedoraproject.org, wildfly-owner at fedoraproject.org, zanata-common-owner at fedoraproject.org Next week I am probably going to update XOM to latest upstream version [1]. It can possibly be backwards-incompatible. If you have any objections or comments please comment in the bug. Packages that directly depend on XOM: eucalyptus json-lib maven-eclipse-plugin owasp-esapi-java saxon wildfly zanata-common [1] https://bugzilla.redhat.com/show_bug.cgi?id=977551 -- Mikolaj Izdebski IRC: mizdebsk -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 295 bytes Desc: OpenPGP digital signature URL: