The benchmarks can be built and run using bazel by running:
$ bazel run //org.eclipse.jgit.benchmarks:benchmarks
Change-Id: I6679750eaa0f2be30ed9d45036e013b0ea4fcc86
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Bazel: Reuse version from .bazelversion for minimum used version check
Bazel is still supported in addition to the Bazel wrapper Bazelisk,
that is recommended, as it would automatically switch to the right
Bazel version on stable branches (like it was the case with Buck).
That why minimum used Bazel version check is still needed in WORKSPACE
file in addition to the .bazelversion used by Bazelisk. That means that
currently, bazel version is maintained in two places:
* .bazelversion
* WORKSPACE
This change introduces the repository rule to read the bazel version
from the .bazelversion file and perform the minimum version check.
Change-Id: Ib9c1382935ded7bcd322ed0122838c40ba2faa6c
Signed-off-by: David Ostrovsky <david@ostrovsky.org>
Using buildifier from master branch and the command:
$ buildifier -r -lint fix -warnings all .
Change-Id: I52a18c09a1f192e2141f4156f9c1aabbbdbc910a
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Increase severity of AmbiguousMethodReference to ERROR
All instances of this problem have been fixed. Increase its severity
to ERROR to prevent reoccurrences.
Change-Id: I42d41a7c32b43d1ba59a28cd2f5a7d0ad315d8d9
Signed-off-by: David Pursehouse <david.pursehouse@gmail.com>
Fix NarrowingCompoundAssignment warnings from Error Prone
Error Prone reports:
[NarrowingCompoundAssignment] Compound assignments from long to int
hide lossy casts
and
[NarrowingCompoundAssignment] Compound assignments from int to byte
hide lossy casts
See https://errorprone.info/bugpattern/NarrowingCompoundAssignment
Fix the warnings by adding explicit casts or changing types as
necessary.
Now that all occurrences of the warning are fixed, increase its
severity to ERROR.
Change-Id: Idb3670e6047b146ae37daee07212ff9455512623
Signed-off-by: David Pursehouse <david.pursehouse@gmail.com>
GlobalBundleCache: Fix ClassNewInstance warning from Error Prone
Error Prone reports:
[ClassNewInstance] Class.newInstance() bypasses exception checking;
prefer getDeclaredConstructor().newInstance()
See https://errorprone.info/bugpattern/ClassNewInstance
This was the only occurrence of the warning in the code base; now it's
fixed, increase the severity to ERROR to prevent future occurrences.
Change-Id: Ic04d1c5d2bd458bbb4bb399d6ce9d147bd48d0b1
Signed-off-by: David Pursehouse <david.pursehouse@gmail.com>
Error Prone: Increase severity of NonOverridingEquals to ERROR
Error Prone reports the warning on several classes:
[NonOverridingEquals] equals method doesn't override Object.equals;
if this is a type-specific helper for a method that does override
Object.equals, either inline it into the callers or rename it to
avoid ambiguity.
See https://errorprone.info/bugpattern/NonOverridingEquals
Most of these are in the public API, so we can't rename or inline them
without breaking the API. FileSnapshot is not part of the public API,
but clients may be using it anyway, so we also shouldn't change that.
Suppress all the warnings instead. Having the check at severity ERROR
will at least make sure we don't introduce any new occurrences.
Change-Id: I92345c11256f06b4fa03ccc13337f72af5a43591
Signed-off-by: David Pursehouse <david.pursehouse@gmail.com>
Increase severity of OperatorPrecedence to ERROR, and fix instances
Fix all remaining instances of the OperatorPrededence warning, by adding
parentheses to make the precedence explicit.
Change-Id: Ib296dfed09f9be042d0ff0f7fad8214e4dd766b4
Signed-off-by: David Pursehouse <david.pursehouse@gmail.com>
ErrorProne: Increase severity of FutureReturnValueIgnored to ERROR
The only remaining code where the return value is ignored is in tests.
Update them to store the value and perform a basic assertion.
Change-Id: I29ef5bd5dd0648aac3490f9e47ecc74544109652
Signed-off-by: David Pursehouse <david.pursehouse@gmail.com>
Based on recent work by Dave Borowitz on the Gerrit project [1, 2].
The warnings/error configuration is unchanged, but now the checks are
enabled by default during the build rather than having to be manually
invoked.
[1] https://gerrit-review.googlesource.com/c/gerrit/+/225653
[2] https://gerrit-review.googlesource.com/c/gerrit/+/225714
Change-Id: I7f4849896af72de38880b13d64519cc93bb3d2a3
Signed-off-by: David Pursehouse <david.pursehouse@gmail.com>
Add dependencies from source to binary features and enforce the same
version. Restrict the dependencies between binary features by version,
too.
Adapt the version.sh script to properly replace these version numbers.
Bug: 545906
Change-Id: I953616e58d27accdf61b49f6435a54895bcbf6da
Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
The native.git_repository method doesn't work in the latest version
of bazel, and causes the build to fail with:
type 'struct' has no method git_repository()
Change-Id: Id6a57369b681c0afe811e9e3740b141fb7fb4653
Signed-off-by: David Pursehouse <david.pursehouse@gmail.com>
(cherry picked from commit ec5fc57b79)
The native.git_repository method doesn't work in the latest version
of bazel, and causes the build to fail with:
type 'struct' has no method git_repository()
Change-Id: Id6a57369b681c0afe811e9e3740b141fb7fb4653
Signed-off-by: David Pursehouse <david.pursehouse@gmail.com>
The script missed to update all but the first version in
org.eclipse.jgit.coverage/pom.xml
Change-Id: If8021accf07d7b57b477992cc0f1ba8ddc7db9a6
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Also replace native git_repository rule with Starlark rule. This is
needed because in recent Bazel versions native git_repository rule
is deprecated.
Change-Id: I2c19fd31693a930d7d35fdbb93bfa4abf21fa2aa
Signed-off-by: David Ostrovsky <david@ostrovsky.org>
Bazel: Increase severity of DefaultCharset to ERROR
All existing instances of this issue have been fixed in preceding
commits. Increase its severity to ERROR so that it is easier to
detect reoccurences.
Change-Id: I50f95152857baac5ca44c15493f23b6f9cfac1bf
Signed-off-by: David Pursehouse <david.pursehouse@gmail.com>
All instances of this potential bug have been cleaned up in
preceding commits. Increase the severity to ERROR so that it
is easier to detect reoccurences.
Change-Id: I25beebcea1f01f468e0f2b1d24a83511029c077c
Signed-off-by: David Pursehouse <david.pursehouse@gmail.com>
Bazel: Increase severity of ExpectedExceptionChecker to ERROR
Incorrect usage of ExpectedException has been cleaned up in the
preceding commits. Increase the severity from WARN to ERROR so
that it is easier to catch any reoccurences.
Change-Id: I57decf620b37e85413bda53723f839c02b488f2c
Signed-off-by: David Pursehouse <david.pursehouse@gmail.com>
Bazel: Provide toolchain with activated error prone warnings
On recent bazel versions it's trivial to apply package specific checks.
Provide custom java toolchain with all error prone warnings activated.
The list of all error prone warnings was borrowed from here: [1].
Test Plan:
$ bazel build --java_toolchain //tools:error_prone_warnings_toolchain \
//...
[1] https://github.com/bazelbuild/BUILD_file_generator/blob/master/tools/bazel_defs/java.bzl
Change-Id: I207a368555bfb7ddab8d782d46d563ce779a6211
Signed-off-by: David Ostrovsky <david@ostrovsky.org>
Signed-off-by: David Pursehouse <david.pursehouse@gmail.com>
The initial implementation only builds the packages consumed by
Gerrit Code Review.
Test build and execution is not implemented.
We prefer to consume maven_jar custom rule from bazlets repository,
for the same reasons as in the Gerrit project:
* Caching artifacts across different clones and projects
* Exposing source classifiers and neverlink artifact
TEST PLAN:
$ bazel build :all
$ unzip -t bazel-genfiles/all.zip
Archive: bazel-genfiles/all.zip
testing: libjgit-archive.jar OK
testing: libjgit-servlet.jar OK
testing: libjgit.jar OK
testing: libjunit.jar OK
No errors detected in compressed data of bazel-genfiles/all.zip.
Change-Id: Ia837ce95d9829fe2515f37b7a04a71a4598672a0
Signed-off-by: David Ostrovsky <david@ostrovsky.org>
Signed-off-by: David Pursehouse <david.pursehouse@gmail.com>
The bundle org.eclipse.jgit.java7 was deleted in 4.0
Change-Id: I57dbc0b18eaf164c8f53cc2b776ecb80481a993d
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Remove org.eclipse.jgit.updatesite project from tools/version.sh
We don't need to update versions for this project which was removed
a long time ago.
Change-Id: Ie2d030134942add152847581797db3a213ec4c9e
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Run git describe during the build to determine the lineage of this
working directory and stamp this information into the binary.
Change-Id: I0ad24125c31e4280ccf900bac4065924087b05aa
Today there are plenty of modern build tool systems available in the
wild (in no particular order):
* http://bazel.io
* https://pantsbuild.github.io
* http://shakebuild.com
* https://ninja-build.org
* https://buckbuild.com
The attributes, that all these build tools have in common, are:
* reliable
* correct
* very fast
* reproducible
It must not always be the other build tool, this project is currently
using. Or, quoting Gerrit Code Review maintainer here:
"Friends, don't let friends use <the other build tool system>!"
This change is non-complete implementation of JGit build in Buck,
needed by Gerrit Code Review to replace its dependency with standlone
JGit cell. This is very useful when a developer is working on both
projects and is trying to integrate changes made in JGit in Gerrit.
The supported workflow is:
$ cd jgit
$ emacs <hack>
$ cd ../gerrit
$ buck build --config repositories.jgit=../jgit gerrit
With --config repositories.jgit=../jgit jgit cell is routed through
JGit development tree.
To build jgit, issue:
$ buck build //:jgit
[-] PROCESSING BUCK FILES...FINISHED 0,0s
Yes, you can't measure no-op build time, given that Buck daemon is
used.
Change-Id: I301a71b19fba35a5093d8cc64d4ba970c2877a44
Signed-off-by: David Ostrovsky <david@ostrovsky.org>
Since we updated minimum Java version to Java 7 the console bundle
doesn't need to be a separate bundle anymore. Move the contained classes
to the pgm bundle which is using these classes.
Change-Id: If8e6f2d7405fdfe6f4b178673b4ccf99c67d4b64
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Enable passing version number to maven central scripts
Also check if the passed version matches the version pattern
<major>.<minor>.<micro>.<qualifier>-<classifier>
Change-Id: Ib7edf51fb5e89232909611de5b4811a62b4f3953
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Fix version.sh to update Eclipse-SourceBundle version
The version attribute of Eclipse-SourceBundle must match
the bundle version.
Change-Id: Ic629ccae1d89c9070e4ec80420a0e2ed7d403922
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
These scripts were created to bootstrap the initial contribution for
Eclipse using information from the pre-Eclipse history. We are well
past the point where the project will rewrite history in order to
correct copyright statements, so these tools no longer make sense
to keep in the tip of the tree.
Change-Id: If68419ead0766035d17a21a53a3e5e761eaa70c4
The 1.0.0 release tags have a new suffix.
Account for this.
Change-Id: Ic6f260b6a5ba353af3b312b722f576155208eaa0
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
We used our LICENSE file to describe both the license of the package,
and also the header template that should appear at the start of
all Java files we create. This creates a confusing situation for
readers who just want to consume the package, because our file
header template starts off in the middle of a sentence.
Move our template header to a separate file, and reformat the text
of the license to be something more readable by a person reviewing
the project's terms of use.
Change-Id: If318e64c06683ea14e0240914c2d057c9199ce98
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
David Pursehouse
Matthias Sohn
David Ostrovsky
Thomas Wolf
Shawn Pearce
Shawn Pearce