mirrors
/
gitblit
mirror of https://github.com/gitblit/gitblit.git
Watch 1
Star 0
Fork 0
Code Issues 0 Releases 43 Wiki Activity
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
2077 Commits
11 Branches
Tree: ce07c4f4ca
Branches Tags
${ item.name }
Create branch ${ searchTerm }
from 'ce07c4f4ca'
${ noResults }
gitblit/src/main/java/com/gitblit/manager/IRepositoryManager.java

IRepositoryManager.java 13KB
Raw Normal View History

Define manager interfaces and update all of Gitblit to use managers These manager interfaces define how the GitBlit singleton will eventually be split into smaller component managers. The Wicket app and all servlets have been updated to request the needed managers. There are _very_ few method signature changes - although there are a handful. This is a surgical sharding of responsibility based on a proof of concept refactor. Instead of random references to GittBlit.self() there are now precise references to the manager interface required to accomplish some task. Some tasks may require references to multiple managers. The code is now littered with calls to GitBlit.getManager(class) and those familiar with the code-base will no doubt notice the duplication of methods from IUserService in IUserManager and the addition of implementation methods in the GitBlit context class. When the GitBlit class is broken apart and the existing external authentication user service classes are refactored to AuthenticationService classes, this will again simplify and flatten. But in order to safely and cleanly modularize the stable code-base we will have to live with a little duplication for a short while. Change-Id: I7314ec8acaab2dcc6092785ed4434cc09fdbbe16
10 years ago
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
Extract RepositoryManager from the GitBlit singleton Change-Id: I265cfaf25e4093ffa5f53f70d8eb1c20d731b7b3
10 years ago
Define manager interfaces and update all of Gitblit to use managers These manager interfaces define how the GitBlit singleton will eventually be split into smaller component managers. The Wicket app and all servlets have been updated to request the needed managers. There are _very_ few method signature changes - although there are a handful. This is a surgical sharding of responsibility based on a proof of concept refactor. Instead of random references to GittBlit.self() there are now precise references to the manager interface required to accomplish some task. Some tasks may require references to multiple managers. The code is now littered with calls to GitBlit.getManager(class) and those familiar with the code-base will no doubt notice the duplication of methods from IUserService in IUserManager and the addition of implementation methods in the GitBlit context class. When the GitBlit class is broken apart and the existing external authentication user service classes are refactored to AuthenticationService classes, this will again simplify and flatten. But in order to safely and cleanly modularize the stable code-base we will have to live with a little duplication for a short while. Change-Id: I7314ec8acaab2dcc6092785ed4434cc09fdbbe16
10 years ago
​
​
​
​
​
Update javadoc
10 years ago
Define manager interfaces and update all of Gitblit to use managers These manager interfaces define how the GitBlit singleton will eventually be split into smaller component managers. The Wicket app and all servlets have been updated to request the needed managers. There are _very_ few method signature changes - although there are a handful. This is a surgical sharding of responsibility based on a proof of concept refactor. Instead of random references to GittBlit.self() there are now precise references to the manager interface required to accomplish some task. Some tasks may require references to multiple managers. The code is now littered with calls to GitBlit.getManager(class) and those familiar with the code-base will no doubt notice the duplication of methods from IUserService in IUserManager and the addition of implementation methods in the GitBlit context class. When the GitBlit class is broken apart and the existing external authentication user service classes are refactored to AuthenticationService classes, this will again simplify and flatten. But in order to safely and cleanly modularize the stable code-base we will have to live with a little duplication for a short while. Change-Id: I7314ec8acaab2dcc6092785ed4434cc09fdbbe16
10 years ago
​
​
​
​
​
​
​
Update javadoc
10 years ago
Define manager interfaces and update all of Gitblit to use managers These manager interfaces define how the GitBlit singleton will eventually be split into smaller component managers. The Wicket app and all servlets have been updated to request the needed managers. There are _very_ few method signature changes - although there are a handful. This is a surgical sharding of responsibility based on a proof of concept refactor. Instead of random references to GittBlit.self() there are now precise references to the manager interface required to accomplish some task. Some tasks may require references to multiple managers. The code is now littered with calls to GitBlit.getManager(class) and those familiar with the code-base will no doubt notice the duplication of methods from IUserService in IUserManager and the addition of implementation methods in the GitBlit context class. When the GitBlit class is broken apart and the existing external authentication user service classes are refactored to AuthenticationService classes, this will again simplify and flatten. But in order to safely and cleanly modularize the stable code-base we will have to live with a little duplication for a short while. Change-Id: I7314ec8acaab2dcc6092785ed4434cc09fdbbe16
10 years ago
​
​
​
​
​
​
​
Update javadoc
10 years ago
Define manager interfaces and update all of Gitblit to use managers These manager interfaces define how the GitBlit singleton will eventually be split into smaller component managers. The Wicket app and all servlets have been updated to request the needed managers. There are _very_ few method signature changes - although there are a handful. This is a surgical sharding of responsibility based on a proof of concept refactor. Instead of random references to GittBlit.self() there are now precise references to the manager interface required to accomplish some task. Some tasks may require references to multiple managers. The code is now littered with calls to GitBlit.getManager(class) and those familiar with the code-base will no doubt notice the duplication of methods from IUserService in IUserManager and the addition of implementation methods in the GitBlit context class. When the GitBlit class is broken apart and the existing external authentication user service classes are refactored to AuthenticationService classes, this will again simplify and flatten. But in order to safely and cleanly modularize the stable code-base we will have to live with a little duplication for a short while. Change-Id: I7314ec8acaab2dcc6092785ed4434cc09fdbbe16
10 years ago
​
​
​
​
​
​
Update javadoc
10 years ago
Define manager interfaces and update all of Gitblit to use managers These manager interfaces define how the GitBlit singleton will eventually be split into smaller component managers. The Wicket app and all servlets have been updated to request the needed managers. There are _very_ few method signature changes - although there are a handful. This is a surgical sharding of responsibility based on a proof of concept refactor. Instead of random references to GittBlit.self() there are now precise references to the manager interface required to accomplish some task. Some tasks may require references to multiple managers. The code is now littered with calls to GitBlit.getManager(class) and those familiar with the code-base will no doubt notice the duplication of methods from IUserService in IUserManager and the addition of implementation methods in the GitBlit context class. When the GitBlit class is broken apart and the existing external authentication user service classes are refactored to AuthenticationService classes, this will again simplify and flatten. But in order to safely and cleanly modularize the stable code-base we will have to live with a little duplication for a short while. Change-Id: I7314ec8acaab2dcc6092785ed4434cc09fdbbe16
10 years ago
​
​
​
​
​
​
​
​
Update javadoc
10 years ago
Define manager interfaces and update all of Gitblit to use managers These manager interfaces define how the GitBlit singleton will eventually be split into smaller component managers. The Wicket app and all servlets have been updated to request the needed managers. There are _very_ few method signature changes - although there are a handful. This is a surgical sharding of responsibility based on a proof of concept refactor. Instead of random references to GittBlit.self() there are now precise references to the manager interface required to accomplish some task. Some tasks may require references to multiple managers. The code is now littered with calls to GitBlit.getManager(class) and those familiar with the code-base will no doubt notice the duplication of methods from IUserService in IUserManager and the addition of implementation methods in the GitBlit context class. When the GitBlit class is broken apart and the existing external authentication user service classes are refactored to AuthenticationService classes, this will again simplify and flatten. But in order to safely and cleanly modularize the stable code-base we will have to live with a little duplication for a short while. Change-Id: I7314ec8acaab2dcc6092785ed4434cc09fdbbe16
10 years ago
​
​
​
​
​
​
​
​
​
Update javadoc
10 years ago
Define manager interfaces and update all of Gitblit to use managers These manager interfaces define how the GitBlit singleton will eventually be split into smaller component managers. The Wicket app and all servlets have been updated to request the needed managers. There are _very_ few method signature changes - although there are a handful. This is a surgical sharding of responsibility based on a proof of concept refactor. Instead of random references to GittBlit.self() there are now precise references to the manager interface required to accomplish some task. Some tasks may require references to multiple managers. The code is now littered with calls to GitBlit.getManager(class) and those familiar with the code-base will no doubt notice the duplication of methods from IUserService in IUserManager and the addition of implementation methods in the GitBlit context class. When the GitBlit class is broken apart and the existing external authentication user service classes are refactored to AuthenticationService classes, this will again simplify and flatten. But in order to safely and cleanly modularize the stable code-base we will have to live with a little duplication for a short while. Change-Id: I7314ec8acaab2dcc6092785ed4434cc09fdbbe16
10 years ago
​
​
​
​
​
​
​
​
Update javadoc
10 years ago
Define manager interfaces and update all of Gitblit to use managers These manager interfaces define how the GitBlit singleton will eventually be split into smaller component managers. The Wicket app and all servlets have been updated to request the needed managers. There are _very_ few method signature changes - although there are a handful. This is a surgical sharding of responsibility based on a proof of concept refactor. Instead of random references to GittBlit.self() there are now precise references to the manager interface required to accomplish some task. Some tasks may require references to multiple managers. The code is now littered with calls to GitBlit.getManager(class) and those familiar with the code-base will no doubt notice the duplication of methods from IUserService in IUserManager and the addition of implementation methods in the GitBlit context class. When the GitBlit class is broken apart and the existing external authentication user service classes are refactored to AuthenticationService classes, this will again simplify and flatten. But in order to safely and cleanly modularize the stable code-base we will have to live with a little duplication for a short while. Change-Id: I7314ec8acaab2dcc6092785ed4434cc09fdbbe16
10 years ago
​
​
​
​
​
​
​
​
​
Update javadoc
10 years ago
Define manager interfaces and update all of Gitblit to use managers These manager interfaces define how the GitBlit singleton will eventually be split into smaller component managers. The Wicket app and all servlets have been updated to request the needed managers. There are _very_ few method signature changes - although there are a handful. This is a surgical sharding of responsibility based on a proof of concept refactor. Instead of random references to GittBlit.self() there are now precise references to the manager interface required to accomplish some task. Some tasks may require references to multiple managers. The code is now littered with calls to GitBlit.getManager(class) and those familiar with the code-base will no doubt notice the duplication of methods from IUserService in IUserManager and the addition of implementation methods in the GitBlit context class. When the GitBlit class is broken apart and the existing external authentication user service classes are refactored to AuthenticationService classes, this will again simplify and flatten. But in order to safely and cleanly modularize the stable code-base we will have to live with a little duplication for a short while. Change-Id: I7314ec8acaab2dcc6092785ed4434cc09fdbbe16
10 years ago
​
​
​
​
​
​
​
​
​
Update javadoc
10 years ago
Define manager interfaces and update all of Gitblit to use managers These manager interfaces define how the GitBlit singleton will eventually be split into smaller component managers. The Wicket app and all servlets have been updated to request the needed managers. There are _very_ few method signature changes - although there are a handful. This is a surgical sharding of responsibility based on a proof of concept refactor. Instead of random references to GittBlit.self() there are now precise references to the manager interface required to accomplish some task. Some tasks may require references to multiple managers. The code is now littered with calls to GitBlit.getManager(class) and those familiar with the code-base will no doubt notice the duplication of methods from IUserService in IUserManager and the addition of implementation methods in the GitBlit context class. When the GitBlit class is broken apart and the existing external authentication user service classes are refactored to AuthenticationService classes, this will again simplify and flatten. But in order to safely and cleanly modularize the stable code-base we will have to live with a little duplication for a short while. Change-Id: I7314ec8acaab2dcc6092785ed4434cc09fdbbe16
10 years ago
​
​
​
​
​
​
​
​
Update javadoc
10 years ago
Define manager interfaces and update all of Gitblit to use managers These manager interfaces define how the GitBlit singleton will eventually be split into smaller component managers. The Wicket app and all servlets have been updated to request the needed managers. There are _very_ few method signature changes - although there are a handful. This is a surgical sharding of responsibility based on a proof of concept refactor. Instead of random references to GittBlit.self() there are now precise references to the manager interface required to accomplish some task. Some tasks may require references to multiple managers. The code is now littered with calls to GitBlit.getManager(class) and those familiar with the code-base will no doubt notice the duplication of methods from IUserService in IUserManager and the addition of implementation methods in the GitBlit context class. When the GitBlit class is broken apart and the existing external authentication user service classes are refactored to AuthenticationService classes, this will again simplify and flatten. But in order to safely and cleanly modularize the stable code-base we will have to live with a little duplication for a short while. Change-Id: I7314ec8acaab2dcc6092785ed4434cc09fdbbe16
10 years ago
​
​
​
​
​
​
​
​
​
Update javadoc
10 years ago
Define manager interfaces and update all of Gitblit to use managers These manager interfaces define how the GitBlit singleton will eventually be split into smaller component managers. The Wicket app and all servlets have been updated to request the needed managers. There are _very_ few method signature changes - although there are a handful. This is a surgical sharding of responsibility based on a proof of concept refactor. Instead of random references to GittBlit.self() there are now precise references to the manager interface required to accomplish some task. Some tasks may require references to multiple managers. The code is now littered with calls to GitBlit.getManager(class) and those familiar with the code-base will no doubt notice the duplication of methods from IUserService in IUserManager and the addition of implementation methods in the GitBlit context class. When the GitBlit class is broken apart and the existing external authentication user service classes are refactored to AuthenticationService classes, this will again simplify and flatten. But in order to safely and cleanly modularize the stable code-base we will have to live with a little duplication for a short while. Change-Id: I7314ec8acaab2dcc6092785ed4434cc09fdbbe16
10 years ago
​
​
​
​
​
​
​
Update javadoc
10 years ago
Define manager interfaces and update all of Gitblit to use managers These manager interfaces define how the GitBlit singleton will eventually be split into smaller component managers. The Wicket app and all servlets have been updated to request the needed managers. There are _very_ few method signature changes - although there are a handful. This is a surgical sharding of responsibility based on a proof of concept refactor. Instead of random references to GittBlit.self() there are now precise references to the manager interface required to accomplish some task. Some tasks may require references to multiple managers. The code is now littered with calls to GitBlit.getManager(class) and those familiar with the code-base will no doubt notice the duplication of methods from IUserService in IUserManager and the addition of implementation methods in the GitBlit context class. When the GitBlit class is broken apart and the existing external authentication user service classes are refactored to AuthenticationService classes, this will again simplify and flatten. But in order to safely and cleanly modularize the stable code-base we will have to live with a little duplication for a short while. Change-Id: I7314ec8acaab2dcc6092785ed4434cc09fdbbe16
10 years ago
​
​
​
​
​
Update javadoc
10 years ago
​
Define manager interfaces and update all of Gitblit to use managers These manager interfaces define how the GitBlit singleton will eventually be split into smaller component managers. The Wicket app and all servlets have been updated to request the needed managers. There are _very_ few method signature changes - although there are a handful. This is a surgical sharding of responsibility based on a proof of concept refactor. Instead of random references to GittBlit.self() there are now precise references to the manager interface required to accomplish some task. Some tasks may require references to multiple managers. The code is now littered with calls to GitBlit.getManager(class) and those familiar with the code-base will no doubt notice the duplication of methods from IUserService in IUserManager and the addition of implementation methods in the GitBlit context class. When the GitBlit class is broken apart and the existing external authentication user service classes are refactored to AuthenticationService classes, this will again simplify and flatten. But in order to safely and cleanly modularize the stable code-base we will have to live with a little duplication for a short while. Change-Id: I7314ec8acaab2dcc6092785ed4434cc09fdbbe16
10 years ago
​
​
Ensure the repository model ref list is refreshed on ref creation or deletion
10 years ago
​
​
​
​
​
​
​
Define manager interfaces and update all of Gitblit to use managers These manager interfaces define how the GitBlit singleton will eventually be split into smaller component managers. The Wicket app and all servlets have been updated to request the needed managers. There are _very_ few method signature changes - although there are a handful. This is a surgical sharding of responsibility based on a proof of concept refactor. Instead of random references to GittBlit.self() there are now precise references to the manager interface required to accomplish some task. Some tasks may require references to multiple managers. The code is now littered with calls to GitBlit.getManager(class) and those familiar with the code-base will no doubt notice the duplication of methods from IUserService in IUserManager and the addition of implementation methods in the GitBlit context class. When the GitBlit class is broken apart and the existing external authentication user service classes are refactored to AuthenticationService classes, this will again simplify and flatten. But in order to safely and cleanly modularize the stable code-base we will have to live with a little duplication for a short while. Change-Id: I7314ec8acaab2dcc6092785ed4434cc09fdbbe16
10 years ago
​
​
​
​
Update javadoc
10 years ago
Define manager interfaces and update all of Gitblit to use managers These manager interfaces define how the GitBlit singleton will eventually be split into smaller component managers. The Wicket app and all servlets have been updated to request the needed managers. There are _very_ few method signature changes - although there are a handful. This is a surgical sharding of responsibility based on a proof of concept refactor. Instead of random references to GittBlit.self() there are now precise references to the manager interface required to accomplish some task. Some tasks may require references to multiple managers. The code is now littered with calls to GitBlit.getManager(class) and those familiar with the code-base will no doubt notice the duplication of methods from IUserService in IUserManager and the addition of implementation methods in the GitBlit context class. When the GitBlit class is broken apart and the existing external authentication user service classes are refactored to AuthenticationService classes, this will again simplify and flatten. But in order to safely and cleanly modularize the stable code-base we will have to live with a little duplication for a short while. Change-Id: I7314ec8acaab2dcc6092785ed4434cc09fdbbe16
10 years ago
​
​
​
​
​
​
​
Update javadoc
10 years ago
Define manager interfaces and update all of Gitblit to use managers These manager interfaces define how the GitBlit singleton will eventually be split into smaller component managers. The Wicket app and all servlets have been updated to request the needed managers. There are _very_ few method signature changes - although there are a handful. This is a surgical sharding of responsibility based on a proof of concept refactor. Instead of random references to GittBlit.self() there are now precise references to the manager interface required to accomplish some task. Some tasks may require references to multiple managers. The code is now littered with calls to GitBlit.getManager(class) and those familiar with the code-base will no doubt notice the duplication of methods from IUserService in IUserManager and the addition of implementation methods in the GitBlit context class. When the GitBlit class is broken apart and the existing external authentication user service classes are refactored to AuthenticationService classes, this will again simplify and flatten. But in order to safely and cleanly modularize the stable code-base we will have to live with a little duplication for a short while. Change-Id: I7314ec8acaab2dcc6092785ed4434cc09fdbbe16
10 years ago
​
​
​
​
​
​
​
​
Update javadoc
10 years ago
Define manager interfaces and update all of Gitblit to use managers These manager interfaces define how the GitBlit singleton will eventually be split into smaller component managers. The Wicket app and all servlets have been updated to request the needed managers. There are _very_ few method signature changes - although there are a handful. This is a surgical sharding of responsibility based on a proof of concept refactor. Instead of random references to GittBlit.self() there are now precise references to the manager interface required to accomplish some task. Some tasks may require references to multiple managers. The code is now littered with calls to GitBlit.getManager(class) and those familiar with the code-base will no doubt notice the duplication of methods from IUserService in IUserManager and the addition of implementation methods in the GitBlit context class. When the GitBlit class is broken apart and the existing external authentication user service classes are refactored to AuthenticationService classes, this will again simplify and flatten. But in order to safely and cleanly modularize the stable code-base we will have to live with a little duplication for a short while. Change-Id: I7314ec8acaab2dcc6092785ed4434cc09fdbbe16
10 years ago
​
​
​
​
​
​
​
Update javadoc
10 years ago
Define manager interfaces and update all of Gitblit to use managers These manager interfaces define how the GitBlit singleton will eventually be split into smaller component managers. The Wicket app and all servlets have been updated to request the needed managers. There are _very_ few method signature changes - although there are a handful. This is a surgical sharding of responsibility based on a proof of concept refactor. Instead of random references to GittBlit.self() there are now precise references to the manager interface required to accomplish some task. Some tasks may require references to multiple managers. The code is now littered with calls to GitBlit.getManager(class) and those familiar with the code-base will no doubt notice the duplication of methods from IUserService in IUserManager and the addition of implementation methods in the GitBlit context class. When the GitBlit class is broken apart and the existing external authentication user service classes are refactored to AuthenticationService classes, this will again simplify and flatten. But in order to safely and cleanly modularize the stable code-base we will have to live with a little duplication for a short while. Change-Id: I7314ec8acaab2dcc6092785ed4434cc09fdbbe16
10 years ago
​
​
​
​
​
​
​
​
​
Update javadoc
10 years ago
Define manager interfaces and update all of Gitblit to use managers These manager interfaces define how the GitBlit singleton will eventually be split into smaller component managers. The Wicket app and all servlets have been updated to request the needed managers. There are _very_ few method signature changes - although there are a handful. This is a surgical sharding of responsibility based on a proof of concept refactor. Instead of random references to GittBlit.self() there are now precise references to the manager interface required to accomplish some task. Some tasks may require references to multiple managers. The code is now littered with calls to GitBlit.getManager(class) and those familiar with the code-base will no doubt notice the duplication of methods from IUserService in IUserManager and the addition of implementation methods in the GitBlit context class. When the GitBlit class is broken apart and the existing external authentication user service classes are refactored to AuthenticationService classes, this will again simplify and flatten. But in order to safely and cleanly modularize the stable code-base we will have to live with a little duplication for a short while. Change-Id: I7314ec8acaab2dcc6092785ed4434cc09fdbbe16
10 years ago
​
​
​
​
​
​
​
​
Update javadoc
10 years ago
Define manager interfaces and update all of Gitblit to use managers These manager interfaces define how the GitBlit singleton will eventually be split into smaller component managers. The Wicket app and all servlets have been updated to request the needed managers. There are _very_ few method signature changes - although there are a handful. This is a surgical sharding of responsibility based on a proof of concept refactor. Instead of random references to GittBlit.self() there are now precise references to the manager interface required to accomplish some task. Some tasks may require references to multiple managers. The code is now littered with calls to GitBlit.getManager(class) and those familiar with the code-base will no doubt notice the duplication of methods from IUserService in IUserManager and the addition of implementation methods in the GitBlit context class. When the GitBlit class is broken apart and the existing external authentication user service classes are refactored to AuthenticationService classes, this will again simplify and flatten. But in order to safely and cleanly modularize the stable code-base we will have to live with a little duplication for a short while. Change-Id: I7314ec8acaab2dcc6092785ed4434cc09fdbbe16
10 years ago
​
​
​
​
​
​
​
Update javadoc
10 years ago
Define manager interfaces and update all of Gitblit to use managers These manager interfaces define how the GitBlit singleton will eventually be split into smaller component managers. The Wicket app and all servlets have been updated to request the needed managers. There are _very_ few method signature changes - although there are a handful. This is a surgical sharding of responsibility based on a proof of concept refactor. Instead of random references to GittBlit.self() there are now precise references to the manager interface required to accomplish some task. Some tasks may require references to multiple managers. The code is now littered with calls to GitBlit.getManager(class) and those familiar with the code-base will no doubt notice the duplication of methods from IUserService in IUserManager and the addition of implementation methods in the GitBlit context class. When the GitBlit class is broken apart and the existing external authentication user service classes are refactored to AuthenticationService classes, this will again simplify and flatten. But in order to safely and cleanly modularize the stable code-base we will have to live with a little duplication for a short while. Change-Id: I7314ec8acaab2dcc6092785ed4434cc09fdbbe16
10 years ago
​
​
​
​
​
​
​
Update javadoc
10 years ago
Define manager interfaces and update all of Gitblit to use managers These manager interfaces define how the GitBlit singleton will eventually be split into smaller component managers. The Wicket app and all servlets have been updated to request the needed managers. There are _very_ few method signature changes - although there are a handful. This is a surgical sharding of responsibility based on a proof of concept refactor. Instead of random references to GittBlit.self() there are now precise references to the manager interface required to accomplish some task. Some tasks may require references to multiple managers. The code is now littered with calls to GitBlit.getManager(class) and those familiar with the code-base will no doubt notice the duplication of methods from IUserService in IUserManager and the addition of implementation methods in the GitBlit context class. When the GitBlit class is broken apart and the existing external authentication user service classes are refactored to AuthenticationService classes, this will again simplify and flatten. But in order to safely and cleanly modularize the stable code-base we will have to live with a little duplication for a short while. Change-Id: I7314ec8acaab2dcc6092785ed4434cc09fdbbe16
10 years ago
​
​
​
​
​
​
​
​
Update javadoc
10 years ago
Define manager interfaces and update all of Gitblit to use managers These manager interfaces define how the GitBlit singleton will eventually be split into smaller component managers. The Wicket app and all servlets have been updated to request the needed managers. There are _very_ few method signature changes - although there are a handful. This is a surgical sharding of responsibility based on a proof of concept refactor. Instead of random references to GittBlit.self() there are now precise references to the manager interface required to accomplish some task. Some tasks may require references to multiple managers. The code is now littered with calls to GitBlit.getManager(class) and those familiar with the code-base will no doubt notice the duplication of methods from IUserService in IUserManager and the addition of implementation methods in the GitBlit context class. When the GitBlit class is broken apart and the existing external authentication user service classes are refactored to AuthenticationService classes, this will again simplify and flatten. But in order to safely and cleanly modularize the stable code-base we will have to live with a little duplication for a short while. Change-Id: I7314ec8acaab2dcc6092785ed4434cc09fdbbe16
10 years ago
​
​
​
​
​
​
​
​
​
Update javadoc
10 years ago
Define manager interfaces and update all of Gitblit to use managers These manager interfaces define how the GitBlit singleton will eventually be split into smaller component managers. The Wicket app and all servlets have been updated to request the needed managers. There are _very_ few method signature changes - although there are a handful. This is a surgical sharding of responsibility based on a proof of concept refactor. Instead of random references to GittBlit.self() there are now precise references to the manager interface required to accomplish some task. Some tasks may require references to multiple managers. The code is now littered with calls to GitBlit.getManager(class) and those familiar with the code-base will no doubt notice the duplication of methods from IUserService in IUserManager and the addition of implementation methods in the GitBlit context class. When the GitBlit class is broken apart and the existing external authentication user service classes are refactored to AuthenticationService classes, this will again simplify and flatten. But in order to safely and cleanly modularize the stable code-base we will have to live with a little duplication for a short while. Change-Id: I7314ec8acaab2dcc6092785ed4434cc09fdbbe16
10 years ago
​
​
​
​
​
​
​
​
​
Update javadoc
10 years ago
Define manager interfaces and update all of Gitblit to use managers These manager interfaces define how the GitBlit singleton will eventually be split into smaller component managers. The Wicket app and all servlets have been updated to request the needed managers. There are _very_ few method signature changes - although there are a handful. This is a surgical sharding of responsibility based on a proof of concept refactor. Instead of random references to GittBlit.self() there are now precise references to the manager interface required to accomplish some task. Some tasks may require references to multiple managers. The code is now littered with calls to GitBlit.getManager(class) and those familiar with the code-base will no doubt notice the duplication of methods from IUserService in IUserManager and the addition of implementation methods in the GitBlit context class. When the GitBlit class is broken apart and the existing external authentication user service classes are refactored to AuthenticationService classes, this will again simplify and flatten. But in order to safely and cleanly modularize the stable code-base we will have to live with a little duplication for a short while. Change-Id: I7314ec8acaab2dcc6092785ed4434cc09fdbbe16
10 years ago
​
​
​
​
​
​
​
​
Update javadoc
10 years ago
Define manager interfaces and update all of Gitblit to use managers These manager interfaces define how the GitBlit singleton will eventually be split into smaller component managers. The Wicket app and all servlets have been updated to request the needed managers. There are _very_ few method signature changes - although there are a handful. This is a surgical sharding of responsibility based on a proof of concept refactor. Instead of random references to GittBlit.self() there are now precise references to the manager interface required to accomplish some task. Some tasks may require references to multiple managers. The code is now littered with calls to GitBlit.getManager(class) and those familiar with the code-base will no doubt notice the duplication of methods from IUserService in IUserManager and the addition of implementation methods in the GitBlit context class. When the GitBlit class is broken apart and the existing external authentication user service classes are refactored to AuthenticationService classes, this will again simplify and flatten. But in order to safely and cleanly modularize the stable code-base we will have to live with a little duplication for a short while. Change-Id: I7314ec8acaab2dcc6092785ed4434cc09fdbbe16
10 years ago
​
​
​
​
​
​
​
​
​
​
Update javadoc
10 years ago
Define manager interfaces and update all of Gitblit to use managers These manager interfaces define how the GitBlit singleton will eventually be split into smaller component managers. The Wicket app and all servlets have been updated to request the needed managers. There are _very_ few method signature changes - although there are a handful. This is a surgical sharding of responsibility based on a proof of concept refactor. Instead of random references to GittBlit.self() there are now precise references to the manager interface required to accomplish some task. Some tasks may require references to multiple managers. The code is now littered with calls to GitBlit.getManager(class) and those familiar with the code-base will no doubt notice the duplication of methods from IUserService in IUserManager and the addition of implementation methods in the GitBlit context class. When the GitBlit class is broken apart and the existing external authentication user service classes are refactored to AuthenticationService classes, this will again simplify and flatten. But in order to safely and cleanly modularize the stable code-base we will have to live with a little duplication for a short while. Change-Id: I7314ec8acaab2dcc6092785ed4434cc09fdbbe16
10 years ago
​
​
​
​
​
​
​
​
​
​
​
Update javadoc
10 years ago
Define manager interfaces and update all of Gitblit to use managers These manager interfaces define how the GitBlit singleton will eventually be split into smaller component managers. The Wicket app and all servlets have been updated to request the needed managers. There are _very_ few method signature changes - although there are a handful. This is a surgical sharding of responsibility based on a proof of concept refactor. Instead of random references to GittBlit.self() there are now precise references to the manager interface required to accomplish some task. Some tasks may require references to multiple managers. The code is now littered with calls to GitBlit.getManager(class) and those familiar with the code-base will no doubt notice the duplication of methods from IUserService in IUserManager and the addition of implementation methods in the GitBlit context class. When the GitBlit class is broken apart and the existing external authentication user service classes are refactored to AuthenticationService classes, this will again simplify and flatten. But in order to safely and cleanly modularize the stable code-base we will have to live with a little duplication for a short while. Change-Id: I7314ec8acaab2dcc6092785ed4434cc09fdbbe16
10 years ago
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
Update javadoc
10 years ago
Define manager interfaces and update all of Gitblit to use managers These manager interfaces define how the GitBlit singleton will eventually be split into smaller component managers. The Wicket app and all servlets have been updated to request the needed managers. There are _very_ few method signature changes - although there are a handful. This is a surgical sharding of responsibility based on a proof of concept refactor. Instead of random references to GittBlit.self() there are now precise references to the manager interface required to accomplish some task. Some tasks may require references to multiple managers. The code is now littered with calls to GitBlit.getManager(class) and those familiar with the code-base will no doubt notice the duplication of methods from IUserService in IUserManager and the addition of implementation methods in the GitBlit context class. When the GitBlit class is broken apart and the existing external authentication user service classes are refactored to AuthenticationService classes, this will again simplify and flatten. But in order to safely and cleanly modularize the stable code-base we will have to live with a little duplication for a short while. Change-Id: I7314ec8acaab2dcc6092785ed4434cc09fdbbe16
10 years ago
​
​
​
​
​
​
​
​
​
​
Update javadoc
10 years ago
Define manager interfaces and update all of Gitblit to use managers These manager interfaces define how the GitBlit singleton will eventually be split into smaller component managers. The Wicket app and all servlets have been updated to request the needed managers. There are _very_ few method signature changes - although there are a handful. This is a surgical sharding of responsibility based on a proof of concept refactor. Instead of random references to GittBlit.self() there are now precise references to the manager interface required to accomplish some task. Some tasks may require references to multiple managers. The code is now littered with calls to GitBlit.getManager(class) and those familiar with the code-base will no doubt notice the duplication of methods from IUserService in IUserManager and the addition of implementation methods in the GitBlit context class. When the GitBlit class is broken apart and the existing external authentication user service classes are refactored to AuthenticationService classes, this will again simplify and flatten. But in order to safely and cleanly modularize the stable code-base we will have to live with a little duplication for a short while. Change-Id: I7314ec8acaab2dcc6092785ed4434cc09fdbbe16
10 years ago
​
​
​
​
​
​
​
​
Update javadoc
10 years ago
Define manager interfaces and update all of Gitblit to use managers These manager interfaces define how the GitBlit singleton will eventually be split into smaller component managers. The Wicket app and all servlets have been updated to request the needed managers. There are _very_ few method signature changes - although there are a handful. This is a surgical sharding of responsibility based on a proof of concept refactor. Instead of random references to GittBlit.self() there are now precise references to the manager interface required to accomplish some task. Some tasks may require references to multiple managers. The code is now littered with calls to GitBlit.getManager(class) and those familiar with the code-base will no doubt notice the duplication of methods from IUserService in IUserManager and the addition of implementation methods in the GitBlit context class. When the GitBlit class is broken apart and the existing external authentication user service classes are refactored to AuthenticationService classes, this will again simplify and flatten. But in order to safely and cleanly modularize the stable code-base we will have to live with a little duplication for a short while. Change-Id: I7314ec8acaab2dcc6092785ed4434cc09fdbbe16
10 years ago
​
​
​
​
​
​
​
​
Update javadoc
10 years ago
Define manager interfaces and update all of Gitblit to use managers These manager interfaces define how the GitBlit singleton will eventually be split into smaller component managers. The Wicket app and all servlets have been updated to request the needed managers. There are _very_ few method signature changes - although there are a handful. This is a surgical sharding of responsibility based on a proof of concept refactor. Instead of random references to GittBlit.self() there are now precise references to the manager interface required to accomplish some task. Some tasks may require references to multiple managers. The code is now littered with calls to GitBlit.getManager(class) and those familiar with the code-base will no doubt notice the duplication of methods from IUserService in IUserManager and the addition of implementation methods in the GitBlit context class. When the GitBlit class is broken apart and the existing external authentication user service classes are refactored to AuthenticationService classes, this will again simplify and flatten. But in order to safely and cleanly modularize the stable code-base we will have to live with a little duplication for a short while. Change-Id: I7314ec8acaab2dcc6092785ed4434cc09fdbbe16
10 years ago
​
​
​
​
​
​
​
Update javadoc
10 years ago
Define manager interfaces and update all of Gitblit to use managers These manager interfaces define how the GitBlit singleton will eventually be split into smaller component managers. The Wicket app and all servlets have been updated to request the needed managers. There are _very_ few method signature changes - although there are a handful. This is a surgical sharding of responsibility based on a proof of concept refactor. Instead of random references to GittBlit.self() there are now precise references to the manager interface required to accomplish some task. Some tasks may require references to multiple managers. The code is now littered with calls to GitBlit.getManager(class) and those familiar with the code-base will no doubt notice the duplication of methods from IUserService in IUserManager and the addition of implementation methods in the GitBlit context class. When the GitBlit class is broken apart and the existing external authentication user service classes are refactored to AuthenticationService classes, this will again simplify and flatten. But in order to safely and cleanly modularize the stable code-base we will have to live with a little duplication for a short while. Change-Id: I7314ec8acaab2dcc6092785ed4434cc09fdbbe16
10 years ago
​
​
​
​
​
​
​
​
​
Update javadoc
10 years ago
Define manager interfaces and update all of Gitblit to use managers These manager interfaces define how the GitBlit singleton will eventually be split into smaller component managers. The Wicket app and all servlets have been updated to request the needed managers. There are _very_ few method signature changes - although there are a handful. This is a surgical sharding of responsibility based on a proof of concept refactor. Instead of random references to GittBlit.self() there are now precise references to the manager interface required to accomplish some task. Some tasks may require references to multiple managers. The code is now littered with calls to GitBlit.getManager(class) and those familiar with the code-base will no doubt notice the duplication of methods from IUserService in IUserManager and the addition of implementation methods in the GitBlit context class. When the GitBlit class is broken apart and the existing external authentication user service classes are refactored to AuthenticationService classes, this will again simplify and flatten. But in order to safely and cleanly modularize the stable code-base we will have to live with a little duplication for a short while. Change-Id: I7314ec8acaab2dcc6092785ed4434cc09fdbbe16
10 years ago
​
​
​
​
​
​
​
​
​
​
Update javadoc
10 years ago
Define manager interfaces and update all of Gitblit to use managers These manager interfaces define how the GitBlit singleton will eventually be split into smaller component managers. The Wicket app and all servlets have been updated to request the needed managers. There are _very_ few method signature changes - although there are a handful. This is a surgical sharding of responsibility based on a proof of concept refactor. Instead of random references to GittBlit.self() there are now precise references to the manager interface required to accomplish some task. Some tasks may require references to multiple managers. The code is now littered with calls to GitBlit.getManager(class) and those familiar with the code-base will no doubt notice the duplication of methods from IUserService in IUserManager and the addition of implementation methods in the GitBlit context class. When the GitBlit class is broken apart and the existing external authentication user service classes are refactored to AuthenticationService classes, this will again simplify and flatten. But in order to safely and cleanly modularize the stable code-base we will have to live with a little duplication for a short while. Change-Id: I7314ec8acaab2dcc6092785ed4434cc09fdbbe16
10 years ago
​
​
​
​
​
​
​
​
​
Update javadoc
10 years ago
Define manager interfaces and update all of Gitblit to use managers These manager interfaces define how the GitBlit singleton will eventually be split into smaller component managers. The Wicket app and all servlets have been updated to request the needed managers. There are _very_ few method signature changes - although there are a handful. This is a surgical sharding of responsibility based on a proof of concept refactor. Instead of random references to GittBlit.self() there are now precise references to the manager interface required to accomplish some task. Some tasks may require references to multiple managers. The code is now littered with calls to GitBlit.getManager(class) and those familiar with the code-base will no doubt notice the duplication of methods from IUserService in IUserManager and the addition of implementation methods in the GitBlit context class. When the GitBlit class is broken apart and the existing external authentication user service classes are refactored to AuthenticationService classes, this will again simplify and flatten. But in order to safely and cleanly modularize the stable code-base we will have to live with a little duplication for a short while. Change-Id: I7314ec8acaab2dcc6092785ed4434cc09fdbbe16
10 years ago
​
​
​
​
​
​
​
​
​
​
Update javadoc
10 years ago
Define manager interfaces and update all of Gitblit to use managers These manager interfaces define how the GitBlit singleton will eventually be split into smaller component managers. The Wicket app and all servlets have been updated to request the needed managers. There are _very_ few method signature changes - although there are a handful. This is a surgical sharding of responsibility based on a proof of concept refactor. Instead of random references to GittBlit.self() there are now precise references to the manager interface required to accomplish some task. Some tasks may require references to multiple managers. The code is now littered with calls to GitBlit.getManager(class) and those familiar with the code-base will no doubt notice the duplication of methods from IUserService in IUserManager and the addition of implementation methods in the GitBlit context class. When the GitBlit class is broken apart and the existing external authentication user service classes are refactored to AuthenticationService classes, this will again simplify and flatten. But in order to safely and cleanly modularize the stable code-base we will have to live with a little duplication for a short while. Change-Id: I7314ec8acaab2dcc6092785ed4434cc09fdbbe16
10 years ago
​
​
​
​
​
​
​
​
​
Update javadoc
10 years ago
​
Define manager interfaces and update all of Gitblit to use managers These manager interfaces define how the GitBlit singleton will eventually be split into smaller component managers. The Wicket app and all servlets have been updated to request the needed managers. There are _very_ few method signature changes - although there are a handful. This is a surgical sharding of responsibility based on a proof of concept refactor. Instead of random references to GittBlit.self() there are now precise references to the manager interface required to accomplish some task. Some tasks may require references to multiple managers. The code is now littered with calls to GitBlit.getManager(class) and those familiar with the code-base will no doubt notice the duplication of methods from IUserService in IUserManager and the addition of implementation methods in the GitBlit context class. When the GitBlit class is broken apart and the existing external authentication user service classes are refactored to AuthenticationService classes, this will again simplify and flatten. But in order to safely and cleanly modularize the stable code-base we will have to live with a little duplication for a short while. Change-Id: I7314ec8acaab2dcc6092785ed4434cc09fdbbe16
10 years ago
​
​
​
​
​
Update javadoc
10 years ago
Define manager interfaces and update all of Gitblit to use managers These manager interfaces define how the GitBlit singleton will eventually be split into smaller component managers. The Wicket app and all servlets have been updated to request the needed managers. There are _very_ few method signature changes - although there are a handful. This is a surgical sharding of responsibility based on a proof of concept refactor. Instead of random references to GittBlit.self() there are now precise references to the manager interface required to accomplish some task. Some tasks may require references to multiple managers. The code is now littered with calls to GitBlit.getManager(class) and those familiar with the code-base will no doubt notice the duplication of methods from IUserService in IUserManager and the addition of implementation methods in the GitBlit context class. When the GitBlit class is broken apart and the existing external authentication user service classes are refactored to AuthenticationService classes, this will again simplify and flatten. But in order to safely and cleanly modularize the stable code-base we will have to live with a little duplication for a short while. Change-Id: I7314ec8acaab2dcc6092785ed4434cc09fdbbe16
10 years ago
​
​
​
​
​
​
​
Update javadoc
10 years ago
Define manager interfaces and update all of Gitblit to use managers These manager interfaces define how the GitBlit singleton will eventually be split into smaller component managers. The Wicket app and all servlets have been updated to request the needed managers. There are _very_ few method signature changes - although there are a handful. This is a surgical sharding of responsibility based on a proof of concept refactor. Instead of random references to GittBlit.self() there are now precise references to the manager interface required to accomplish some task. Some tasks may require references to multiple managers. The code is now littered with calls to GitBlit.getManager(class) and those familiar with the code-base will no doubt notice the duplication of methods from IUserService in IUserManager and the addition of implementation methods in the GitBlit context class. When the GitBlit class is broken apart and the existing external authentication user service classes are refactored to AuthenticationService classes, this will again simplify and flatten. But in order to safely and cleanly modularize the stable code-base we will have to live with a little duplication for a short while. Change-Id: I7314ec8acaab2dcc6092785ed4434cc09fdbbe16
10 years ago
​
​
Move GarbageCollector repository methods to the RepositoryManager
10 years ago
​
​
Update javadoc
10 years ago
Move GarbageCollector repository methods to the RepositoryManager
10 years ago
​
​
​
​
​
Update javadoc
10 years ago
Move GarbageCollector repository methods to the RepositoryManager
10 years ago
​
​
​
​
​
​
​
Update javadoc
10 years ago
Move GarbageCollector repository methods to the RepositoryManager
10 years ago
​
Define manager interfaces and update all of Gitblit to use managers These manager interfaces define how the GitBlit singleton will eventually be split into smaller component managers. The Wicket app and all servlets have been updated to request the needed managers. There are _very_ few method signature changes - although there are a handful. This is a surgical sharding of responsibility based on a proof of concept refactor. Instead of random references to GittBlit.self() there are now precise references to the manager interface required to accomplish some task. Some tasks may require references to multiple managers. The code is now littered with calls to GitBlit.getManager(class) and those familiar with the code-base will no doubt notice the duplication of methods from IUserService in IUserManager and the addition of implementation methods in the GitBlit context class. When the GitBlit class is broken apart and the existing external authentication user service classes are refactored to AuthenticationService classes, this will again simplify and flatten. But in order to safely and cleanly modularize the stable code-base we will have to live with a little duplication for a short while. Change-Id: I7314ec8acaab2dcc6092785ed4434cc09fdbbe16
10 years ago
 123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327328329330331332333334335336337338339340341342343344345346347348349350351352353354355356357358359360361362363364365366367368369370371372373374375376377378379380381382383384385386387388389390391392393394395396397398399400401402403404405406407408409410411412413414415416417418419420421422423424425426427428429430431432433434435436437438439440441442443444445446447448449450451452453454455456457458459460461462463464465466 
  1. /*

  2.  * Copyright 2013 gitblit.com.

  3.  *

  4.  * Licensed under the Apache License, Version 2.0 (the "License");

  5.  * you may not use this file except in compliance with the License.

  6.  * You may obtain a copy of the License at

  7.  *

  8.  *     http://www.apache.org/licenses/LICENSE-2.0

  9.  *

  10.  * Unless required by applicable law or agreed to in writing, software

  11.  * distributed under the License is distributed on an "AS IS" BASIS,

  12.  * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.

  13.  * See the License for the specific language governing permissions and

  14.  * limitations under the License.

  15.  */

  16. package com.gitblit.manager;

  17. 

  18. import java.io.File;

  19. import java.util.Collection;

  20. import java.util.Date;

  21. import java.util.List;

  22. 

  23. import org.eclipse.jgit.lib.Repository;

  24. 

  25. import com.gitblit.GitBlitException;

  26. import com.gitblit.models.ForkModel;

  27. import com.gitblit.models.Metric;

  28. import com.gitblit.models.RegistrantAccessPermission;

  29. import com.gitblit.models.RepositoryModel;

  30. import com.gitblit.models.SearchResult;

  31. import com.gitblit.models.UserModel;

  32. 

  33. public interface IRepositoryManager extends IManager {

  34. 

  35. 	/**

  36. 	 * Returns the path of the repositories folder. This method checks to see if

  37. 	 * Gitblit is running on a cloud service and may return an adjusted path.

  38. 	 *

  39. 	 * @return the repositories folder path

  40.  	 * @since 1.4.0

  41. 	 */

  42. 	File getRepositoriesFolder();

  43. 

  44. 	/**

  45. 	 * Returns the path of the hooks folder. This method checks to see if

  46. 	 * Gitblit is running on a cloud service and may return an adjusted path.

  47. 	 *

  48. 	 * @return the Groovy hook scripts folder path

  49.  	 * @since 1.4.0

  50. 	 */

  51. 	File getHooksFolder();

  52. 

  53. 	/**

  54. 	 * Returns the path of the grapes folder. This method checks to see if

  55. 	 * Gitblit is running on a cloud service and may return an adjusted path.

  56. 	 *

  57. 	 * @return the Groovy grapes folder path

  58.  	 * @since 1.4.0

  59. 	 */

  60. 	File getGrapesFolder();

  61. 

  62. 	/**

  63. 	 * Returns the most recent change date of any repository served by Gitblit.

  64. 	 *

  65. 	 * @return a date

  66.  	 * @since 1.4.0

  67. 	 */

  68. 	Date getLastActivityDate();

  69. 

  70. 	/**

  71. 	 * Returns the effective list of permissions for this user, taking into account

  72. 	 * team memberships, ownerships.

  73. 	 *

  74. 	 * @param user

  75. 	 * @return the effective list of permissions for the user

  76.  	 * @since 1.4.0

  77. 	 */

  78. 	List<RegistrantAccessPermission> getUserAccessPermissions(UserModel user);

  79. 

  80. 	/**

  81. 	 * Returns the list of users and their access permissions for the specified

  82. 	 * repository including permission source information such as the team or

  83. 	 * regular expression which sets the permission.

  84. 	 *

  85. 	 * @param repository

  86. 	 * @return a list of RegistrantAccessPermissions

  87.  	 * @since 1.4.0

  88. 	 */

  89. 	List<RegistrantAccessPermission> getUserAccessPermissions(RepositoryModel repository);

  90. 

  91. 	/**

  92. 	 * Sets the access permissions to the specified repository for the specified users.

  93. 	 *

  94. 	 * @param repository

  95. 	 * @param permissions

  96. 	 * @return true if the user models have been updated

  97.  	 * @since 1.4.0

  98. 	 */

  99. 	boolean setUserAccessPermissions(RepositoryModel repository, Collection<RegistrantAccessPermission> permissions);

  100. 

  101. 	/**

  102. 	 * Returns the list of all users who have an explicit access permission

  103. 	 * for the specified repository.

  104. 	 *

  105. 	 * @see IUserService.getUsernamesForRepositoryRole(String)

  106. 	 * @param repository

  107. 	 * @return list of all usernames that have an access permission for the repository

  108.  	 * @since 1.4.0

  109. 	 */

  110. 	List<String> getRepositoryUsers(RepositoryModel repository);

  111. 

  112. 	/**

  113. 	 * Returns the list of teams and their access permissions for the specified

  114. 	 * repository including the source of the permission such as the admin flag

  115. 	 * or a regular expression.

  116. 	 *

  117. 	 * @param repository

  118. 	 * @return a list of RegistrantAccessPermissions

  119.  	 * @since 1.4.0

  120. 	 */

  121. 	List<RegistrantAccessPermission> getTeamAccessPermissions(RepositoryModel repository);

  122. 

  123. 	/**

  124. 	 * Sets the access permissions to the specified repository for the specified teams.

  125. 	 *

  126. 	 * @param repository

  127. 	 * @param permissions

  128. 	 * @return true if the team models have been updated

  129.  	 * @since 1.4.0

  130. 	 */

  131. 	boolean setTeamAccessPermissions(RepositoryModel repository, Collection<RegistrantAccessPermission> permissions);

  132. 

  133. 	/**

  134. 	 * Returns the list of all teams who have an explicit access permission for

  135. 	 * the specified repository.

  136. 	 *

  137. 	 * @see IUserService.getTeamnamesForRepositoryRole(String)

  138. 	 * @param repository

  139. 	 * @return list of all teamnames with explicit access permissions to the repository

  140.  	 * @since 1.4.0

  141. 	 */

  142. 	List<String> getRepositoryTeams(RepositoryModel repository);

  143. 

  144. 	/**

  145. 	 * Adds the repository to the list of cached repositories if Gitblit is

  146. 	 * configured to cache the repository list.

  147. 	 *

  148. 	 * @param model

  149.  	 * @since 1.4.0

  150. 	 */

  151. 	void addToCachedRepositoryList(RepositoryModel model);

  152. 

  153. 	/**

  154. 	 * Resets the repository list cache.

  155. 	 *

  156.  	 * @since 1.4.0

  157. 	 *

  158. 	 */

  159. 	void resetRepositoryListCache();

  160. 

  161. 	/**

  162. 	 * Reset all caches for this repository.

  163. 	 *

  164. 	 * @param repositoryName

  165. 	 * @since 1.5.1

  166. 	 */

  167. 	void resetRepositoryCache(String repositoryName);

  168. 

  169. 	/**

  170. 	 * Returns the list of all repositories available to Gitblit. This method

  171. 	 * does not consider user access permissions.

  172. 	 *

  173. 	 * @return list of all repositories

  174.  	 * @since 1.4.0

  175. 	 */

  176. 	List<String> getRepositoryList();

  177. 

  178. 	/**

  179. 	 * Returns the JGit repository for the specified name.

  180. 	 *

  181. 	 * @param repositoryName

  182. 	 * @return repository or null

  183.  	 * @since 1.4.0

  184. 	 */

  185. 	Repository getRepository(String repositoryName);

  186. 

  187. 	/**

  188. 	 * Returns the JGit repository for the specified name.

  189. 	 *

  190. 	 * @param repositoryName

  191. 	 * @param logError

  192. 	 * @return repository or null

  193.  	 * @since 1.4.0

  194. 	 */

  195. 	Repository getRepository(String repositoryName, boolean logError);

  196. 

  197. 	/**

  198. 	 * Returns the list of repository models that are accessible to the user.

  199. 	 *

  200. 	 * @param user

  201. 	 * @return list of repository models accessible to user

  202.  	 * @since 1.4.0

  203. 	 */

  204. 	List<RepositoryModel> getRepositoryModels(UserModel user);

  205. 

  206. 	/**

  207. 	 * Returns a repository model if the repository exists and the user may

  208. 	 * access the repository.

  209. 	 *

  210. 	 * @param user

  211. 	 * @param repositoryName

  212. 	 * @return repository model or null

  213.  	 * @since 1.4.0

  214. 	 */

  215. 	RepositoryModel getRepositoryModel(UserModel user, String repositoryName);

  216. 

  217. 	/**

  218. 	 * Returns the repository model for the specified repository. This method

  219. 	 * does not consider user access permissions.

  220. 	 *

  221. 	 * @param repositoryName

  222. 	 * @return repository model or null

  223.  	 * @since 1.4.0

  224. 	 */

  225. 	RepositoryModel getRepositoryModel(String repositoryName);

  226. 

  227. 	/**

  228. 	 * Returns the star count of the repository.

  229. 	 *

  230. 	 * @param repository

  231. 	 * @return the star count

  232.  	 * @since 1.4.0

  233. 	 */

  234. 	long getStarCount(RepositoryModel repository);

  235. 

  236. 	/**

  237. 	 * Determines if this server has the requested repository.

  238. 	 *

  239. 	 * @param n

  240. 	 * @return true if the repository exists

  241.  	 * @since 1.4.0

  242. 	 */

  243. 	boolean hasRepository(String repositoryName);

  244. 

  245. 	/**

  246. 	 * Determines if this server has the requested repository.

  247. 	 *

  248. 	 * @param n

  249. 	 * @param caseInsensitive

  250. 	 * @return true if the repository exists

  251.  	 * @since 1.4.0

  252. 	 */

  253. 	boolean hasRepository(String repositoryName, boolean caseSensitiveCheck);

  254. 

  255. 	/**

  256. 	 * Determines if the specified user has a fork of the specified origin

  257. 	 * repository.

  258. 	 *

  259. 	 * @param username

  260. 	 * @param origin

  261. 	 * @return true the if the user has a fork

  262.  	 * @since 1.4.0

  263. 	 */

  264. 	boolean hasFork(String username, String origin);

  265. 

  266. 	/**

  267. 	 * Gets the name of a user's fork of the specified origin

  268. 	 * repository.

  269. 	 *

  270. 	 * @param username

  271. 	 * @param origin

  272. 	 * @return the name of the user's fork, null otherwise

  273.  	 * @since 1.4.0

  274. 	 */

  275. 	String getFork(String username, String origin);

  276. 

  277. 	/**

  278. 	 * Returns the fork network for a repository by traversing up the fork graph

  279. 	 * to discover the root and then down through all children of the root node.

  280. 	 *

  281. 	 * @param repository

  282. 	 * @return a ForkModel

  283.  	 * @since 1.4.0

  284. 	 */

  285. 	ForkModel getForkNetwork(String repository);

  286. 

  287. 	/**

  288. 	 * Updates the last changed fields and optionally calculates the size of the

  289. 	 * repository.  Gitblit caches the repository sizes to reduce the performance

  290. 	 * penalty of recursive calculation. The cache is updated if the repository

  291. 	 * has been changed since the last calculation.

  292. 	 *

  293. 	 * @param model

  294. 	 * @return size in bytes of the repository

  295.  	 * @since 1.4.0

  296. 	 */

  297. 	long updateLastChangeFields(Repository r, RepositoryModel model);

  298. 

  299. 	/**

  300. 	 * Returns the metrics for the default branch of the specified repository.

  301. 	 * This method builds a metrics cache. The cache is updated if the

  302. 	 * repository is updated. A new copy of the metrics list is returned on each

  303. 	 * call so that modifications to the list are non-destructive.

  304. 	 *

  305. 	 * @param model

  306. 	 * @param repository

  307. 	 * @return a new array list of metrics

  308.  	 * @since 1.4.0

  309. 	 */

  310. 	List<Metric> getRepositoryDefaultMetrics(RepositoryModel model, Repository repository);

  311. 

  312. 	/**

  313. 	 * Creates/updates the repository model keyed by reopsitoryName. Saves all

  314. 	 * repository settings in .git/config. This method allows for renaming

  315. 	 * repositories and will update user access permissions accordingly.

  316. 	 *

  317. 	 * All repositories created by this method are bare and automatically have

  318. 	 * .git appended to their names, which is the standard convention for bare

  319. 	 * repositories.

  320. 	 *

  321. 	 * @param repositoryName

  322. 	 * @param repository

  323. 	 * @param isCreate

  324. 	 * @throws GitBlitException

  325.  	 * @since 1.4.0

  326. 	 */

  327. 	void updateRepositoryModel(String repositoryName, RepositoryModel repository, boolean isCreate)

  328. 			throws GitBlitException;

  329. 

  330. 	/**

  331. 	 * Updates the Gitblit configuration for the specified repository.

  332. 	 *

  333. 	 * @param r

  334. 	 *            the Git repository

  335. 	 * @param repository

  336. 	 *            the Gitblit repository model

  337.  	 * @since 1.4.0

  338. 	 */

  339. 	void updateConfiguration(Repository r, RepositoryModel repository);

  340. 

  341. 	/**

  342. 	 * Deletes the repository from the file system and removes the repository

  343. 	 * permission from all repository users.

  344. 	 *

  345. 	 * @param model

  346. 	 * @return true if successful

  347.  	 * @since 1.4.0

  348. 	 */

  349. 	boolean deleteRepositoryModel(RepositoryModel model);

  350. 

  351. 	/**

  352. 	 * Deletes the repository from the file system and removes the repository

  353. 	 * permission from all repository users.

  354. 	 *

  355. 	 * @param repositoryName

  356. 	 * @return true if successful

  357.  	 * @since 1.4.0

  358. 	 */

  359. 	boolean deleteRepository(String repositoryName);

  360. 

  361. 	/**

  362. 	 * Returns the list of all Groovy push hook scripts. Script files must have

  363. 	 * .groovy extension

  364. 	 *

  365. 	 * @return list of available hook scripts

  366.  	 * @since 1.4.0

  367. 	 */

  368. 	List<String> getAllScripts();

  369. 

  370. 	/**

  371. 	 * Returns the list of pre-receive scripts the repository inherited from the

  372. 	 * global settings and team affiliations.

  373. 	 *

  374. 	 * @param repository

  375. 	 *            if null only the globally specified scripts are returned

  376. 	 * @return a list of scripts

  377.  	 * @since 1.4.0

  378. 	 */

  379. 	List<String> getPreReceiveScriptsInherited(RepositoryModel repository);

  380. 

  381. 	/**

  382. 	 * Returns the list of all available Groovy pre-receive push hook scripts

  383. 	 * that are not already inherited by the repository. Script files must have

  384. 	 * .groovy extension

  385. 	 *

  386. 	 * @param repository

  387. 	 *            optional parameter

  388. 	 * @return list of available hook scripts

  389.  	 * @since 1.4.0

  390. 	 */

  391. 	List<String> getPreReceiveScriptsUnused(RepositoryModel repository);

  392. 

  393. 	/**

  394. 	 * Returns the list of post-receive scripts the repository inherited from

  395. 	 * the global settings and team affiliations.

  396. 	 *

  397. 	 * @param repository

  398. 	 *            if null only the globally specified scripts are returned

  399. 	 * @return a list of scripts

  400.  	 * @since 1.4.0

  401. 	 */

  402. 	List<String> getPostReceiveScriptsInherited(RepositoryModel repository);

  403. 

  404. 	/**

  405. 	 * Returns the list of unused Groovy post-receive push hook scripts that are

  406. 	 * not already inherited by the repository. Script files must have .groovy

  407. 	 * extension

  408. 	 *

  409. 	 * @param repository

  410. 	 *            optional parameter

  411. 	 * @return list of available hook scripts

  412.  	 * @since 1.4.0

  413. 	 */

  414. 	List<String> getPostReceiveScriptsUnused(RepositoryModel repository);

  415. 

  416. 	/**

  417. 	 * Search the specified repositories using the Lucene query.

  418. 	 *

  419. 	 * @param query

  420. 	 * @param page

  421. 	 * @param pageSize

  422. 	 * @param repositories

  423. 	 * @return a list of search results

  424.  	 * @since 1.4.0

  425. 	 */

  426. 	List<SearchResult> search(String query, int page, int pageSize, List<String> repositories);

  427. 

  428. 	/**

  429. 	 *

  430. 	 * @return true if we are running the gc executor

  431.  	 * @since 1.4.0

  432. 	 */

  433. 	boolean isCollectingGarbage();

  434. 

  435. 	/**

  436. 	 * Returns true if Gitblit is actively collecting garbage in this repository.

  437. 	 *

  438. 	 * @param repositoryName

  439. 	 * @return true if actively collecting garbage

  440.  	 * @since 1.4.0

  441. 	 */

  442. 	boolean isCollectingGarbage(String repositoryName);

  443. 

  444. 	/**

  445. 	 * Ensures that all cached repositories are completely closed and their resources

  446. 	 * are properly released.

  447.  	 * @since 1.4.0

  448. 	 */

  449. 	void closeAll();

  450. 

  451. 	/**

  452. 	 * Ensures that a cached repository is completely closed and it's resources

  453. 	 * are properly released.

  454.  	 * @since 1.4.0

  455. 	 */

  456. 	void close(String repository);

  457. 

  458. 	/**

  459. 	 * Returns true if the repository is idle (not being accessed).

  460. 	 *

  461. 	 * @param repository

  462. 	 * @return true if the repository is idle

  463.  	 * @since 1.4.0

  464. 	 */

  465. 	boolean isIdle(Repository repository);

  466. }