Project settings are now saved in the project.config file of the
refs/meta/config branch within each Git repository. This offers
us free version control over the lifespan of the project, and will
help reduce schema version issues as the configuration file is
more free-form.
Project owners can edit the configuration of their project by
hand and push the results back up, possibly even going through
code review, if the proper access rules are assigned in the
project's access panel. Project users can inspect the history of
the configuration by reading the history of the refs/meta/config
branch with their favorite history browser.
Change-Id: Id63414d86dbfb9033021f76e1d5e782373525a77
Signed-off-by: Shawn O. Pearce <sop@google.com>
Declaring the same plugin twice may not be supported in future
versions of Maven. Try to prevent unexpected issues by putting
everything into one block.
Change-Id: I52e2964ed25e67010dfb04dbf8fcd69f4e68ff57
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>
When we started building gerrit-gwtdebug as a submodule, we broke
the way the Maven Eclipse plugin generated the project classpath.
Instead of the WAR, link to the JAR of each project.
Change-Id: Ie8a3723ee26c19710cac67eac79930a1ba992006
Signed-off-by: Shawn O. Pearce <sop@google.com>
We would really prefer not to mess around with the CDDL if we can
avoid it as a license. Fortunately, the Apache Tomcat project
has created a reimplementation of the javax.servlet API under the
friendly Apache License 2.0. We can use that instead of the much
more commonly used reference implementation that is supplied by
Sun Microsystems (err, now Oracle).
The Eclipse Foundation uses this for the sevlet 2.5 specification
in their Orbit repository, so its a reasonably clean source to
build from. Unfortunately Jetty's own Maven pom files request the
Sun package, so we have to be careful to ensure we excluce it.
Change-Id: I177a3e0863cf6d46e824296e2e3dc8cfb350d71e
Signed-off-by: Shawn O. Pearce <sop@google.com>
This way the documentation for that release is embedded within the
WAR and can be served directly from the servlet container that is
running Gerrit Code Review itself. This should make it easier to
look up the relevant information from a running installation.
The documentation menu is only installed in the UI if the server
has the "Documentation/" subdirectory within the servlet context.
This should be true if the server was packaged with our release
script, but otherwise would be false as its not there.
Its probably more GWT-ey to use some sort of build parameter in
the module definition to enable or disable this menu creation
code at compile time, allowing GWT to strip out the resources and
JavaScript if the documentation wasn't available at build time.
But this is far too complex for our needs. The documentation is
most likely going to be present, and its only a handful of bytes
for the strings. Any minor savings resulting from being able to
strip this code out just isn't worth the additional code complexity.
Change-Id: Ib2be63cf99fa20ff427ab811ab25d5e9e8a6b21f
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>
SchemaVersion subclasses form a DAG, managed by Guice, chaining the
current schema version to its immediate predecessor. When a version
is selected, we try to upgrade to it by first asking is predecessor
to validate (and upgrade).
Drops of schema elements are not performed automatically, but instead
are printed to the console so the administrator can verify the drops
aren't their own private schema elements, and execute the commands
they know won't damage their own private data.
Change-Id: I2a53749ca23432da2a9b1866203aafb151b48aab
Signed-off-by: Shawn O. Pearce <sop@google.com>
We now load our database settings in hosted development mode from
the $site_path/etc/gerrit.config, just like we would under daemon.
This reduces the number of weird configurations that are supported.
Change-Id: I0a13f16dd74bdb034d05650eadd5e36771109f3e
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 now automatically create the database indexes during schema
creation by parsing our own index creation script(s) and doing
their raw SQL commands one at a time on the underlying database.
To simplify setup we now only perform this work inside of init,
and no longer do it implicitly when the WAR is loaded inside of
a servlet container.
Bug: issue 343
Change-Id: I0b37d7e75d75402a3854bb3751c642dec7897940
Signed-off-by: Shawn O. Pearce <sop@google.com>
Instead of mingling our resource files alongside of our Java source
code, move them into the src/main/resources directory where Maven
normally expects them to be.
We only move the resources which actually have to appear at runtime
in our CLASSPATH, which means we can omit the GWT message files and
linker scripts (*.gwt.xml) from the resource directory.
Change-Id: I18c573501f4d60ced35a247fb6ef6a056f774b1c
Signed-off-by: Shawn O. Pearce <sop@google.com>
In the 2.1 series we're strongly encouring everyone to switch
to using our embedded Jetty container (under our daemon command)
rather than installing and running their own external Jetty process.
It vastly simplifies the installation and maintenance of upgrades.
Also, Jetty 6.x is already (or very close to) being end-of-lifed.
The entire Jetty project moved to the Eclipes Foundation and
rewrote their package namespace during the 7.x release cycle.
A stable 7.x has already been released, and we're embedding it in
our daemon command. So users who absolutely want to run their own
external Jetty container should just run Jetty 7 and use our jetty7
support scripts instead.
Change-Id: I4981549e2ece146d49c2b1b6c5d9933e9d7d0419
Signed-off-by: Shawn O. Pearce <sop@google.com>
These upgrade scripts were necessary to upgrade databases in the
2.0.x code series. Given how major of a release 2.1 is, I'm just
whacking them out of the repository and archiving them for historical
purposes on our download page.
http://gerrit.googlecode.com/files/schema-upgrades003_019.zip
In the 2.1.x series we plan to handle schema upgrades more
automatically, within our application code, rather than making
a site administrator run the upgrades by hand.
Change-Id: I8913317a1d7350ea40ea5193cc6a938e3eb08638
Signed-off-by: Shawn O. Pearce <sop@google.com>
Disable the automatic update check for Ehcache. Because the library
is embedded in the Gerrit distribution our users are not likely to
update it on their own. Letting them know there is a new version
at server startup does not help them.
Change-Id: If10710db723b5bb2e32478d8526e649f200d781e
Signed-off-by: Shawn O. Pearce <sop@google.com>
Minor typo on the test, we need to use -a and not && to perform
multiple compare operations in one test invocation.
We can't use " & ;" in Bourne shell, the ; is unexpected.
Allow START_STOP_DAEMON and NO_START to be inherited in from the
environment, but also pulled from /etc/default/gerritcodereview
if the administrator wants to override it.
Change-Id: I8658b5ebcd6fad7bc008362e941f89e4b2b363aa
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>
Don't display the date and time of the startup when we aren't using
start-stop-daemon, its weird. Instead display just OK.
Change-Id: Ic72b397e0523e0e21417e39f8dab80f52ddc7302
Signed-off-by: Shawn O. Pearce <sop@google.com>
If start-stop-daemon isn't available on this system, and we are
not running as root, run as the current user. This avoids the
failure caused by su denying access to the root account.
If $UID isn't defined by /bin/sh (its a GNU bash extension), we
now initialize it to the current user id, from `id -u`. This is
supposedly part of the POSIX standard and should be available on
all systems.
Change-Id: Ia17b360c9e6384c5e2425a85e389d65910fc0ba8
Signed-off-by: Shawn O. Pearce <sop@google.com>
Mac OS X's /bin/sh does not support echo -n. Instead use the much
more widely supported printf with a format string of just %s.
Change-Id: I77ac99e7fff7432e3eaf663284e8b2950239ff88
Signed-off-by: Shawn O. Pearce <sop@google.com>
On Mac OS X (aka Darwin) and some versions of Linux, /bin/sh does
not support ulimit -x. Ignore any errors trying to adjust that
particular resource usage limit.
Change-Id: Ib419c53e23ec904e1215b0541ba0f5bb9e029791
Signed-off-by: Shawn O. Pearce <sop@google.com>
Our startup script is extracted into $site_path/bin/gerrit.sh so
administrators can easily link to it in their /etc/rc.d management.
This script is based heavily upon the jetty.sh that comes in
any Jetty distribution, so we're opting to relicense it under the
Apache License version 2.0, rather than the Eclipse Public License.
Most of the script is intact, but I've certainly butchered and
reworked some parts that were really Jetty specific.
If /usr/bin/perl is available (these days it is on most systems) we
use that to launch the JVM rather than the shell. This allows us to
force the process name as reported by ps to be 'GerritCodeReview'
rather than '/usr/bin/java', which can really help to nail down
which JVM is your Gerrit daemon. If perl isn't found we stick the
unused system property -DGerritCodeReview=1 as early in the command
line as we can, to help ps challenged systems to still identify us.
We store the pid file for our running daemon in $site_path/logs,
rather than /tmp or /var/tmp, so its easier to locate and match to
a specific site path installation.
During `gerrit init` we try to capture the relevant parameters to
locate the JRE and gerrit.war and stuff them into gerrit.config so
the start script can find them later on. Adminstrators can always
adjust these later on if necessary.
If git isn't available to read the gerrit.config with during startup
we use a crude but workable configuration parser written entirely
in Bourne shell. It should be just good enough to scan through the
gerrit.config and pull out container.javaHome and container.war,
which is about all we need to boot ourselves.
Change-Id: I52872b1acffc22e80c5fd33fd6df0e152bc96cff
Signed-off-by: Shawn O. Pearce <sop@google.com>
We specifically install the ChannelDirectTcpip channel factory
so that the daemon understands this protocol feature but our
TcpIpForwardFilter automatically rejects all connection attempts made
by a client. This will cause nice error messages to be reported
back, letting the user know their port forwarding was denied,
rather than generating an obtuse error message in the client.
Even if we skipped the ChannelDirectTcpip session factory we must
install the TcpIpForwardFilter. If we don't MINA SSHD would permit
any client to listen for inbound connections on any of our local
ports and redirect them to the client's own server of choice.
We also now specifically configure the subsystem list to be empty.
This is to disable any SFTP support inherited from MINA SSHD,
we actually don't want to service SFTP for anything at this time.
We might consider enabling SFTP off the same virtual filesystem we
use for scp, but its not a very important feature.
Bug: issue 336
Change-Id: I7a64601524ca84f308b76357290c456dc4613b67
Signed-off-by: Shawn O. Pearce <sop@google.com>
We now save daemon log files into $site_path/logs, rolling over
once per day using the DailyRollingFileAppender class from log4j.
Current messages are written to $site_path/logs/error_log until the
end of a day is reached in GMT, and then its renamed to an archive
file suffixed with the 'yyyy-mm-dd' format.
Because the daemon is meant to run in the background and service
user requests, the log messages are automatically redirect to the
log file by default. An administrator can force us to send log
messages to stderr again by using the new option --console-log.
Bug: issue 328
Change-Id: I6add1d2ac8faf57c6ca17964a7e88a2afacfb094
Signed-off-by: Shawn O. Pearce <sop@google.com>
Instead of relying on the horribly ugly GerritServer.properties we
now configure the database out of gerrit.config through database.*
configuration settings.
Change-Id: I34734ebe880181480cf149d664368c8e7e469bef
Signed-off-by: Shawn O. Pearce <sop@google.com>
We now include Jetty 7.x as part of our distribution WAR and allow
administrators to launch the embedded copy using our Daemon command
line program. This vastly simplifies server installation as you
do not need to download the Jetty servlet container and configure
it prior to using Gerrit Code Review.
Configuration of Jetty is performed using our gerrit.config, rather
than the Jetty XML configuration language. Jetty's language can be
quite a bit more powerful for isoteric configurations, but we want
to embed Jetty to simplify setup, not complicate it. Gerrit's own
configuration file in the git syntax is simpler, so we stick with
that and offer a limited subset of Jetty's configuration features
through httpd.* properties.
Logging currently goes only to stderr, which is fine for toy setups
but probably not ideal for a production environment.
Unfortunately we are still relying on GerritServer.properties to
get us the database connection information, and this DataSource is
not pooled. Thus the web handlers in our embedded container will
run slightly slower then the web handlers in a standalone container,
as the latter will be likely be using a connection pool configured
out of the container's JNDI namespace.
Bug: issue 202
Change-Id: Ia7956ba48cbc3a8d4241101db5ff493e16d26b9f
Signed-off-by: Shawn O. Pearce <sop@google.com>
These two databases are somewhat popular for a Gerrit installation,
and their drivers don't take up that much space. We might as well
include them, along with commons-dbcp and commons-pool, so there
is less to download and install when setting up a new Gerrit server.
Change-Id: I389d5b5d7aa8fdb03460193bcba834fe74a9bb61
Signed-off-by: Shawn O. Pearce <sop@google.com>
Instead of enumerating the startup/shutdown sequence inside of the
WebAppInitializer we now use listeners which are bound and managed
by Guice. The listeners are fired in the order they are registered
within the injector modules.
By using Guice we are more easily able to track the need to start
(or gracefully stop) a component alongside its explicit binding
in the injector. We can also conditionally include start or stop
rules by controlling which modules are included in the injection.
Change-Id: I93590c666d46e13fdce9aa05100489f9f6d94615
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