| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
| |
Replace the links in NOTICE to the closed down Google Code
(code.google.com) with their Github counterparts where the projects
moved to.
Gitblit used to download dependencies upon first start. This has since
long been changed and everything is bundled with Gitblit now. So reflect
this in the design.mkd document, which still said they would be
downloaded.
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
It was still pointing to Google Code.
This closes #1408
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
Since Bintray seized operation, the packages for versions 1.4.0 - 1.8.0
have been uploaded to Cloudsmith. Adjust the links appropriately.
An attribution is added to comply with Cloudsmith's OSS hosting policy.
|
|
|
|
|
|
|
| |
Update the URL to the Gitblit docker image to point to the
`gitblit/gitblit` repository, which I now consider the official
Docker repository.
Also link to the Docker images on the main page.
|
|
|
|
|
|
|
| |
Ohloh got acquired by Synopsis and is nor Open Hub.
Change the links for the tiny widget to point to Open Hub.
Closes #1356
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The `tickets_overview` page links to the `tickets_setup` page using a
wiki style internal link: `[[tickets setup]]`. Whatever library is
interpreting that is creating a link under the assumption that the
resulting page will be called `tickets-setup.html`. But that is not the
convention used by Moxie, which will use the source file name and thus
create a file called `tickets_setup.html`.
I was not able to find out which of the many libraries included is the
one that parses this file and creates the link. Messy.
There are two solutions. One is to configure the Moxie site build to
generate the file as `tickets-setup.html`. But this would break any
links to that page that might exist somewhere on the Interweb. So I
opted for the other option, which is to not use wiki syntax for the
reference to the local page but normal markdown syntax. This is not
a wiki, afterall.
|
|
|
|
| |
Also: release notes.
|
|
|
|
|
|
|
|
|
| |
While most systems will not need the class path passed to the JVM with
the `-cp` parameter to be in quotes, apparently some exist where that
will not work without the quotes, e.g. FreeBSD.
So always use quotes for the class path in all scripts.
Issue #1333
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add Ant tasks and macros to deploy binaries to GitHub,
using GitHub's releases.
Adds an Awk script to extract GH flavoured markdown release notes
from the release.moxie file.
Adds `ok.sh` to the repository so that it is readily available.
This is a Bourne shell GitHub API client, used to create a release
on GitHub and upload the binaries.
|
| |
|
| |
|
|
|
|
|
| |
They will need to be called with the classpath and main class now,
instead of simply using the Jar.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The (moxie and other) Launcher do not work with Java 9 and later anymore.
It used to dynamically extend the classpath, misusing an internal
interface of the `URLClassLoader`. This is no longer possible since Java 9,
which closed that path and does not offer any way to dynamically extend
the classpath during runtime.
So the choice is between providing one large Jar with everything in it,
providing a Jar that has the Jars in `ext` listed explicitly in its
manifest, and specifying the classpath on the command line where
the `ext` directory can be added and all contained jar files will
be put on the classpath.
The motivation for the Launcher class was to be able to simply drop
new jar files into a directory and they will be picked up at the
application start, without having to specify a classpath. We opt
for solution three here. This way jar files can still be dropped
into the ext directory, albeit the directory needs to be added to
the classpath on the command line. Unfortunately using a wildcard
is not possible in the manifest file. We change the calls in the
script files accordingly. This seems like a good compromise,
since no one will run the application manually typing the whole
commandline anyway.
This also does away with the splash screen, by the way. Again,
doesn't seem like a big loss, as I don't think it was ever shown
for the Authority.
Personally, I am not convinced that it is the best way, because
I don't really think that the use case of dropping whatever jar
files into the `ext` directory is a valid one that happened a lot.
This does not yet fix the client programs, which still use a
Launcher. Maybe for them a all-in-one Jar is a better solution.
Fixes #1262
Fixes #1294
|
|\ |
|
| |
| |
| |
| |
| |
| | |
Integrate the `PasswordHash` class and subclass in the user
and password editing and authentication. Replaces the old code and
the previous `SecurePasswordHashingUtils` class.
|
| |
| |
| |
| | |
Addresses #1166
|
| |
| |
| |
| |
| |
| | |
e.g.: https://localhost:8443/rpc/?req=LIST_REPOSITORY_BRANCHES&name=repo.git
Fix #1184
|
|/
|
|
| |
as well
|
|\
| |
| | |
Ticket #998 document dh keysize
|
| | |
|
| | |
|
|/ |
|
| |
|
|
|
|
|
|
| |
+ Filestore listing filtered by user view permissions
+ Configuration help for filestore relocated to website files
+ Added migration example
|
| |
|
|
|
|
|
| |
+ Adds standard logging for all authentication providers
+ Updates help page to use default GitBlit SSH port
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
The RPC URL should be `/rpc/?` and not `/rpc?` according to
https://groups.google.com/d/msg/gitblit/Ajp2gR3B2bM/AXg6wIf21eIJ
|
|\ |
|
| | |
|
| | |
|
|\| |
|
| | |
|
|\| |
|
| | |
|
|\| |
|
| |
| |
| | |
In AuthenticationManager:385, only `provider instanceof UsernamePasswordAuthenticationProvider` will be called
|