Bugzilla – Full Text Bug Listing
| Summary: | Support for generic web-based repositories | ||
|---|---|---|---|
| Product: | z_Archived | Reporter: | Eugene Kuleshov <ekuleshov> |
| Component: | Mylyn | Assignee: | Eugene Kuleshov <ekuleshov> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P3 | CC: | raphael.ackermann, steffen.pingel |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | All | ||
| Whiteboard: | |||
| Bug Depends on: | 146396 | ||
| Bug Blocks: | 143612 | ||
| Attachments: | |||
|
Description
Eugene Kuleshov
This sounds excellent, and I assume that you're happy taking it on. Regarding my comment in email about specifying the URLs via extension points, I think that your idea of doing it via the UI is better, as these will simply become additional properties that can be set on the repository. For the time being I think that this should come as patches to mylar.sandbox. However, it's final destination could be mylar.tasklist if we decide not to make it an optional feature. It seems like there are lot of struff that is getting into the way. For example, AbstractRepositoryConnector has whole bunch of methods for stuff that can't be supported and I would have to use some dummy stubs. getAddExistingTaskWizard() method there is kind of confusing (jira and bugzilla providers both subclass AbstractAddExistingTaskWizard in a same way. AbstractRepositorySettingsPage always has url, user, password, time zone and encoding. None of those are needed for this provider. I'll add some more after deeper digging... Yup, to support this provider we will have to make this a bit more generic and likely break out a seperate synchronization facility. Which is a good thing, and it will serve as the example for a basic connector once JIRA has the offline stuff (which requires timezone, etc). Let's use this report for your API requests. For now could you just use stubs (like JIRA), and then use this report for requests of stuff to reomve (e.g. need to have username and password). (In reply to comment #3) > Yup, to support this provider we will have to make this a bit more generic and > likely break out a seperate synchronization facility. Which is a good thing, > and it will serve as the example for a basic connector once JIRA has the > offline stuff (which requires timezone, etc). Let's use this report for your > API requests. Should patches for sandbox also go here? > For now could you just use stubs (like JIRA), and then use this > report for requests of stuff to reomve (e.g. need to have username and > password). You mean need to have no user name and password? :-) PS: I'd say that is is rather other way around and this bug depends on bug 143612 ... Yes, that's what I meant. Yes, you can make patches for sandbox go here, but feel free to make new reports as needed. Interesting on our opposite thinking re depencecy: I think that way because bug 143621 is a sub-task of this one. It's the way I've seen the Mozilla folks use dependencies. Also, I assume that this will provide some of the generic features that one needs. (In reply to comment #5) > Interesting on our opposite thinking re depencecy: I think that way because > bug 143612 is a sub-task of this one. It's the way I've seen the Mozilla folks use > dependencies. Also, I assume that this will provide some of the generic > features that one needs. I just felt that it would be easier to generalize something you can prototype on top of the existing stuff. E.g. in web-based provider url for new issue is entered by user and for jira and bugzilla it will be derived from the repository url... PS: interesting typo you made in bug number. That sounds right, but I'm not sure what you're suggesting. Let me know if there are specific generalizations you need made or submit them as seperate reports. Created attachment 44702 [details] Support for creating new task This is kind of a hack. I had to create a "new task" wizard with dummy page because wizard for choosing repository does not allow to finish right after selecting repository. I filled an issue for this. https://bugs.eclipse.org/bugs/show_bug.cgi?id=147540 Patch applied. What repository should I be trying this stuff out with? Btw, I'll leave it up to you to mark your reports as FIXED when done. (In reply to comment #9) > Patch applied. What repository should I be trying this stuff out with? Anything that has list of something. For instance: No new task supported: http://dev.eclipse.org/newslists/news.eclipse.technology.mylar/maillist.html http://dev.eclipse.org/mhonarc/lists/mylar-dev/maillist.html With new task, but require login on first web page activation: repo url: http://subclipse.tigris.org/issues/ new url: http://subclipse.tigris.org/issues/enter_bug.cgi task prefix: http://subclipse.tigris.org/issues/show_bug.cgi?id= > Btw, I'll leave it up to you to mark your reports as FIXED when done. Thanks. It seems there could some more changes soon... Good stuff. I guess you'll need a way to make those irrelevant fields stop showing. It's like we need capabilities for repositories, e.g. if there is no offline handler then there is no point asking for the timezone info. (In reply to comment #11) > I guess you'll need a way to make those irrelevant fields stop > showing. It's like we need capabilities for repositories, e.g. if there is no > offline handler then there is no point asking for the timezone info. Not sure about capabilities. It is probably makes sense to move out all those default controls and create an empty wizard page. Created attachment 45141 [details]
query implementation for web-based provider
Here is implementation of query for web-based provider. Query serialization haven't implemented yet.
Few observations about connector and query API:
-- In connector - getNewQueryWizard() vs. openEditQueryDialog() methods
I think those should be replaced by getQueryWizard(TaskRepository taskRepository, AbstractRepositoryQuery query) where query could be null when editing existing queries
-- AbstractRepositoryQuery and its derivatives probably good candidates for generic attributes, this abstract class look kind of messy
-- AbstractQueryHit - same story, but most importantly id used in constructr should be changed to String!
-- AbstractRepositoryTask - handle parameter in constructor is really confusing
Patch applied. Wow that is cool. I will take a closer look at the UI and your observatoins tomorrow. So do you think there should be some pre-configured settings that come from a drop-down? Interestingly Bugzilla could use that to (e.g. one for bugs.eclipse.org). Note that I added one missing @author tag and updated the copyright to the Mylar Committers one. That will now be automatic for new files you create in the sandbox. (In reply to comment #12) > Not sure about capabilities. It is probably makes sense to move out all those > default controls and create an empty wizard page. Since this is something which is needed for the Trac connector as well I have opened bug 148378 to discuss refactoring of AbstractRepositorySettingsPage. (In reply to comment #13) > -- In connector - getNewQueryWizard() vs. openEditQueryDialog() methods > I think those should be replaced by getQueryWizard(TaskRepository > taskRepository, AbstractRepositoryQuery query) where query could be null when > editing existing queries Yes, this would avoid code replication. I basically copied the openEditQueryDialog() code from Jira for Trac. The implementation could probably just be moved to AbstractRepositoryConnector. Should be a simple patch. > -- AbstractQueryHit - same story, but most importantly id used in constructr > should be changed to String! I agree, this should be along the lines of AbstractRepositoryTask which also uses String ids. (In reply to comment #14) > So do you think there should be some pre-configured > settings that come from a drop-down? Interestingly Bugzilla could use that to > (e.g. one for bugs.eclipse.org). Maybe it could be useful, but I just not sure about UI. The only thing that might work is code completion in regexp text that could be used to insert some templates. Not sure how to implement it though. Created attachment 45184 [details]
support for regexp content proposal
This patch is using Eclipse 3.2 API for Ctrl-Space content propsal in regexp area. Suggesting regexps for IssueZilla, SF/GForge, Jira and Trac. Couldn't manage to create one for Bugzilla.
Expect to get to this end of this week or beginning of next... Created attachment 45736 [details]
implemented externalization and fixed task opening
If I am not mistaken last patch require issue 149509 (AbstractQueryHit.id should be a String) https://bugs.eclipse.org/bugs/show_bug.cgi?id=149509 Created attachment 45811 [details]
resubmitting last patch after 149509
Patch is invalid/malformed, could you try to attach again? Created attachment 45814 [details]
resubmitting again
Patch applied. I had to comment out RegExpProposalProvider and ContentProposalAdapter use from WebQueryWizardPage to get rid of unused warnings. How about making the first page of this repository wizard allow the user to select between a "Create custom repository configuration" and "Create repository from template"? Then include templates to some of the common ones which populate the values? We'll need some tests for this in org.eclipse.mylar.sandbox.tests... (In reply to comment #26) > Patch applied. I had to comment out RegExpProposalProvider and > ContentProposalAdapter use from WebQueryWizardPage to get rid of unused > warnings. What do you mean? > How about making the first page of this repository wizard allow the user to > select between a "Create custom repository configuration" and "Create > repository from template"? Then include templates to some of the common ones > which populate the values? I would really like to keep it simle (you know about the goal of this excercise). So, it is really unclear what those templates could look like for those multiple fields required for each repository. Created attachment 45892 [details]
implemented async preview and restored regexp completion
I wasn't able to make DecoratedField to work properly for multiline Text field. Not sure if it is a but in JFace/SWT.
WebRepositoryConnector has conflict in patch. Could you please reapply, or let me know which patch to apply first? Created attachment 46105 [details] updated patch I think Rob already applied changes for connector class as part of patch for creating tasks from query nodes, etc. So, this one only include changes for WebQueryWizardPage. By the way, can you please clarify what tests you would like to see for this stuff. I also found really nice regexp library that has support for true named matching groups (http://jregex.sourceforge.net/index.html). It would make fetching and mapping to other issue attributes much easier... Patch applied. The key thing is to test the most fragile non UI stuff as you contribute it. Right now I think that is the regular expression matchers--I suggest writing a test case that check each against a live URL to ensure that it collects the right items. Then if/when the format of the 'supported' repositories' HTML pages changes a test will fail. It looks like you have all the key pieces in place and the content-assit based regexps and preview are definitely neat. But I find this a very advanced UI. I think that having pre-defined templates would make it much easier for others to start using. You currently have templates for the regexp, and would need to have those encapsulate repository settings as well: 1) Give the Web Repository Settings page a combo that allows a template to be slected, but defaults to "<custom settings>". Selecting a template will fill in all of the URLs and prefixes. This means that each will need an concrete repository to point at (hopefully the repository project itself in most cases). This will make it easy for people to diffrenet repositories by working from the example. 2) The URL and regexp of the New Web Query page will be auto-populated with the template. I believe that that this "by example" approach is more effective than the careful documentation that this requires otherwise because it will allow people to start from something that works and modify to their needs. What do you think? Regarding the library, the good news is that eclipse.org is getting: http://www.eclipse.org/proposals/orbit/ However, jregex would still require a 6 week review and interest by others to use so if there is another Apache library or something else already being used by other eclipse.org projects that would be easier. Well, those regexps though as generic examples. But maybe you are right and they need to be linked to concrete repositories... Do you have suggestions for such templates? I mean what repositories/projects to use. Speaking of drop down on the repository settings I think that it would be most appropriate to have a dropdown on repository url field. So it won't require additional controls. Then we can use similar thing for query settings and pick query url from the drop down. Note that none other regexp library support named matching groups (all support numbered but you generally don't know the order) phyton style. jregex also support latest perl regexps that none of apache libraries does... Yes, I think this approach will make it very easy for people to get started using this for stuff like java.net. Good idea on the UI for the drop-down, and yes, then we can add bugs.eclipse.org and other repositories there. It'll be a little hidden but we can point to it in the page description. Regarding concrete templates suggestions, going after the notion that more generic is better - IssueZilla: https://mustang.dev.java.net/ - GForge: their own (http://gforge.org/tracker/?atid=105&group_id=1&func=browse) - Trac: http://projects.edgewall.com/trac - JIRA: JIRA Dashboard - vBulletin: http://www.vbulletin.com/forum/ ? (In reply to comment #35) > Good idea on the UI for the drop-down, and > yes, then we can add bugs.eclipse.org and other repositories there. It'll be a > little hidden but we can point to it in the page description. You've said while back that you will allow me to get rid of unneded stuff from the settings page. I guess this is about right time now and you can also change url entry field to the drop down that I could poulate and add my own listener. For the other repositories that drop down could keep history saved into the dialog settings like CVS and Subclipse dialogs do. Though we may need to differentiate dialog settings between providers... Added 150327: Make repositry url entry field a drop down https://bugs.eclipse.org/bugs/show_bug.cgi?id=150327 Created attachment 46185 [details]
Implemented templating support for query wizard
Please apply after patch for issue 150327
Patch applied. - I moved WebRepositoryConnectorTests into mylar.sandbox/testsrc to follow our convention of making tests seperate. - WebRepositoryTemplate is now public as is another search method, which is OK since we consider tests to be another client of the plug-in so opening things up for tests is acceptable. If it's something that really shouldn't be touched by a client we stick a /** For testing */ comment on. - Please integrate WebRepositoryConnectorTests into AllSandboxTests as that will eventually allow this to run as part of our comprehensive suite The other requests will need to wait until bug 145123 is done (should be this aft). Please hold off further patches until then. Created attachment 46217 [details]
fixing stuff after applied patch
Mik, this doesn't seem got trough properly. So, here is the patch to clean up some left overs.
Also note that to add test to all tests suite you should use:
suite.addTest(WebRepositoryConnectorTest.suite());
Created attachment 46219 [details]
added example of phpBB and vBulettin forums
Created attachment 46247 [details]
updated patch with last changes
Created attachment 46300 [details]
updated patch after last refactoring
Patch applied. I had to do a manual merge on AbstarctRepositorySettingsPage so you may want to verify. Wow, I have my SourceForge bugs in my task list! Took a bit of copy pasting with the IDs and the UI is pretty advanced, but this is quite cool. Maybe we should start making it available with the dev builds in the Sandbox category... Are you planning on adding a query test for each supported template? (In reply to comment #45) > Are you planning on adding a query test for each supported template? Hey! It is already in CVS. :-) WebRepositoryConnectorTest.suite() is commented out in AllSandboxTests Ha, the modularity of your test is too good, and because it was so short I hadn't noticed that you actually were testing the templates! (In reply to comment #43) > Patch applied. I had to do a manual merge on AbstarctRepositorySettingsPage > so you may want to verify. The only think I noticed is this part: String repositoryLabel = repository.getRepositoryLabel(); if (repositoryLabel != null && repositoryLabel.length() > 0) { repositoryLabelCombo.setText(repositoryLabel); } Code you committed is accessing label using getPropertyMethod() and adding element to the Combo instead of setting text. There is now an org.eclipse.mylar.sandbox-feature in CVS. Dev build coming tomorrow morning. I pulled the context tree and control panel into mylar.viz so that only the dev tools and the web connector will be available for download. In order to encourage peopel to try this, do you want to write some brief docs for setting up with java.net? I think it should be brief sine the UI is likely to evolve, but it would give people a starting point. For now a good place for those docs is: http://wiki.eclipse.org/index.php/Mylar_Contributor_Reference#Sandbox I've moved comment#43 to bug 150969 Marking resolved, since we are tracking web connector bugs in seperate reports. |