Community
Participate
Working Groups
Define an interface for Trac repositories with the following operations: * validate() * getTicket() * search() Provide an implementation for access through XML-RPC and query script (see bug 140512). These classes will compose the core and model package of the Mylar Trac plug-in.
Created attachment 44964 [details] mylar/context/zip
Created attachment 44965 [details] Core and model classes that compose repository abstraction layer
Created attachment 44966 [details] Tests for core and model classes
Patches applied. I will make a closer review tomorrow.
Created attachment 45026 [details] mylar/context/zip
I have added bug 148089 for the XML-RPC implementation and bug 148090 for query script implementation. The patch mylar-trac-abstract-core-patch.txt which is attached to this report needs to be merged first.
Created attachment 45027 [details] Abstract repository class and utility methods
Patches applied. The name AbstractTracRepository is a bit confusing, since we have the TaskRepository class. Could you rename this to something like TracServerFacade, since the role of the class is to be a Java facade to the XML RPC API of the server? Or perhaps TracXmlRpcFacade?
(In reply to comment #8) > The name AbstractTracRepository is a bit confusing, since we > have the TaskRepository class. Could you rename this to something like > TracServerFacade, since the role of the class is to be a Java facade to the XML > RPC API of the server? Or perhaps TracXmlRpcFacade? Yes, I agree. This is somewhat confusing. I will try to come up with a better name. TracServerFacade is a bit misleading as a single server can host multiple repositories and each AbstractTracRepository object represent a single repository.
Ups, looks like I accidentally assigned this bug to mylar-inbox by hitting the wrong control. Sorry. Mik, could you assign this report back to me?
Can you use TaskRepository for this? It can now handle generic attributes, and we will pull it out into a seperate plug-in that both bugzilla.core and trac.core stuff can depend on (in case you ever split that out of UI). Plug-in will probably be called mylar.tasks. Fyi, regarding my previous instructions, usually I should be the one closing your bugs, because that's how I know to update mylar-iplog.csv.
(In reply to comment #12) > Can you use TaskRepository for this? I probably could and get rid of AbstractTracRepository but I am planning to add more functionality such as caching of repository information (milestones, severities etc.) to the class in the future. From my understanding TaskRepository is more like a data container for information that needs to be held in memory all the time whereas instances of AbstractTracRepository are created when a connection to a repository is requested for the first time. How about AbstractTracClient or AbstractTracConnection? > Fyi, regarding my previous instructions, usually I should be the one closing > your bugs, because that's how I know to update mylar-iplog.csv. Alright, I will not close bugs unless specifically instructed to do so :). Did you notice my last comment on bug 148089?
Yup, I have committed the outstanding patch. Yes, TaskRepository does only hold the credential-related information, but the Bugzilla connector has a class for caching configuration data. So once you start doing that we should make that class a generic facility available from AbstractRepositoryConnector, e.g. something like IRepositorySettingsHandler which will provide that information, and which the generic repository support will cache for 'free'.
The attached patch contains fixes for the XML-RPC API changes. Please let me know if test cases still fail (which they should not). My plan is to implement the connector class next and add query support. When that has been done I will look into getting configuration data from the repository. A generic handler to cache this data would be great. I have closed bug 148090 as the query script core has been merged. I will attach a patch for renaming all XXXTracRepository classes to XXXTracClient to this report which should resolve this report.
Created attachment 45079 [details] Fix for multicall() API changes in Trac XML-RPC Plugin
Created attachment 45080 [details] Renames XXXTracRepository classes to XXXTracClient. Includes multicall() patch. Mik, let me know if TracClient is bad choice (so I can create a another patch for a different name). In that case the multicall() patch can be applied.
Patch applied. I still find Trac client a bit odd because I see the structure like this: - Task List -> Trac Connector (i.e. client) - 1..n Trac Repositories -> Trac Server Facade (i.e. client core) - 1..n Trac Server But go with what you have for now and let's discuss naming on Thursday's call, since we should make it consistent across connectors.
Should we mark this resolved and address future tasks on new bug reports?
Yes, this report can be closed.
Done.
