Use versioned index directories for repository indices.
Change from the index version of a repository index being stored in a config
file to also using index directories with the version in the name. For that,
`LuceneRepoIndexStore` is added, which adds the fixed `lucene` part to the path.
It also gives out the location of the `lucene.conf` file, which is now stored in
the index directory. This way it is automatically deleted when the directory is
deleted.
I believe that it should also provide means to store branch aliases and tips,
i.e. hide the config file completely. But this isn't implemented with this
commit, the `LuceneService` is still aware that a config file is used.
In order to be able to update the index definition, the ticket index
is assigned a version number, 2. This way the definiton can be updated
and compatability with existing index files can be checked.
The actual index is stored in a directory of name `indexVersion_codecVersion`.
This wayit is veriy easy to check if an index of a certain version exists on the
filesystem. It allows to have multiple indexes of different versions present,
so that a downgrade of the software is possible without having to reindex
again. Of coure, this is only possible if no new tickets were created since these
would be missing in the old index.
A new class `LuceneIndexStore` is introduced, which abstracts away the versioned
index directory. The idea is, that this provides one place to keep the Lucene
codec version and to allow to code compatibility rules into this class, so that
older indices can still be used if they are compatible.
Add DocValues to support sorting of ticket index fields.
In order to support sorting, Lucene 5 needs DocValue fields in an index.
So in order to make the ticket index work, i.e. show any tickets on the
tickets page, the ticket index needs to be changed, adding a DocValues
field.
The DocValuesFields are implemented for the current index, which does not
use multiple values for a field. Should at any time in the future an
existing numeric field get multiple values stored in a document, then
the index needs to know that and use SortedNumeric DocValues and SortFields
instead.
Update link target to Lucene 5.5 query syntax, moving the link to the page.
Update the link target to the query parser syntax page of the 5.5 version.
Refactor the `LuceneSearchPage` to use an `ExternalLink` for the link
to the lucene page, so that the link target is kept and updated in the
Java code. Move the link out of the language files. This was way too
cumbersome to update the link target (which is probably why no one ever
did).
The query help text is changed to contain a variable:
`gb.queryHelp = here be some ${querySyntax} help`, which is replaced by
Wicket with a link.
The link text is a new lange file property: `gb.querySyntax`.
Add library `lucene-backward-codecs` to migrate indices.
To be able to read and migrate Lucene indices from old (4.x)
formats to new (5.x) ones, add the `lucene-backward-codecs`
library to the project.
It is added to the `ext` directory and therefore to the classpath.
According to the Lucene documentation, having it in the classpath
can affect performance. But right now the `ext` directory is the
only one available and even for a separate tool for offline
migration the library would be needed.
Exclude Lucene dependencies `lucene-spatial` and `lucene-join`.
They were added during the update but are not needed. This patch
excludes them explicitly so that they do not show up in the
generated IDE files and `ext` directory.
With localizations, there can be longer text then 13em so there is a line break.
This fix prevent this line breaking and thus every line has normal height again.
Configure the build for Circle CI in the new file circle.yml.
Specify a compile step to have the build fail on compilation error.
The test step is then configured as `ant test`, which will compile
again due to the limits of Ant/Moxie.
Contrary to the documentation, the default Java version on Circle CI
is Java 8.
The project is set as a Java 7 project. We define to use OpenJDK 7,
because the Gitblit build has some trouble with Java 8, I consider
Java 7 the default, and Circle CI does not provide an Oracle JDK 7
installation to use. I could only get it to work with OpenJDK 7.
The Java version is reported in the Circle CI build script to ease
analysis.
Test and coverage reports get stored as artifacts for a build, which
allows to browse them in the Circle CI web interface.
Add the most basic build definition file for Travis CI. It only
defines the project language as Java. For the rest the defaults
are kept as Travis seems to work fine with them.
We add `.travis.yml` as a dotfile in order not to clutter the
top directory with too much non-project files.
Update to explicit versions of JUnit 4.12 and JaCoCo 0.7.8
Use explicit coordinates, and therefor version numbers fro JUnit
in the build.moxie file. It should not be some version that just
happens to be used.
Update JUnit to latest 4.12.
Update JaCoCo to lates 0.7.8, which makes it work under Java 8.
The last used version would fail when tests are run under Java 8.