GWT only needs the rebind code for CSS and ServerLinker to be
precompiled as bytecode. Save build time by passing no source
files to the java_library() used by gwt_module().
For a full draft build of ui_safari this cuts the refresh time
down from 32.015s to 26.158s on my MacBook. Saving 6s on each
UI reload adds up during development.
The common annotations need to be provided as bytecode, avoiding
spurious warnings from GWT when there is a Java syntax error.
Change-Id: I37826498650c65c05303e7d4d1177d05781c56f6
Updated version of prettify: in addition to adding new syntax
highlighters, it appears to run much better in IE versions >8.
This would manifest as an unhandled JavaScript exception.
Additionally, formatting appeared to not work well in IE standards
mode and Safari because the @media selector was getting mangled
by GWT. This was fixed in an update to GWT 2.5.1.
Change-Id: Idcc095dac1007c6794e9f67fa12a92b01695d5cf
* stable-2.7:
Fix: NullPointerException of dashboard title
Properly handle double click on external group in GroupTable
Add plugin repositories section in the pom
PrettyFormatter: Fix expand tab when syntax coloring is on.
* stable-2.6:
Fix: NullPointerException of dashboard title
Properly handle double click on external group in GroupTable
Add plugin repositories section in the pom
PrettyFormatter: Fix expand tab when syntax coloring is on.
* stable-2.7:
PrettyFormatter: Fix ArrayIndexOutOfBoundException with CRLF files.
Allow administrators to see all groups
Correct URL encoding with REST API
prettify lost support for expanding tabs in r143 [1]. As a consequence,
tab width preference is no longer honored.
Gerrit now handles expanding tabs by itself in all cases, even if syntax
coloring is active.
[1] http://code.google.com/p/google-code-prettify/source/detail?r=143
Bug: issue 1872
Change-Id: I283a3620b1d130d3f66e56d3f202a5122d7a73b8
Change I6d82ce322d401743a8de5ab8090b2adc43a909f5 added a workaround for
a bug in prettify, by temporarily adding a space before each \n
character.
For files with CRLF line endings, this means replacing "\r\n" by
"\r<space>\n", which prettify sees as two lines. This leads to a
crash since Gerrit expects a consistent number of lines even after
prettify.
When Show Line Endings is active, the issue does not appear since \r
are replaced with a specific markup, without any actual \r.
Change-Id: I345e332225e449c6f26871476f1a07e67458da59
The Maven build does not work since the introduction of CodeMirror.
Remove the build until to prevent people from trying to use a broken
build process. If buck is rejected this commit will be reverted, and
we will attempt to fix the Maven build to include CodeMirror. If buck
is accepted, we just saved time by avoiding a messy Maven change.
Change-Id: I147d8d1741d52f59de1d2ddce8e5e82583990c14
Implement a new build system using Buck[1], Facebook's
open source clone of Google's internal build system.
Pros:
- Concise build language
- Test and build output is concise
- Test failures and stack traces show on terminal
- Reliable incrementals; clean is unnecessary
- Extensible with simple blocks of Python
- Fast
buck: clean: 0.452s, full 1m21.083s [*], no-op: 7.145s,
mvn: clean: 4.596s, full 2m53.776s, no-op: 59.108s,
[*] full build includes downloading all dependencies,
time can vary due to remote server performance.
Cons:
- No Windows support
- No native Maven Central support (added by macros)
- No native GWT, Prolog, or WAR support (added by macros)
- Bootstrap of buck requires Ant
Getting started:
git clone https://gerrit.googlesource.com/buck
cd buck
ant
Mac OS X:
PATH="`pwd`/bin:/System/Library/Frameworks/JavaVM.framework/Versions/Current/Commands:$PATH"
Linux:
PATH="`pwd`/bin:$PATH"
Importing into Eclipse:
$ time buck build :eclipse
0m48.949s
Import existing project from `pwd`
Import 'gerrit' (do not import other Maven based projects)
Expand 'gerrit'
Right click 'buck-out' > Properties
Under Attributes check 'Derived'
If the code doesn't currently compile but an updated classpath
is needed, refresh the configs and obtain missing JARs:
$ buck build :eclipse_project :download
Running JUnit tests:
$ time buck test --all -e slow # skip slow tests
0m19.320s
$ time buck test --all # includes acceptance tests
5m17.517s
Building WAR:
$ buck build :gerrit
$ java -jar buck-out/gen/gerrit.war
Building release:
$ buck test --all && buck build :api :release
$ java -jar buck-out/gen/release.war
$ ls -lh buck-out/gen/{extension,plugin}-api.jar
Downloading dependencies:
Dependencies are normally downloaded automatically, but Buck can
inspect its graph and download missing dependencies so future
compiles can run without the network:
$ buck build :download
[1] http://facebook.github.io/buck/
Change-Id: I40853b108bd8e153cefa0896a5280a9a5ff81655
This cleans up a weird dependency in the build tree for any Buck based
build. Most of these classes are meant only to be compiled for GWT and
do not build at the server side. Maven allowed sloppy use of gwt-user,
making it difficult to identify this earlier.
Change-Id: Id86e74f2f0760c9853829483899379353e5ada13
Change I34fb07f incorrectly "fixed" the brackets in the `toString`
method, however the usage of [ and ) was intentional, to denote that
the range is inclusive/exclusive.
Add a short comment in the method to prevent the same mistake from
being made again.
Change-Id: Idfe9b560c0cc55bfa4a6ab06fba172d971c3089c
This reverts commit 17daae9934941bc6db6b372a04433f19186d5972
The use of ) was intentional as the range is inclusive, exclusive.
Change-Id: I1aa25b6d8a17a374766c6316ee1872c4272e609e
Inserting "<lf>\n" doesn't work. Prettify leaves the <lf> but
often inserts a <span> tag between <lf> and \n leaving a very
deep tag stack for the DOM to handle. This is really slow to
render and can cause mis-rendering.
Insert a space before LF. Most prettify styles will treat this
as the same as the LF, allowing the trailing space to be removed
before splitting by line.
Change-Id: I85d12c590a8d1bda1b1b66874a0dddb4628a8655
Latest prettify build appears to delete empty lines from the end of
the input file. This causes Gerrit to crash with array exceptions
because the formatted HTML is a different length then the diff
hunks indicate.
Work around the broken prettify by inserting a fake HTML tag before
each LF and removing it after formatting is complete.
Change-Id: I6d82ce322d401743a8de5ab8090b2adc43a909f5
Local copy of the JavaScript was updated to include all supported
languages:
(cd gerrit-prettify/src/main/resources/com/google/gerrit/prettify/client/;
for f in lang-*.js; do
n=$(echo $f | sed 's,-,_,; s,.js,,');
echo " @Source(\"$f\") TextResource $n();";
done) >gerrit-prettify/src/main/java/com/google/gerrit/prettify/client/Resources.java
prettify no longer uses <br> for line breaks. It now inserts only
an LF. This requires the post-processing parsing step to be updated
and break on LF or HTML tags.
Bug: issue 1155
Change-Id: I09c199f568a4579804790f7fa1548473419d14c2
In some cases displaying the intraline diff fails with an exception like
this:
java.lang.ArrayIndexOutOfBoundsException: Array index out of range: 10
at com.google.gerrit.prettify.common.SparseFileContent.mapIndexToLine(SparseFileContent.java:149)
at com.google.gerrit.prettify.common.PrettyFormatter.format(PrettyFormatter.java:188)
at com.google.gerrit.client.patches.AbstractPatchContentTable.getSparseHtmlFileB(AbstractPatchContentTable.java:287)
at com.google.gerrit.client.patches.SideBySideTable.render(SideBySideTable.java:113)
at com.google.gerrit.client.patches.AbstractPatchContentTable.display(AbstractPatchContentTable.java:238)
at com.google.gerrit.client.patches.PatchScreen.onResult(PatchScreen.java:444)
...
This happens when the old line is:
foo-old<LF>
and the new line is:
foo-new<CRLF>
The computed intraline diff that should be highlighted for the new file
will be 'new<CR>'. To do the highlighting 'span' tags are inserted
which separates <CR> and <LF> for the new file. The prettify parser now
replaces both with a 'br' tag. Since the number of 'br' tags is
expected to match the number of lines and we now have one 'br' too much
we run into the ArrayIndexOutOfBoundsException when looking up the lines.
Avoid this problem by removing <CR> from the intraline diff before
running the prettify parser.
Bug: issue 1759
Change-Id: I738b1c780116b890d8db8bb0ab795c6b2b72128d
Signed-off-by: Edwin Kempin <edwin.kempin@sap.com>
This fixes two ArrayIndexOutOfBoundsException's that can occur when
navigating from one patch to the next/previous patch if the
next/previous patch is a newly added binary file.
1. if the user is not signed in:
java.lang.ArrayIndexOutOfBoundsException: Array index out of range: 0
at com.google.gerrit.prettify.common.SparseFileContent.get(SparseFileContent.java:74)
at com.google.gerrit.prettify.common.PrettyFormatter.colorLineEdits(PrettyFormatter.java:381)
at com.google.gerrit.prettify.common.PrettyFormatter.toHTML(PrettyFormatter.java:315)
at com.google.gerrit.prettify.common.PrettyFormatter.format(PrettyFormatter.java:129)
at com.google.gerrit.client.patches.AbstractPatchContentTable.getSparseHtmlFileB(AbstractPatchContentTable.java:201)
at com.google.gerrit.client.patches.UnifiedDiffTable.render(UnifiedDiffTable.java:99)
...
2. if the user is signed in and has 'Syntax Coloring' in the preferences enabled:
java.lang.ArrayIndexOutOfBoundsException: Array index out of range: 0
at com.google.gerrit.prettify.common.SparseFileContent.get(SparseFileContent.java:74)
at com.google.gerrit.prettify.common.PrettyFormatter.toHTML(PrettyFormatter.java:319)
at com.google.gerrit.prettify.common.PrettyFormatter.format(PrettyFormatter.java:129)
at com.google.gerrit.client.patches.AbstractPatchContentTable.getSparseHtmlFileB(AbstractPatchContentTable.java:201)
at com.google.gerrit.client.patches.UnifiedDiffTable.render(UnifiedDiffTable.java:99)
...
Bug: issue 735
Change-Id: I43716b1c868e98c083b12e57b4686528634ae390
Signed-off-by: Edwin Kempin <edwin.kempin@sap.com>
Displays Windows EOL/Cr-Lf on patch diff screen. This is
optional and is controlled by a checkbox. A new column
show_line_endings is added in account_diff_preferences.
Display is similar to gitweb i.e. '\r' in dotted-line box
Bug: issue 626
Change-Id: I6128575bd2f0869a3c59e3d2fd409d5ee431ecc5
Eclipse overwrites these files when we import projects using m2e.
Eclipse 3 writes a timestamp at the top of these files making the Git
working tree dirty. Eclipse 4 (Juno) still overwrites these files but
doesn't write the timestamp. This should help keeping the working tree
clean. However, since the timestamp is currently present in these
files, Eclispe 4 would still make them dirty by overwriting and
effectively removing the timestamp.
This change removes the timestamp from these files. This help those
using Eclipse 4 and doesn't make it worse for those still using Eclispe
3.
Change-Id: Ic23299a12ac80f7294bcc602c8565889069a0d10
Signed-off-by: Sasa Zivkov <sasa.zivkov@sap.com>
The 2.3 was released and what we have in the master branch
is targeted for 2.4.
Change-Id: Idca8a12aaef1dc5ea5f628b3640881e66f04dc9c
Signed-off-by: Sasa Zivkov <sasa.zivkov@sap.com>
Refactored the GWT client code to include only what the gerrit GWT
client. The gerrit GWT build was giving build warnings since the
getAsync() signature and implementation used types that were
not available to GWT.
Split the reviewdb into a client and server package.
Organized the imports to ease the migration.
Change-Id: I6cd6125eddcb1dd2b5c5e353edf163544248026b
Don't show '... skipping 1 common line ...'. The text to show this
takes up just as much space as showing the line which was skipped.
Issue: 981
Change-Id: If86eb27dd6734a6826a9ceb379920c7c1d5e4692
We don't push our code to a Maven repository, so there only reason
to construct source archives is to feed source files into the GWT
compiler. Move the source plugin onto only the packages that we
feed into the GWT code, allowing the others to skip this step.
This fixes a "bug" in a later change that adds the Prolog Cafe
translater to the build process. Without this change first, the
Prolog Cafe translator is firing twice for every Prolog source file
that is part of our standard build.
Change-Id: Iba38aa371ce7c8950ac30dc3cf06e01b465afb5a
Signed-off-by: Shawn O. Pearce <sop@google.com>
I meant to keep reusing the 2.1 version number for the entire
2.1 series during development, but botched it during the 2.1.4
development cycle and set it to 2.1.4-SNAPSHOT by mistake. Put
it back to 2.1-SNAPSHOT since 2.1.4 is released.
Change-Id: I37e206c0609bf3fd94a5aab8ea301c98b7fb013e
Signed-off-by: Shawn O. Pearce <sop@google.com>
There was some code duplication in these classes. This refactoring
removes the PatchScriptSettings and PrettySettings classes and uses
AccountDiffPreference instead.
Issue: bug 629
Change-Id: I57ab1522b0023503d0cbd29620236ea68b7717ed
Signed-off-by: Sasa Zivkov <zivkov@gmail.com>
On IE6 or IE8 we can't abuse an IFrame quite the same way as we
do on Mozilla, WebKit and Opera. IE requires us to initialize the
iframe by running a script that exports the iframe window back to
the parent before we can use its eval method.
Change-Id: Ia5e01a611ed9685a5fc5341a3f8a2446f7dcb9f4
Signed-off-by: Shawn O. Pearce <sop@google.com>
The prettify symbol 'PR' at the top level window object may conflict
with a name created by the optimized GWT compiler, resulting in
conflicting ideas about what the PR name really is and causing
crashes in particular browsers.
Move prettify into its own iframe, where it has its own top level
window object, and thus has its own isolated namespace.
Change-Id: I30523854067eb33250810e9d2f7e23b4c691541f
Signed-off-by: Shawn O. Pearce <sop@google.com>
Prettify converts a bare CR in the middle of a line of text into a
<br/>, which we later convert back into an LF. This skews all of the
line numbers through the rest of the file, resulting in a confusing
situation (due to the unexpected LF) as we try to map the formatted
HTML back into the SparseFileContent object we use for rendering.
Highlight bare CRs as spaces with whitespace error spans around them,
before we feed the text into prettify. This ensures we won't get
back more lines than we fed in, so our formatting is still correct.
Change-Id: Ib2dc8b024a2211601a588fd0552c4963d5b6e028
Signed-off-by: Shawn O. Pearce <sop@google.com>
If syntax highlighting is enabled the visual tab markers might adopt
the surrounding code's coloring due to prettify pushing its own CSS
class inside of our vt span. Override all of the prettify classes
when inside of a vt span with our own concept of the correct color.
Change-Id: I15ed9eb7348d5c4fb26f98332caed0194c6daefe
Signed-off-by: Shawn O. Pearce <sop@google.com>
The parent commit should have included these new files, it references
them to pick up the translated strings for the tooltips.
Change-Id: I907436eeb9f717d6aed17757304e461fe888187c
Signed-off-by: Shawn O. Pearce <sop@google.com>
Sometime users are confused about why Gerrit shows a particular part
of the new file (which is always green) in red. Its a whitespace
error, a case that isn't normal. Explain it with a tooltip message.
Change-Id: Ide90f14c4a25eac5a2bcb1bc9f5e6d67e9ac4cb7
Signed-off-by: Shawn O. Pearce <sop@google.com>
Inserting the HTML entity confused the prettify engine when we were
running in debug hosted mode. Instead of the Unicode character we
expected, we got an ASCII "W".
Use the actual character in the source code rather than the entity,
this should reduce the risk that the prettify engine or the browser
will become confused and misrender it.
Also correct the coloring, now that its a real character prettify is
converting it into a class named 'pun', which is contained within
the 'vt' class we created. But if syntax highlighting is off that
'pun' class doesn't exist, so we need CSS selectors for both cases.
Change-Id: I8ac03bf00cd4493ea53dcf3573cc2ba92455dfbf
Signed-off-by: Shawn O. Pearce <sop@google.com>
