Having a standard tool for formatting saves reviewers' valuable time.
google-java-format is Google's standard formatter and is somewhat
inspired by gofmt[1]. This commit formats everything using
google-java-format version 1.2.
The downside of this one-off formatting is breaking blame. This can be
somewhat hacked around with a tool like git-hyper-blame[2], but it's
definitely not optimal until/unless this kind of feature makes its way
to git core.
Not in this change:
* Tool support, e.g. Eclipse. The command must be run manually [3].
* Documentation of best practice, e.g. new 100-column default.
[1] https://talks.golang.org/2015/gofmt-en.slide#3
[2] https://commondatastorage.googleapis.com/chrome-infra-docs/flat/depot_tools/docs/html/git-hyper-blame.html
[3] git ls-files | grep java$ | xargs google-java-format -i
Change-Id: Id5f3c6de95ce0b68b41f0a478b5c99a93675aaa3
Signed-off-by: David Pursehouse <dpursehouse@collab.net>
This is a preparation change to activate Error Prone for Buck driven
build. This fix is needed, otherwise the compilation is failing with:
Source option 1.2 is no longer supported. Use 1.6 or later.
Target option 1.2 is no longer supported. Use 1.6 or later.
Change-Id: I1ef45eee87dec788522873cabe4612bf7ac2ef5b
Reformat the Bazel build files with the buildifier tool [1].
The style is different for Bazel files. Most notably, indentation level
is 4 spaces instead of 2, and " is used instead of '.
[1] https://github.com/bazelbuild/buildifier
Change-Id: I95c0c6f11b6d76572797853b4ebb5cee5ebd3c98
This tiny class uses a very ancient and limited API so it runs on any
JVM. Its entire purpose is to check the minimum Java version, fail if
it is too low, otherwise jump into the real class in another package.
The Maven build used to create this class for Java 1.2, so it would be
helpful to users attempting to launch Gerrit on the wrong JVM. That flag
was lost when the build moved to Buck.
Reset the source and target level to 1.2 so the warning message might
be useful again, especially during the jump from Java 6 to Java 7.
Change-Id: I9187e13ee67c9c482a8e11296649fcf712e5aad1
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
Try to reduce the size of the top-level BUCK file by moving
anything that has to do with Eclipse project generation and
classpath management into tools/eclipse.
Change-Id: Id779eaff4fe732908b28a8e3441004e364b59e21
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
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>
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>
Most of our build will want to assume the same version of each
plugin across all components, just like do with our dependencies.
Also, start populating some data into the manifest of each created
JAR file, to better document where the JAR came from.
Change-Id: I38c62949dfb0e14603a31e9045e4ab5f7ca1424b
Signed-off-by: Shawn O. Pearce <sop@google.com>
Rather than listing all of our build projects in the parent pom,
list them where they are actually required to compile.
Change-Id: I27954f3e4affdaa258ee024c0899f0cacd3f2ae4
Signed-off-by: Shawn O. Pearce <sop@google.com>
To run Gerrit Code Review we require Java 6, because our class
files are compiled against the Java 6 SDK, use methods from it,
and are in the Java 6 bytecode file format. We cannot run on a
JRE that predates the Java 6 specification.
Rather than giving users who are trying to run us on an outdated
virutal machine an obtuse stack trace like the following:
Exception in thread "main" java.lang.UnsupportedClassVersionError:
Bad version number in .class file
at java.lang.ClassLoader.defineClass1(Native Method)
...
we should give them a specific message describing the problem,
and our minimum version requirement.
To get a custom error message we compile our Main springboard class
in Java 1.2 format, against only APIs that are available since Java
1.2, and we check the specification of our runtime to verify it can
support us. This allows us to execute on a really old JRE and at
least report a descriptive error message.
In order to use Java 6 APIs in GerritLauncher we had to move it
to its own Maven component, where the runtime environment is still
described as Java 6.
Change-Id: I47bfcfb5076427d491c896a2815dd091ca205bfc
Signed-off-by: Shawn O. Pearce <sop@google.com>
We've changed so much since the 2.0.24 release that I'm really not
comfortable calling it 2.0.25.
Change-Id: I9cf28b0a97e0f74838bf893b79ce3105e0a7bfdb
Signed-off-by: Shawn O. Pearce <sop@google.com>
When we access ~/.gerritcodereview/tmp we might find out that tmp has
actually be symlinked to a different part of the local filesystem,
such as /tmp. Resolve the link as early as possible during startup so
that if ~/ is on NFS we remove our dependency on the NFS server as
early as possible and won't be impacted later on should it go down.
Change-Id: Ib631add17338c08c55dd84762dc4fd105308d7c2
Signed-off-by: Shawn O. Pearce <sop@google.com>
Jetty can serve a file directly from local disk using low-level APIs
like sendfile(), but only if the file it is reading from is actually
stored on the local filesystem. Loading it dynamically from a JAR
where its been compressed completely defeats this feature of the
DefaultServlet we are trying to take advantage of.
To enable Jetty's more optimized IO path, we now unpack our WAR
contents to our temporary directory, under the gerrit_war folder.
Change-Id: I7be7c90029720f1664bc35ae2f7ff77e247161df
Signed-off-by: Shawn O. Pearce <sop@google.com>
Some NFS based filesystems seem to have a problem deleting the
temporary directory we create to hold our JARs. Something on the
NFS server is pegging the directory open until the JVM exits,
which means we may wind up leaving an infinite number of empty
directories in ~/.gerritcodereview/tmp.
This appears to be isolated to certain NFS servers, because my local
/tmp doesn't suffer from the same problem, the temporary directory
is deleted on JVM exit.
We use a simple rule here, any empty directory with a modification
date older than 7 days is assumed to be garbage and removed.
Any directory that is non-empty can be assumed to be a running
daemon, even if it has a modification date of older than 7 days,
and is thus left alone.
Change-Id: I3d4e697863f347e66e5b142e4a7ad8e99a08956d
Signed-off-by: Shawn O. Pearce <sop@google.com>
Some operating system distributions include a cron script which
cleans /tmp by unlinking any files not modified in the past 7 days.
This can kill a running Gerrit server by deleting its JAR files,
preventing it from lazily-loading any code after the unlink occurs.
Work around this by unpacking our JARs into a directory below the
user's home directory. This matches the behavior of Hudson CI,
which also suffered from having their JARs disappear at runtime
due to these automatic /tmp cleaning scripts.
Change-Id: Ia83c65d61310658fc9afd1c663b4b3877c457a3c
Signed-off-by: Shawn O. Pearce <sop@google.com>
I've never liked having these be special cases. Lets move them to
the pgm package where they aren't special anymore.
Change-Id: Ib76fd6c7fe806b92ee5658ece4c788e67bcacdbc
Signed-off-by: Shawn O. Pearce <sop@google.com>
Instead of doing a direct System.exit() use return to return the
exit code to the caller, which is the true main method for the
application. This simplifies the calling strategy considerably.
Change-Id: I3b056579726a56bd9a1ab7186265dc5c5ebeeacc
Signed-off-by: Shawn O. Pearce <sop@google.com>
This little query tool is primarily intended for use when running an
embedded H2 database where there really is no other way to access the
in-memory files and state.
It is however handy for quick queries against any other database.
Bug: issue 327
Change-Id: I77a96c0833026d432103a16b48ec36f315c352ec
Signed-off-by: Shawn O. Pearce <sop@google.com>
The init command uses an interactive prompting process to help the
user get a basic website configured.
The --import-projects option will automatically search for and import
any Git repositories which are discovered within gerrit.basePath.
Bug: issue 323
Bug: issue 330
Change-Id: I3d6e8f9f5fea8bfc78f6dfb1fc8f284bebfba670
Signed-off-by: Shawn O. Pearce <sop@google.com>
We don't really care that the reflection based invocation of a method
failed with an InvocationTargetException, what's really relevant for
us to display is the cause of this exception.
Change-Id: Ifd6332a44c2b19b073c14b73b631210030321889
Signed-off-by: Shawn O. Pearce <sop@google.com>
Since we embedded Jetty into our WAR and automatically launch the
web server when our daemon command is invoked its no longer true that
we run only the SSH daemon. Correct this misleading description.
Change-Id: I440b1b484a43d7e9c6ba57c313fde55762dfc49e
Signed-off-by: Shawn O. Pearce <sop@google.com>
This refactoring splits the code up into different components, with
their own per-component CLASSPATH. By moving all of our classes
into isolated components we can better isolate the classpaths and
try to avoid unexpected dependency problems. It also allows us to
more clearly define which components are used by the GWT UI and
thus must be compiled under GWT, and which components are run on
the server and can therefore use more of the J2SE API.
Change-Id: I833cc22bacc5655d1c9099ed7c2b0e0a5b08855a
Signed-off-by: Shawn O. Pearce <sop@google.com>
