This avoids we show a stacktrace on the console by default when this
type of exception is thrown during the run method is executed.
Change-Id: I4d3c04b27727762870d3135228768aae177ea3fc
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
This avoids we show a stacktrace on the console by default when this
type of exception is thrown during the run method is executed.
Change-Id: I087b3e510682c68cae74c069b10050c7acb48a29
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
This avoids we show a stacktrace on the console by default when this
type of exception is thrown during the run method is executed.
Change-Id: Iba0e4338381519dc55c2892d95181ddfb881adf2
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
The import is only needed because of a reference to it in the Javadoc,
and can be avoided by explicitly specifying the package instead, which
is how it's referenced in other cases (Constants, FileHeader).
Change-Id: I0c6254a9adf1f52fb8f2c04a858b11696ad264f5
Signed-off-by: David Pursehouse <david.pursehouse@gmail.com>
Since 8ed59c5 ("Make TestRepository AutoCloseable", Jan 11, 2019) the
TestRepository class is auto-closeable, but instantiations of it were
not converted to use try-with-resource.
Converting to try-with-resource results, in several cases, in the
repository being closed twice because LocalDiskRepositoryTestCase has
logic to close created repositories in the tearDown method. This results
in several tests emitting a warning to the console:
close() called when useCnt is already zero
Change the default behavior of the createRepository method to not use
the auto-close logic in LocalDiskRepositoryTestCase, so that thy will
instead be closed (only once) using the AutoCloseable implementation.
Deprecate the method that has the autoClose parameter.
Change-Id: I63d62c9913f9b61271667861dae144e551d358c1
Signed-off-by: David Pursehouse <david.pursehouse@gmail.com>
This avoids we show a stacktrace on the console by default when this
type of exception is thrown during the run method is executed.
Change-Id: Ic5d9d94c4a451f300fb7ad3f71b3e22db9a2c181
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
This avoids we show a stacktrace on the console by default when this
type of exception is thrown during the run method is executed. Also
externalize error message.
Change-Id: I909dc77385a672d8298053b12683c0cbbf9f2aa2
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
This avoids we show a stacktrace on the console by default when this
type of exception is thrown during the run method is executed.
Change-Id: Idf5325bcc235fbcf4418239a1d49572409576a7d
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
This avoids we show a stacktrace on the console by default when this
type of exception is thrown during the run method is executed.
Change-Id: Ic06bf16c9bfc79753a9ec767f8030a12887df168
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
This avoids we show a stacktrace on the console by default when this
type of exception is thrown during the run method is executed.
Change-Id: I043838143df7280351186ee1bcca4d1cc4832257
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
This avoids we show a stacktrace on the console by default when one of
the expected exceptions is thrown during the run method is executed.
Change-Id: Ib07cc8dd26b45b62de1d77739380eb36833082f1
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
This avoids we show a stacktrace on the console by default when this
type of exception is thrown during the run method is executed.
Change-Id: I9290b057b004e9ee4137d968ba4f5759442aacb6
Signed-off-by: Matthias Sohn <matthias.sohn@sap.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>
This avoids we show a stacktrace on the console by default when this
type of exception is thrown during the run method is executed.
Change-Id: I02940bdc1645c1d5e0abeeb4f1bafde1b8c54a1c
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
This also includes a change to generating the jgit CLI jar. Shading is
no longer possible because it breaks the signature of BouncyCastle.
Instead, the Spring Boot Loader Maven plug-in is now used to generate an
executable jar.
Bug: 382212
Change-Id: I35ee3d4b06d9d479475ab2e51b29bed49661bbdc
Also-by: Gunnar Wagenknecht <gunnar@wagenknecht.org>
Signed-off-by: Gunnar Wagenknecht <gunnar@wagenknecht.org>
Signed-off-by: Medha Bhargav Prabhala <mprabhala@salesforce.com>
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
This change introduces the concept of a GpgSigner which will sign
commits. The GpgSigner will be of a specific implementation (eg.,
Bouncycastle or OpenPgP executable). The actual implementation is not
part of this change.
Bug: 382212
Change-Id: Iea5da1e885c039e06bc8d679d46b124cbe504c8e
Also-by: Medha Bhargav Prabhala <mprabhala@salesforce.com>
Signed-off-by: Medha Bhargav Prabhala <mprabhala@salesforce.com>
Signed-off-by: Gunnar Wagenknecht <gunnar@wagenknecht.org>
If a command is stopped by throwing a Die exception since a generic
exception was caught this exception contains additional information
which is not available in the error message. Hence chain it to the Die
exception in order to allow printing a complete stacktrace including
causes to the error stream of the JGit command line by adding option
--show-stack-trace, e.g.
$ jgit --show-stack-trace commit -m "test"
Change-Id: I7ad8c56b997ab60d2bd08f4e7b4d0b80c84021c3
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Update
- orb.eclipse.jdt:ecj to 3.16.0
- plexus-compiler-eclipse to 2.8.5
Change-Id: I56d6d57c4c49646a9c98d2d1ca01b1b1d92280cf
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
As explained in 'The "Double-Checked Locking is Broken"
Declaration'[*], Java's memory model does not support double-checked
locking:
class LazyReadableChannel {
private ReachableChannel rc = null;
public ReadableChannel get() {
if (rc == null) {
synchronized (this) {
if (rc == null) {
rc = new ReadableChannel();
}
}
}
return rc;
}
}
With JDK 5 and newer, there is a formal memory model that ensures this
works if "rc" is volatile, but it is still not thread-safe without
that.
Fortunately, this ReadableChannelSupplier is never passed between
threads, so it does not need to be thread-safe. Simplify by removing
the synchronization.
[*] https://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html
Change-Id: I0698ee6618d734fc129dd4f63fc047c1c17c94a9
Signed-off-by: Jonathan Nieder <jrn@google.com>
Matthias Sohn
David Pursehouse
Medha Bhargav Prabhala
Gunnar Wagenknecht
Jonathan Nieder