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>
Ian Wienand