Because of missing export for gerrit-antlr artifacts in tree Gerrit
plugin cannot compile when they reference gerrit antlr classes. For
example reviewers plugin needs it. Fix by exporting these classes,
as it is already the case for other projects, like gerrit-common.
Change-Id: I9e5832310271821c1bf355841ad32ff92f60000a
* stable-2.9:
Define mvn() function only once
Add pom with meta-data for plugin projects
Add more bug-fixes to 2.9 release notes
No pom.xml in gerrit-plugin-gwtui to update
Conflicts:
tools/version.py
Change-Id: I653f71d4203d516a8b8e35bebbb23b7534e433ee
These pom files are needed to be able to upload the plugin artifacts
to Maven Central.
Change-Id: I7c812538a4c2ddf684c0b6696fb7efc0a42002e4
Signed-off-by: Edwin Kempin <edwin.kempin@sap.com>
In new buck version `$SRCDIR` is not necessary any more. Buck now
always runs genrule relative to the $SRCDIR link forest.
Change-Id: Iee88bb575c7baa62bc087527927be5347a7f8f95
GWT only needs the rebind code for CSS and ServerLinker to be
precompiled as bytecode. Save build time by passing no source
files to the java_library() used by gwt_module().
For a full draft build of ui_safari this cuts the refresh time
down from 32.015s to 26.158s on my MacBook. Saving 6s on each
UI reload adds up during development.
The common annotations need to be provided as bytecode, avoiding
spurious warnings from GWT when there is a Java syntax error.
Change-Id: I37826498650c65c05303e7d4d1177d05781c56f6
Buck changed export_deps from a boolean to be exported_deps, a list of
dependencies that are to be added to deps and also exported. This
allows libraries to have dependencies for implementation use only, but
not expose them to callers for linkage.
exported_deps aren't transparently transitive anymore. This mostly
impacts the plugin-api:lib rule.
This is the first time Gerrit is using upstream Buck with no patches.
- Java memory settings for Buck can now be supplied in a project
specific file using `.buckjavaargs` in the root directory. The file
replaces the `.buckrc` previously supported by Gerrit's fork.
- Temporary directories for java_application() invoked from genrule()
is now supplied as part of the arguments using $TMP. This removes
one of the patches Gerrit had for Buck.
- Unit tests use the system temporary directory during testing. This
can be faster if the temporary directory is a tmpfs. Unfortunately
not all passing tests clean up after themselves, making it possible
to exhaust system memory and swap with useless tmpfs contents.
Using the system temporary directory for tests removes another patch
Gerrit had on top of Buck.
Change-Id: I3a9fe4aab0a33a8673df727e618122027a742638
The plugin api moved into the gerrit-plugin-api package.
Change the reference created by gerrit_plugin() to match.
Change-Id: I390a22f512835847367ae2993a7a9bddf9d11b5c
buck build api
generates now javadocs.
buck build api_install
installs all plugin/extension related artifacts with javadocs in the
local Maven repository.
Change-Id: Ifa6a8eb469f388e16449576ff2bff01a5dce67dd
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
Plugin has to include a class that implements
com.google.gerrit.pgm.init.InitStep and specifying
the class name into the Plugin MANIFEST.MF.
Plugin InitStep is getting instantiated using the
Gerrit PGM injector and then is able to access
the same init objects.
Example:
--------
public class InitJira implements InitStep {
private ConsoleUI ui;
@Inject
public InitJira(final ConsoleUI ui, final Section.Factory sections) {
this.ui = ui;
this.sections = sections;
}
@Override
public void run() throws Exception {
ui.header("Jira integration");
// Jira-specific init steps.
Section jira = sections.get("link", "jira");
// Jira-specific link expansions
}
}
MANIFEST.MF:
------------
Gerrit-InitStep: com.googlesource.plugins.jira.InitJira
Change-Id: I84fcb9acd6845c706961657219a14570e2060b0f
Signed-off-by: Luca Milanesio <luca.milanesio@gmail.com>
Instead of using Ehcache for in-memory caches, use Guava. The Guava
cache code has been more completely tested by Google in high load
production environments, and it tends to have fewer bugs. It enables
caches to be built at any time, rather than only at server startup.
By creating a Guava cache as soon as it is declared, rather than
during the LifecycleListener.start() for the CachePool, we can promise
any downstream consumer of the cache that the cache is ready to
execute requests the moment it is supplied by Guice. This fixes a
startup ordering problem in the GroupCache and the ProjectCache, where
code wants to use one of these caches during startup to resolve a
group or project by name.
Tracking the Gauva backend caches with a DynamicMap makes it possible
for plugins to define their own in-memory caches using CacheModule's
cache() function to declare the cache. It allows the core server to
make the cache available to administrators over SSH with the gerrit
show-caches and gerrit flush-caches commands.
Persistent caches store in a private H2 database per cache, with a
simple one-table schema that stores each entry in a table row as a
pair of serialized objects (key and value). Database reads are gated
by a BloomFilter, to reduce the number of calls made to H2 during
cache misses. In theory less than 3% of cache misses will reach H2 and
find nothing. Stores happen on a background thread quickly after the
put is made to the cache, reducing the risk that a diff or web_session
record is lost during an ungraceful shutdown.
Cache databases are capped around 128M worth of stored data by running
a prune cycle each day at 1 AM local server time. Records are removed
from the database by ordering on the last access time, where last
accessed is the last time the record was moved from disk to memory.
Change-Id: Ia82d056796b5af9bcb1f219fe06d905c9c0fbc84
Plugins may contribute to the /plugins/NAME/ URL space by providing
a ServletModule in the manifest using Gerrit-HttpModule and binding
servlets and filters using Guice bindings.
All names are relative to the plugin's directory, so
serve("/").with(IndexServlet.class);
will handle /plugins/NAME/ and not "/" on the server. This makes a
plugin automatically relocatable to match its SSH command name or
the name in $site_dir/plugins.
Change-Id: I17e3007f0310d2bf4989d652f18864a77c5d5f2e
These settings are created by m2eclipse but don't matter on
this module because there are no Java source files here.
Change-Id: I3c21c40ad5200c320ecb4189aef3618d10333855
This is a new JAR produced by the build that contains almost all of
the code that the corresponding WAR contains at runtime. This permits
plugin authors to compile against this single interface JAR, and then
load their plugin into a running server that uses the real WAR.
Having the API be a single JAR simplifies plugin development, Maven
users can depend on this single JAR using the provided scope. Other
IDE users can just make a new Java project and add this single JAR
as the only dependency.
Change-Id: Ie045ec4202d44b78b75ccb4af000e13c1e7378ce
