Community
Participate
Working Groups
create the new API for use xmlrpc instead of ctype=xml
Let's touch base how to best approach this before we start working on it. We already use XML-RPC to connect to Trac and it could make sense to extract a common layer that could be shared with Bugzilla.
(In reply to comment #1) > Let's touch base how to best approach this before we start working on it. We > already use XML-RPC to connect to Trac and it could make sense to extract a > common layer that could be shared with Bugzilla. > OK, but my first priority is actual to create the now needet Bugzilla Calls
Created attachment 141945 [details] POC Steffen, Rob here is what I implement until now. For Bugzilla, please look into https://bugzilla.mozilla.org/show_bug.cgi?id=504937 When we get this from Bugzilla we can implement the following - control if an user can request/set an flag - default QA and assigned to - Custom workflow - Custom Fields That Only Appear When Another Field Has a Particular Value - Custom Fields Whose List of Values Change Depending on the Value of Another Field We should look what we can share between Trac and Bugzilla for the real implementation. Thoughts?
Created attachment 141946 [details] mylyn/context/zip
Wow this is really awesome Frank...and looks like you're making progress on 504937 with bugzilla.org which is excellent! I'll talk with Steffen and we'll post a high level follow up on how we see the overlap between connectors being abstracted.
Created attachment 149279 [details] next version of POC Steffen, Rob, can you please look if this is the right direction. Your comments are welcome.
Created attachment 149280 [details] mylyn/context/zip
Frank, I'll try to make some progress on the common XML-RPC access layer soon. You can basically assume that the XML-RPC client implementation will provide a method similar to this: public Object call(IProgressMonitor monitor, String method, Object... parameters) throws XmlRpcException;
Created attachment 164474 [details] commited patch V1 Because all is new I commit this. If you want run the junit test please change 1) TEST_REPO to your Bugzilla 3.6rc1 or greater 2) change AuthenticationType.REPOSITORY 3) you must change or remove AuthenticationType.HTTP
Created attachment 164475 [details] mylyn/context/zip
Frank, the commited changes break the weekly build since the referenced org.apache.xmlrpc library is currently not distributed from the main update site. Generally, we have to be careful with adding dependencies to tasks.core since it affects re-usability of the tasks framework. Please always get me or Rob to review before committing changes to the manifest of tasks framework plug-ins. We'll need to revert the changes in tasks.core and create a new plug-in that provides a generic the XML-RPC layer. I'll try to get around to this in the next couple of days to unblock your progress.
(In reply to comment #11) > Frank, the commited changes break the weekly build since the referenced > org.apache.xmlrpc library is currently not distributed from the main update > site. Generally, we have to be careful with adding dependencies to tasks.core > since it affects re-usability of the tasks framework. Please always get me or > Rob to review before committing changes to the manifest of tasks framework > plug-ins. Sorry I did not know this. The next time I will give it to review. > > We'll need to revert the changes in tasks.core and create a new plug-in that > provides a generic the XML-RPC layer. I'll try to get around to this in the next > couple of days to unblock your progress.
(In reply to comment #11) > Frank, the commited changes break the weekly build since the referenced > org.apache.xmlrpc library is currently not distributed from the main update > site. Generally, we have to be careful with adding dependencies to tasks.core > since it affects re-usability of the tasks framework. Please always get me or > Rob to review before committing changes to the manifest of tasks framework > plug-ins. > > We'll need to revert the changes in tasks.core and create a new plug-in that > provides a generic the XML-RPC layer. I'll try to get around to this in the next > couple of days to unblock your progress. commited version is now reverted!
No worries and thanks for fixing it. I have made some progress on bug 308737 and hope that I'll be able to check in a first version of the new org.eclipse.mylyn.commons.xmlrpc plug-in tomorrow.
Created attachment 165350 [details] patch V2 Here the next version. This is based on bug# 308737. The patch "needed changes" is included.
Created attachment 165351 [details] mylyn/context/zip
This looks good. I have two suggestions: * Create a Bugzilla specific subclass of XmlRpcOperation. I think it's likely that some behavior will be customized in the end, e.g. exception conversion. I believe BugzillaClient generally throws CoreException so BugzillaXmlRpcClient should maybe follow that same design. Rob? * Something needs to be done about exceptions resulting out of casts: if (response != null) { result = (Object[]) response.get(XML_RESPONSE_IDS); } Either add a "safeCast()" method that catches ClassCastExceptions or do all processing within operation.execute() and we add general handling in the default operation implementation which we should probably have anyways.
Created attachment 165656 [details] first implementation This is what I have commited.
Created attachment 165657 [details] mylyn/context/zip
It looks like there are several calls in BugzillaXmlRpcClient that use NullProgressMonitor. That is a problem as these operations could block the UI thread. Frank, can you look into that?
Created attachment 174530 [details] add IProgressMonitor to methods (In reply to comment #20) > It looks like there are several calls in BugzillaXmlRpcClient that use > NullProgressMonitor. That is a problem as these operations could block the UI > thread. Frank, can you look into that? please verify.
Created attachment 174531 [details] mylyn/context/zip
I commit the latest patch. Steffen, can you please verify. Now I work on bug# 314744.
(In reply to comment #23) > I commit the latest patch. > > Steffen, can you please verify. > > Now I work on bug# 314744. Steffen, can I close this bug? Or did you found some more things to do?
Yes, we can close this. I haven't gotten around to reviewing it but we should be done here.
