I'm sorry, my mistake. The methods should have an input parameter tenant Id.
void addRepository (int tenantId); void provisionRepository (int tenantId); RepositoryInformation getReopsitoryInformation (int tenantId); On Sat, May 4, 2013 at 11:17 AM, Kishanthan Thangarajah <kishant...@wso2.com > wrote: > > > > On Fri, May 3, 2013 at 9:51 PM, Isuru Haththotuwa <isu...@wso2.com> wrote: > >> The modified interface abstraction to get repository information, create >> or add repositories will be as follows: >> >> Interface name: RepositoryManager >> >> Methods: >> >> void addRepository (); >> - add a repository created by a tenant. >> >> void provisionRepository (); >> - create a repository on behalf of a tenant. >> >> RepositoryInformation getReopsitoryInformation (); >> - retrieve repository information such as url, user name and >> password, etc. >> > > Doesn't this include the tenant-id as input? or how > to differentiate the repositories among tenants? > > > >> >> >> On Sun, Apr 28, 2013 at 10:58 PM, Isuru Haththotuwa <isu...@wso2.com>wrote: >> >>> The proposed interface for RepositoryInformationProvider tentatively >>> would have a single method: >>> >>> public RepositoryInformation getRepositoryInformation(int tenantId); >>> >>> RepositoryInformation instance would hold data of the remote repository >>> for the tenant, such as url, username, password, etc. >>> >>> >>> On Wed, Apr 24, 2013 at 4:13 PM, Pradeep Fernando <prad...@wso2.com>wrote: >>> >>>> >>>> Hi Isuru, >>>> >>>> On Wed, Apr 24, 2013 at 12:39 PM, Isuru Haththotuwa <isu...@wso2.com>wrote: >>>> >>>>> The main limitations with the current architecture related to >>>>> generalizing the implementation are identified as follows: >>>>> >>>>> 1. The dependency on S2 based environment to get the information about >>>>> the repositories for the tenants: >>>>> >>>>> A potential solution would be to abstract out the implementation for a >>>>> repository information provider so that it can manage both the single >>>>> repository (standard deployment), multiple repository (S2 / specialized >>>>> deployment) and any other scenarios. >>>>> >>>>> 2. Usage of deployment synchronization messages in standard and S2 >>>>> deployments: >>>>> >>>>> In the current implementation, the ADC will send a >>>>> GroupManagementCommand (a deployment synchronization message) when there >>>>> are updates in the repository. The standard Deployment Synchronization >>>>> message has been programatically disabled from the git based deployment >>>>> synchronizer component, which is an incorrect thing to do. >>>>> >>>>> It was decided to hold a separate discussion on this to come up with a >>>>> proper architecture for usage of deployment synchronization messages in >>>>> different environments (standard and S2 environment). >>>>> >>>> >>>> please go ahead and schedule. >>>> >>>>> >>>>> 3. Supporting ghost deployment of artifacts: >>>>> >>>>> Svn based deployment synchronizer supports ghost deployment of >>>>> artifacts through svn partial checkouts. Git doesn't support partial >>>>> checkouts, so this is a potential problem. There may be workarounds >>>>> available, need to research on this. >>>>> >>>>> >>>>> On Fri, Apr 19, 2013 at 6:21 PM, Isuru Haththotuwa <isu...@wso2.com>wrote: >>>>> >>>>>> The Git based Deployment Synchronizer developed for Stratos 2 >>>>>> supports Git repositories per tenant, which is a significant difference >>>>>> from other Deployment Synchronizers (SVN depsync, etc). Therefore Git >>>>>> Depsync has to query a service to obtain the git repository URLs and the >>>>>> credentials for the repositories for each tenant at run time. In the SVN >>>>>> depsync, a single repo is used and it's defined in the carbon.xml. >>>>>> >>>>>> Because of this, it is not possible to use the Git Depsync to in a >>>>>> normal worker manager separation, in a similar way as SVN Depsync. To use >>>>>> it in the worker manager separated setup, we can either create another >>>>>> component which is similar to SVN depsync which uses a single repository, >>>>>> or else generalize this implementation so that it can be used in both S2 >>>>>> scenario (with repos per tenant) and in normal worker manager separation >>>>>> (single repo). >>>>>> >>>>>> Thoughts? >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>> _______________________________________________ >>>> Architecture mailing list >>>> Architecture@wso2.org >>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>> >>>> >>> >>> >>> -- >>> Thanks and Regards, >>> >>> Isuru H. >>> >>> >>> >> >> >> -- >> Thanks and Regards, >> >> Isuru H. >> >> >> >> _______________________________________________ >> Architecture mailing list >> Architecture@wso2.org >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > *Kishanthan Thangarajah* > Software Engineer, > Development Technologies Team, > WSO2, Inc. > lean.enterprise.middleware > > Mobile - +94773426635 > Blog - *http://kishanthan.wordpress.com* > Twitter - *http://twitter.com/kishanthan* > > _______________________________________________ > Architecture mailing list > Architecture@wso2.org > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- Thanks and Regards, Isuru H.
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
