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>
Since some systems have a /tmp autocleaner, we don't want to trust
our gitweb configuration file to stay there. Instead keep it with
the extracted WARs inside of our own private temporary location.
Change-Id: I5f4dea46a755bf3296f15ae38361452fe8df6655
Signed-off-by: Shawn O. Pearce <sop@google.com>
On case insensitive filesystems like Mac OS X's HFS+ or Windows NTFS
if Gerrit is started out of the classes directory through an IDE
debugger we would find "daemon.class" on disk and try to load it,
but the JVM refuses because "daemon" is not the actual class name,
its "Daemon". Meanwhile running out of a JAR or on Linux always
works, because the JAR and ext2/3/4 are case sensitive.
Flip the order of operations around and try the Titlecase form of
the command name first. Its more likely going to be a match for
a Java classname, since developers name classes in CamelCaseFormat.
Bug: issue 490
Change-Id: I43a487eb0d5d528ac370e1794a4542e412236307
Signed-off-by: Shawn O. Pearce <sop@google.com>
This class used to be in the default package (and thus had no
package statement), but then we moved it into a package and Eclipse
inserted the package statement before our standard copyright header.
Change-Id: I342e8d6466a7a9b1b466f8f971df7598448038c8
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>
Ian Wienand