After the Eclipse settings were changed to be compatible with the Eclipse
3.7 and the m2e (commit: a68b89fd533e5beb7ed71fa198ac543fb3e81cfb) the full
name of the MAVEN2_CLASSPATH_CONTAINER wasn't updated. This broke the
gwtui_dbg.launch configuration as no maven dependecies were found any more.
Launching this configuration would fail with the
java.lang.NoClassDefFoundError: com/google/gwt/dev/DevMode
Change-Id: I6040d856dbe1880db47dc6a6e68063cebba722e4
Signed-off-by: Sasa Zivkov <zivkov@gmail.com>
We need the Maven generated classes directory on our classpath,
otherwise the keyapplet_jar text resource isn't available.
Change-Id: Ic68ce1dd80816f2a288fd830f7dfa4db3157a8c2
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>
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>
By executing prettify over the entire file contents, rather than
on a single line at a time, we can be certain that multi-line
comments and strings are rendered correctly all of the time, even
if it starts or ends within a hidden context region.
With this change we move prettify to run only on the server, within
the Mozilla Rhino JavaScript engine, and send to the client only
fully formatted HTML line arrays for the two files. Like before,
the server only sends partial arrays, letting the client piece it
all together at display time.
In a future commit I plan to have the client format the file if we
are showing all lines from both sides. This way the RPC response
payload is smaller, and the server can offload the parsing and
formatting load to some clients.
While writing this change I considered using Pygments running inside
of Jython, but chose to stick with prettify in Rhino. Pygments ran
much slower for the same small file contents, and doesn't leave us
with the option to execute formatting on the client side.
As part of this change we now use the Mozilla chardet library to
detect the character set of the file contents we are about to render
as HTML. The chardet library is the same logic used inside of the
Mozilla browser family to detect the character set when it isn't
specified... so its pretty accurate for a wide range of files.
In the future we should also start to honor .gitattributes to get
the encoding.
Bug: issue 250
Bug: issue 251
Change-Id: I155bb7abc560f01a3597b3be678a76a5aa7f9e68
Signed-off-by: Shawn O. Pearce <sop@google.com>
* master:
Fix reading the $site_path/etc/ssh_host_key in serialized form
Never compress a pid file under $site_path/logs
Clean up the DWIMery for database.* configuration settings
Completely remove GerritServer.properties
Fix duplicate branches showing in the Branches tab
Refactor GitRepositoryManager to be an interface
Conflicts:
tools/gwtui_dbg.launch
tools/gwtui_mac.launch
Change-Id: If50811015fa24804013338fa4261fc347c2a8812
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>
Unfortunately GWT now requires the gwt.codesvr query parameter in the
URL anytime we load our host page with GWT code in it. To ensure it
is always present we save it into a cookie during startup and redirect
back to ourselves with the parameter added back into the URL if it was
not already present.
Since this block of JavaScript isn't needed in production we strip it
out of the host page unless our magical system property has been set
to true indicating we were launched through our debug launcher.
We also no longer strongly name the nocache file if we are in the
GWT development mode.
Change-Id: Ia7a91f66e21088ba269410d76461fe0be4480825
Signed-off-by: Shawn O. Pearce <sop@google.com>
Rather than having 3 commands for a human to type in by hand,
lets wrap it all up into a tiny shell script.
Change-Id: I967416266e7cde3a2a5ae567bdc4524c874b4a34
Signed-off-by: Shawn O. Pearce <sop@google.com>
Leave the git describe output as-is when creating the version
string, so the JAR file names match the name we show in the
web UI or in the output of `java -jar gerrit.war version`.
Change-Id: I643d95e698af926b13f233ae8b117a471a536fe0
Signed-off-by: Shawn O. Pearce <sop@google.com>
Our documentation suggests creating the test site in ../test_site
and says pgm_daemon runs that. So actually run that.
Change-Id: I9edd0b9b8a7b83f4cb68662575fb128bed6d1aed
Signed-off-by: Shawn O. Pearce <sop@google.com>
This only existed for developers to bundle their WAR and move
it into their external Jetty container for testing. Now that
we have our own internal daemon, we really prefer this for any
development work because its self-contained and starts up faster.
Its also implemented by Jetty and is easier to upgrade, making it
more likely we'll be running current stable, patched code.
Change-Id: I00ce142c9ca1009ff49e3ff70f3c977d3c50866e
Signed-off-by: Shawn O. Pearce <sop@google.com>
We now can launch the daemon correctly from within the Eclipse debugger
without having to switch to using the WAR in our CLASSPATH. This works
by allowing Eclipse to supply all of the CLASSPATH, but we have to go
find our WAR resource content in gerrit-gwtui/target.
Bug: 340
Change-Id: I7dfbc0654cdc10099fb3de3041e615a9fda5fdb4
Signed-off-by: Shawn O. Pearce <sop@google.com>
If a command line tool like init or daemon dies the user might want to
re-run the tool using --show-stack-trace to collect the complete trace
to include in a bug report, or use to debug the application.
Change-Id: I166699004642970c1424b0be6ca9f22f766e5f80
Signed-off-by: Shawn O. Pearce <sop@google.com>
Since we started loading our DataSource from gerrit.config we no longer
read GerritServer.properties in the daemon code path and thus do not
need this system property to be defined when launching the program.
Change-Id: I89387cbc2421a61c512f7d13f6e0bc663e7f2688
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>
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>
