Community
Participate
Working Groups
Here a part of an Mail from Frédéric Buclin Hello Frank, During the last Bugzilla meeting this week, it has been announced that the current XML-RPC and JSON-RPC APIs will be deprecated in favor of a REST API which will appear in Bugzilla 5.0. It has also been announced that these existing APIs will be totally removed from the source code in Bugzilla 6.0.
Thanks for sharing! This is very interesting. Let's discuss before we move on this. A REST API could warrant forking/re-implementing the Bugzilla connector for 5.0+ to remove all legacy support from the architecture.
Draft for getRepositoryConfiguration is in review https://git.eclipse.org/r/15370
Created attachment 234321 [details] mylyn/context/zip
new review for * getTaskData * getHitSearch * getRepositoryConfiguration
Created attachment 234731 [details] mylyn/context/zip
Created attachment 235923 [details] mylyn/context/zip
I create 3 new reviews instead of review https://git.eclipse.org/r/15370 1) create AbstractBugzillaClient 2) new review as replacement for https://git.eclipse.org/r/#/c/8752/ (372600: create new storage structure for RepositoryConfiguration) 3) create BugzillRESTClient
Here are the reviews: https://git.eclipse.org/r/#/c/17206/ https://git.eclipse.org/r/#/c/17208/ https://git.eclipse.org/r/#/c/17210/
Created attachment 236270 [details] mylyn/context/zip
Hi Frank, do you have a sense for how complete the Bugzilla 5.0 REST API is? I.e. could we replace all the older RDF/XML/RPC calls used in the Bugzilla Connector today without loss of functionality?
*** Bug 411951 has been marked as a duplicate of this bug. ***
(In reply to Robert Elves from comment #10) > Hi Frank, do you have a sense for how complete the Bugzilla 5.0 REST API is? > I.e. could we replace all the older RDF/XML/RPC calls used in the Bugzilla > Connector today without loss of functionality? There is a problem with Mid-Ari collision which must be implementer in mylyn. User matching is not supported. For all other see review https://git.eclipse.org/r/#/c/17210/
for the review you need to apply the patch sudo patch -p0 </tmp/vagrant-bugzilla/modules/bugzilla/files/MylynPatch_756048_916254.patch to the dir /home/tools/bugzilla/bugzilla-REST-trunk/. Hope that this is soon in the bugzilla trunk!
(In reply to comment #12) > (In reply to Robert Elves from comment #10) > > Hi Frank, do you have a sense for how complete the Bugzilla 5.0 REST API is? > > I.e. could we replace all the older RDF/XML/RPC calls used in the Bugzilla > > Connector today without loss of functionality? > > There is a problem with Mid-Ari collision which must be implementer in mylyn. Meaning the Bugzilla server won't respond with a mid-air collision upon submit over the REST api currently? > > User matching is not supported. > > For all other see review https://git.eclipse.org/r/#/c/17210/ Thanks!
(In reply to Robert Elves from comment #14) > (In reply to comment #12) > > (In reply to Robert Elves from comment #10) > > > Hi Frank, do you have a sense for how complete the Bugzilla 5.0 REST API is? > > > I.e. could we replace all the older RDF/XML/RPC calls used in the Bugzilla > > > Connector today without loss of functionality? > > > > There is a problem with Mid-Ari collision which must be implementer in mylyn. > > Meaning the Bugzilla server won't respond with a mid-air collision upon > submit over the REST api currently? Yes you can have lost changes. > > > > User matching is not supported. > > > > For all other see review https://git.eclipse.org/r/#/c/17210/ > Thanks!
I create an patch for Bugzilla. Please see https://bugzilla.mozilla.org/show_bug.cgi?id=432910
create Patch Set 5 for review https://git.eclipse.org/r/#/c/17210/ new is that I add support for getBugHistory and getAttachmentData (sorry I forgot to do this) Actual there are two patches from bugzilla that need to apply to the bugzilla codebase * https://bugzilla.mozilla.org/show_bug.cgi?id=432910 (Mid-Air Collision checking for Bug.update()) * https://bugzilla.mozilla.org/show_bug.cgi?id=756048 (Add and update bug and attachment flags using the the webservices API) you can do vagrant ssh cd /home/tools/bugzilla/bugzilla-REST-trunk/ sudo patch -p0 </tmp/vagrant-bugzilla/modules/bugzilla/files/Mylyn.patch to get both patch applyed.
Created attachment 236689 [details] mylyn/context/zip
I would like to propose something radical to make it easier to proceed with the proposed changes: How about we create a new clean slate Bugzilla connector that only supports REST (i.e. it would only work with Bugzilla 5.0 and later). It would have a clean architecture and not carry any of the previous CGI/HTML, XML-RPC, Bugzilla 3.x, 4.x etc. baggage. This would allow us to move faster on the new code base without having to worry about breaking users or integrators that build on the existing connector. My hope would be that we deprecate the Bugzilla 3.x/4.x connector once Bugzilla 5.0 is out and the new connector is working. This could take a few month or even a year and should provide enough time evolve the new connector to a state where it has feature parity with the old connector. We would keep the old connector around for a bit longer to allow people to migrate but enhancements would only get into the 5.0/REST connector. Considering the maturity of the current connector I would even argue that new features should only be implemented for the new connector. In terms of architecture it would be great if the new connector used all the latest libraries such as Apache HttpClient 4.2, Guava, Gson and not carried forward any of the legacy dependencies. This would enable us to remove HttpClient 3.x and other old libraries from Mylyn at some point. To simplify maintenance of the connector moving forward I would also like to get rid of as much custom UI as possible and move that into the framework. We should also look at the usage of schemas to better define the data model for tasks and such. Additionally we should consider generalizing some of the test infrastructure to reduce duplication between connectors. Thoughts?
Steffen, this has some problems. When we do no longer support the HTML/CGI client then in bugzilla 5.0 the REST API needs to be enabled by default. Should we request this enhancement? For me the REST client should desperate the XMLRPC client. So this was the reason for me to first refactor the common part out of the bugzilla client (review https://git.eclipse.org/r/#/c/17206/) instead of create new connector from scratch. Yes to keep backward compatible with bugzilla 3.x and 4.x needs a lot of translate attribute names. The HTML/CGI client supports actual features like user matching that are not implemented for the REST API. Maybe we can implement an new client using the latest libraries and a new schema for the REST API and then implement the same for the HTML/CGI.
(In reply to comment #20) > When we do no longer support the HTML/CGI client then in bugzilla 5.0 the REST > API needs to be enabled by default. Should we request this enhancement? Yes, that sounds like the right thing to do to me. That said, even if that isn't the default in 5.0 it wouldn't necessarily be a show stopper. A Mylyn connector could be good reason for administrators to flip the switch. > For me the REST client should desperate the XMLRPC client. I agree that it should replace it but I would go one step further and would like to see it be the only interface to Bugzilla. REST APIs provide much better error handling and are much simpler to work with than XML-PRC or custom CGI/HTML. It will make our live much easier if we only need to code against one interface. > So this was the reason for me to first refactor the common part out of the > bugzilla client (review https://git.eclipse.org/r/#/c/17206/) instead of create > new connector from scratch. I'm worried that we introduce a lot of risk to break the existing connector (and integrations building on its internals). Also, we end up with a complicated code base with a lot of abstraction and modes that need to be tested. > Yes to keep backward compatible with bugzilla 3.x and 4.x needs a lot of > translate attribute names. I think to some extend we can worry about migration later. I would think that it is acceptable for instance to re-synchronize all tasks when migrating from 3.x/4.x to the 5.x connector. We should come up with a reasonable plan for migration but it shouldn't substantially influence the design of the new connector, e.g. attribute names should just make sense in the new context otherwise we'll litter the code with a lot of mapping that is only really relevant once but we'll have to keep it forever. > The HTML/CGI client supports actual features like user matching that are not > implemented for the REST API. I find that an acceptable limitation. A very important part of developing the connector is to determine what is missing in the REST API and file enhancement requests against Bugzilla to provide the missing APIs (or help them to develop them). You have already done a great job of that with mid-air collision detection for instance. > Maybe we can implement an new client using the latest libraries and a new schema > for the REST API and then implement the same for the HTML/CGI. In terms of maintainability I would like to get rid of HTML/CGI sooner rather than later. It has helped us to make the connector work with existing Bugzilla instances but this is a great opportunity to drive the modernization of the Bugzilla REST API to cover all the aspects needed to provide a well working connector.
I would suggest that we move the new connector into a sub-directory. This makes it easier to see which bundles are part of the new connector vs. the old one and we may start doing that for other components as well in the near future: pre. connector-bugzilla-rest/ org.eclipse.mylyn.bugzilla.rest-feature org.eclipse.mylyn.bugzilla.rest.core org.eclipse.mylyn.bugzilla.rest.core.tests org.eclipse.mylyn.bugzilla.rest.ui org.eclipse.mylyn.bugzilla.rest.core.tests
(In reply to comment #22) ... > org.eclipse.mylyn.bugzilla.rest.ui > org.eclipse.mylyn.bugzilla.rest.core.tests That should have been org.eclipse.mylyn.bugzilla.rest.ui.tests of course.
I create review https://git.eclipse.org/r/18252 with the new projects (see comment#22 and comment#23). I include * new bugzilla test instance * 5 new projects * "Dummy implementation" (Ui for repository and Task Creation without connection to bugzilla) Maybe this can be a blueprint for an creation of a new connector.
Created attachment 237346 [details] mylyn/context/zip
Steffen, can you please integrate the new projects into the build of the review. I chreate the pom.xml but the projects did not get build.
create https://git.eclipse.org/r/18409 for the setup of the new testinstance
create review https://git.eclipse.org/r/18474 with an minimal UI add TaskRepositorySetting with validation, Query an EditorPage
Created attachment 237511 [details] mylyn/context/zip
review https://git.eclipse.org/r/#/c/18474/ patch set 2 implements the core part of the previous patch set For the UI part I create a new review.
Created attachment 237672 [details] mylyn/context/zip
review https://git.eclipse.org/r/#/c/19178/ creates a minimal UI review https://git.eclipse.org/r/#/c/19220/ add a first version of an configuration without support for flags. Here we need to wait until https://bugzilla.mozilla.org/show_bug.cgi?id=756048 is fixed
Created attachment 237928 [details] mylyn/context/zip
review https://git.eclipse.org/r/#/c/19220/ failed because mylyn.org setup gets an new field (comment_tag) that was not present at the time I did my local setup
Frank, it looks like some of the tests failed against HEAD with the old connector now: http://ci.mylyn.org/job/mylyn-3.11.x/17/testReport/ . If you get a chance it'd be great if you took a look. Not sure if it's related to the test fixture changes.
(In reply to Steffen Pingel from comment #35) > Frank, it looks like some of the tests failed against HEAD with the old > connector now: http://ci.mylyn.org/job/mylyn-3.11.x/17/testReport/ . If you > get a chance it'd be great if you took a look. Not sure if it's related to > the test fixture changes. The problem is that we now longer get "invalid username or password" we now get "invalid login or password". This must be a change within Bugzilla. I create a review!
https://git.eclipse.org/r/19466 please review!
It looks like this test still has the same problem: junit.framework.AssertionFailedError at junit.framework.Assert.fail(Assert.java:55) at junit.framework.Assert.assertTrue(Assert.java:22) at junit.framework.Assert.assertTrue(Assert.java:31) at junit.framework.TestCase.assertTrue(TestCase.java:201) at org.eclipse.mylyn.bugzilla.tests.BugzillaAttachmentHandlerTest.testContextAttachFailure(BugzillaAttachmentHandlerTest.java:504) Could be worth adding a utility method to detect login failures?
create review https://git.eclipse.org/r/#/c/19667/
New Gerrit change created: https://git.eclipse.org/r/52372
New Gerrit change created: https://git.eclipse.org/r/52373
New Gerrit change created: https://git.eclipse.org/r/52374
Gerrit change https://git.eclipse.org/r/52372 was merged to [master]. Commit: http://git.eclipse.org/c/mylyn/org.eclipse.mylyn.tasks.git/commit/?id=c3774ec86109fd47097b974ee51f2c0d2538305a
Gerrit change https://git.eclipse.org/r/41318 was merged to [master]. Commit: http://git.eclipse.org/c/mylyn/org.eclipse.mylyn.tasks.git/commit/?id=869a056a29aac2a817adb0b2ce02b1bbe1d07a89
Gerrit change https://git.eclipse.org/r/52373 was merged to [master]. Commit: http://git.eclipse.org/c/mylyn/org.eclipse.mylyn.tasks.git/commit/?id=eff1cccfaa7d3a6dca543d273e094ba3464bffbc
New Gerrit change created: https://git.eclipse.org/r/53003
Gerrit change https://git.eclipse.org/r/42359 was merged to [master]. Commit: http://git.eclipse.org/c/mylyn/org.eclipse.mylyn.tasks.git/commit/?id=d384ba5675c9353af165a3145aae3d011032e546
Gerrit change https://git.eclipse.org/r/53003 was merged to [master]. Commit: http://git.eclipse.org/c/mylyn/org.eclipse.mylyn.tasks.git/commit/?id=b9b67b4a85c973105e45521c4aa66b51754a0e26
Gerrit change https://git.eclipse.org/r/52374 was merged to [master]. Commit: http://git.eclipse.org/c/mylyn/org.eclipse.mylyn.tasks.git/commit/?id=0db4f0fe1f7028115aa1fb7620818a821e16a4cf
Gerrit change https://git.eclipse.org/r/42373 was merged to [master]. Commit: http://git.eclipse.org/c/mylyn/org.eclipse.mylyn.tasks.git/commit/?id=85b14d73a4da164a9bd9bf6cf65c692c9d395fe1
Gerrit change https://git.eclipse.org/r/42490 was merged to [master]. Commit: http://git.eclipse.org/c/mylyn/org.eclipse.mylyn.tasks.git/commit/?id=cc6f1b4b44f00e696f7f5aaecbedab9cd6baa869
Gerrit change https://git.eclipse.org/r/42970 was merged to [master]. Commit: http://git.eclipse.org/c/mylyn/org.eclipse.mylyn.tasks.git/commit/?id=44a9886b02c40febb2691712528a925eee025df0
Gerrit change https://git.eclipse.org/r/42973 was merged to [master]. Commit: http://git.eclipse.org/c/mylyn/org.eclipse.mylyn.tasks.git/commit/?id=c47e9260be7b93c04ce3b77952dc581f0d74f709
Gerrit change https://git.eclipse.org/r/43371 was merged to [master]. Commit: http://git.eclipse.org/c/mylyn/org.eclipse.mylyn.tasks.git/commit/?id=f76a87b4d57bc7f4cbc17fba249ac1040b7ba18c
