Bugzilla – Full Text Bug Listing
| Summary: | [discussion] provide task/issue repository view and extension points | ||||||
|---|---|---|---|---|---|---|---|
| Product: | z_Archived | Reporter: | Mik Kersten <mik.kersten> | ||||
| Component: | Mylyn | Assignee: | Mik Kersten <mik.kersten> | ||||
| Status: | RESOLVED FIXED | QA Contact: | |||||
| Severity: | enhancement | ||||||
| Priority: | P4 | CC: | brockj, ekuleshov, jed.anderson, mlists, robert.elves, steffen.pingel, wes.coelho, wmitsuda | ||||
| Version: | 0.4 | ||||||
| Target Milestone: | --- | ||||||
| Hardware: | PC | ||||||
| OS: | Windows XP | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
|
Description
Mik Kersten
Created attachment 31781 [details]
Brock's requirements for generic issue tracker support
Great stuff. It seems right that tracker view should only show list of the registered repositories and I don't think it is a good idea to show issues up there (better to jump to the special view, like master/detail, that will support pagination and filtering of the results). So, it would also make sence to have an extension point that would allow 3rd party tracker providers to plug into Mylar's "new query" action. As of issue search it would make sence to put the results into the standard Search view. Doing that we will be able to stay away from another perspective and provide all information within commonly used perspective. As a side note, Subclipse allows to store link to the issue tracker within properties and if I am not mistaken that can be used for project as well as for each commit. Still attaching tracker to the project would be a good idea and it may allow to provide links from the editors and VCS comments. Regarding the three issues raised in comment#2: 1) That definitely sounds like the right idea, so I'll create that extension point and make the Bugzilla Client use it. And yes, I also like thinking of this as a master/detail separation. 2) This also sounds right. The Bugzilla Client Search results already go into the standard search dialog and view, so that should get generalized. 3) Yup, we'll need that project association too, otherwise Mylar's automatic commit messages won't work. Repository content providers could independently decide to show issues, but I agree that it's most doubt it's a good idea unless the repository itself stored something like common queries (e.g. all bugs modified recently). Issues repositories are just too differnet from source repositories because it's rare that we browse them hierarchically. One thing thing that could eventually be useful to show under the repository is the list of products, so you could do something like right-click the product to submit a bug for it. (In reply to comment #3) > One thing thing that could eventually be > useful to show under the repository is the list of products, so you could do > something like right-click the product to submit a bug for it. You thin so? Look at http://jira.codehaus.org/secure/Dashboard.jspa :-) Yowzerz, I see your point :) That's actually why Bugzilla 2.20 now has the notion of Classifications (similar to JIRA categories). So if there were actually a good use case for this the children of the repository could be those things, and their children could be projects, then components, etc. But this is all lower priority since the key thing is that the new bug wizard makes component selection and such easy. (In reply to comment #5) > Yowzerz, I see your point :) That's actually why Bugzilla 2.20 now has the > notion of Classifications (similar to JIRA categories). Heh. I liked more old Bugzilla UI. Now I have to go trough two pages instead of one like before. It is even more stupid that new pages has project names but no links. :-( > So if there were actually a good use case for this the children of > the repository could be those > things, and their children could be projects, then components, etc. But this > is all lower priority since the key thing is that the new bug wizard makes > component selection and such easy. BTW at some point Mylar's new bug wizard din't update component list when selecting different projects in the correspond list... haven't tried it for some time though. *** Bug 110225 has been marked as a duplicate of this bug. *** The current prototype of this funcionality uses a view and wizards. I'm still wondering if this may be better as a preference page, but that complicates the wizard and extension point issue, and makes extending this to repository browsing difficut. But I'm still wondering if there are compelling use cases for browsing repository contents via a view (instead of setting up queries with wizards, etc.). Brock, what's your take on this for JIRA? Given that queries will appear in the task list, what could you see yourself using the view for other than adding/removing repositories? (In reply to comment #8) Mik is it difficult for you to publish a dev build? It would make it easier to try.. Yup, the dev build update site is now specified at: http://www.eclipse.org/mylar/dl.php The only compelling reason i can think of is for repository administration. Jira does have support for remote admin of the repository, but this has not yet been exposed in the plugin. I actually think it would be better to not run queries from the repository view. The types of queries that would be run from there are very simple and could easily be done using the issue search functionality. Allowing the user to persist and re-run queries would be a much more flexible solution. (In reply to comment #10) > Yup, the dev build update site is now specified at: > http://www.eclipse.org/mylar/dl.php Cool! By the way, are you going to move bugzilla properties such as version to the provider properties? Also, I would think that repository label and custom provider icon can be useful. I wonder if "max results" and "refresh on startup" properties will go into query specific properties available from the task view? The preliminary support and "repositories" extension point are in the latest and shipped with the dev build I announced on mylar-dev. mylar.bugzilla.ui uses this extension point, but we still need extensibility for "add query". I hope to have that done early next week, report is bug 123845. I'm going to leave this report open since it is a good place for us to discuss evolving the extension points and UI integration. Brock, I agree with your points on comment#11, so let's keep the view. It also fits nicely into the CVS and Synchronizing pespectives. Eugene, you can already set the "max results" on each query, so I think that should just be removed from the bugzilla prefs page. "refresh on startup" might need to move into a common repositories page, since it seems like this should either be on or off for all. And yes, we could add a custom label provider. I'll work on presentation some next week, report is: bug 123846 I have started integrating with Jira and so far, so good. I have one question though. Is there any way to associate extra properties to a TaskRepository? Currently i have an object (JiraServer) that is persisted across sessions. This object is basically the same as the TaskRepository. It holds the credential information as well preferences and server information (version number). It also acts as a cache for project/component information. Perhaps providers should be responsible for maintaining the details of the task repositories and the TaskRepositoryManger delegates to them. That way TaskRepositoryManager#getRepository could return a subclass of TaskRepository that could then be cast to the concrete repository type. Another approach would be to have the providers maintain their own registry of repositories and look them up from a TaskRepository. There is a place in the UI to do it: extend RepositorySettingsPage the way that BugzillaRepositorySettingsPage does. But yes, there is some commonality here between what the Bugzilla Client does and what you want, so we should figure out the API. What are all the repository settings that you need to have, or imagine wanting to have? For bugzilla the additional ones are: - server version [2.16, 2.18, 2.20] (now) - http auth credentials (future) Let me know, and we can figure out if a subtype of TaskRepository is the best way of handling that. Although I considered it becaue it would have been easier for Bugzilla, I would like to avoid the approach of each provider maintaining a list of their own repositories because there is a lot of benefit to the task list being able to handle the repository map consistently, makes for easy testing, and avoids duplication in the clients. Regarding the product infomration, it seems like the it should be maintained by each client for now? Early next week I hope to make the query page extension point, since that's the key thing needed to enable JIRA queries showing up in the list. (btw, I'm offline until Monday) (In reply to comment #15) > There is a place in the UI to do it: extend RepositorySettingsPage the way that > BugzillaRepositorySettingsPage does. But yes, there is some commonality here > between what the Bugzilla Client does and what you want, so we should figure > out the API. BugzillaRepositorySettingsPage extends the page to add a validate button. It does not store any extra details against the TaskRepository. > What are all the repository settings that you need to have, or > imagine wanting to have? For bugzilla the additional ones are: > - server version [2.16, 2.18, 2.20] (now) > - http auth credentials (future) - server version (this comes from a service call to the server) - rpc plugin version (later) - query limit - gzip compress requests - server description/label > > Let me know, and we can figure out if a subtype of TaskRepository is the best > way of handling that. Although I considered it becaue it would have been > easier for Bugzilla, I would like to avoid the approach of each provider > maintaining a list of their own repositories because there is a lot of benefit > to the task list being able to handle the repository map consistently, makes > for easy testing, and avoids duplication in the clients. > In the short term i was hoping to write the Jira-Mylar integration as a wrapping feature above the other two features. This way people could still use the base Jira plugin as well as the mylar integration. If they don't like the mylar integration, they can simply disable the feature and everything goes back to normal. For this to work the core Jira plugin has to maintain a list of servers as well as user defined queries (which it already does). The Jira-Mylar bridge would convert these to the appropriate Myar Objects (Query categories) when requested. Also, if we are to display custom hierarchies in the repositories view there will have to be a server specific model somewhere. > Regarding the product infomration, it seems like the it should be maintained by > each client for now? I think so. The structure of this information is quite different between products. So the common things are: version, server description/label, and query limit. But shouldn't "query limit" be a default on the query itself? I'll explore adding those in a way that ensures additional settings can be stored. So the big question now seems to be whether or not the JIRA plug-in should depend on mylar.tasks. From a users' perspective, that dependency results in the Mylar Tasks and Task Repositories views showing up (no Mylar UI stuff). The optional bridge approach could also work, but will not provide the UI consistency (one Tasks view with one notion of queries) which I think is important in the long run. But is a smaller change for your users, and could have benefits to you because you get to control more of the UI. Let me know your thoughts on this, and in the meantime I'll be working on the unified query mechanism (bug 123845). By the way, how about other way around. Jira plugin may have core plugin that could be used by both Mylar and Jira ui plugin? I don't think it is a really good idea for the end user to have several views to maintain lists of the different issue tracking repository types. I also feel strongly that the user shouldn't have multiple views for tracking, and am committed to making the Tasks and Repositories views usable and extensible enough to ensure this. Additional merit to the structure Eugene is proposing is that it allows the current JIRA Dashboard UI to stay as-is and not change to dramatically for existing users, and the stuff based on mylar.tasklist to be evolved independently. It would also give us an easy way to gradually move common stuff into mylar.tasklist. So it could look something like this: mylar.tasklist + Bugzilla Client (depends on mylar.bugzilla.core) + Jira Client (depends on jira.core) What do you think Brock? I'm not yet sure if it's a good idea for mylar.bugzilla.core without splitting out a mylar.tasks.core component that bugzilla.core could depend on, because it would result in all of the duplicated code that you were alluding to (i.e. rather than getting to work with a TaskRepository object each client would have to have it's own abstraction). But I could make the bugzilla.core plug-in thinner so that it only provided API for accessing the server, and not abstractions for running searches, etc, which is probably more similar to what you're already doing? Eugene, currently the jira.core plugin can be used by any ui. It was designed to have no coupling to eclipse at all. It could be used by a standalone swing client if needed. It is basically just a facade around a group of jira servers. You request a server from the manager than execute operations on that server. All of this is to hide the mess of SOAP and POST and to allow transparent support for different server versions. I also agree that it isn't good to have two places to maintain the servers. My concern is that to use the TaskRepository object, i would have to re-write my entire core layer and introduce a dependency on the task list plugin (or tasklist core plugin). On a slightly related topic, the task view does not provide the same level of functionality as the Jira Issue Navigator. If the task view had to deal with all of the low level deatils of every issue tracker the number of columns and toolbar could be too much to display. I think the task list is better off staying a task list (instead of an issue list). The user would add queries that he thinks are 'interesting', where I define interesting as being open issues assigned to me (it is up to the user to define their queries though). If you wanted to do ad-hoc querying or assign a bunch of issues to yourself the task view is not the place to do it. If you check out the screenshots here: http://jira-dashboard.tigris.org/screenshots.html you will see that the view that displays the issues is the same as the one that defines the servers. The view is totally driven by the JiraServer objects which makes them kind of important to me :) You might also want to check out the core package and have a look at the API packages (org.tigris.jira.core,org.tigris.jira.core.model,org.tigris.jira.core.service) to see what currently exists. In particular, look at org.tigris.jira.core.CachedRpcJiraServer to see the gory details. This object acts a bridge to the server as well as a server/project information cache and is the model object used to display the tree in the Issue navigator. (In reply to comment #20) > Eugene, currently the jira.core plugin can be used by any ui. It was designed > to have no coupling to eclipse at all. It could be used by a standalone swing > client if needed. It is basically just a facade around a group of jira > servers. You request a server from the manager than execute operations on that > server. All of this is to hide the mess of SOAP and POST and to allow > transparent support for different server versions. > > I also agree that it isn't good to have two places to maintain the servers. My > concern is that to use the TaskRepository object, i would have to re-write my > entire core layer and introduce a dependency on the task list plugin (or > tasklist core plugin). I still hope that you and Mik can come up with some compromise. > On a slightly related topic, the task view does not provide the same level of > functionality as the Jira Issue Navigator. If the task view had to deal with > all of the low level deatils of every issue tracker the number of columns and > toolbar could be too much to display. I think the task list is better off > staying a task list (instead of an issue list). The user would add queries > that he thinks are 'interesting', where I define interesting as being open > issues assigned to me (it is up to the user to define their queries though). > If you wanted to do ad-hoc querying or assign a bunch of issues to yourself the > task view is not the place to do it. This is not quite true. In most of the cases you won't need to see those columns as long as filtering and sorting criteria is maintained by the filter/query wizard. So, if you have defined a query it will be possible to dynamically refresh it istead of copying issues from other plugins or web browsers. This actualy bring me to the part which I'd like to see from Jira integration with mylar, so there should be a wizard to add new query that will mimic that narrow Jira's web-based query editor. I believe this is much more practical then just browsing huge project tree like you've done in Jira dashboard. > If you check out the screenshots here: > http://jira-dashboard.tigris.org/screenshots.html I saw that and tried plugin some time ago. I've mentioned already that with current UI this plugin is just not scalable. If you point it to some real repository, e.g. http://jira.codehaus.org/ you should see what I mean. > you will see that the view that displays the issues is the same as the one that > defines the servers. The view is totally driven by the JiraServer objects > which makes them kind of important to me :) Those are just views and they don't worth much alone. The point is to integrate live issue info into the Mylar's tasl list, so you won't have to copy or switch back and forth between issues. Instead Mylar will provide basic and unified navigation and will also allow to maintain the same workflow for any issue tracking system and version control system. So the way I see it is: -- Get live issue query from the issue tracking server (BugZilla, Jira, RSS, etc) -- Open issue in the internal browser or specialized editor if one is avalable. -- Work on the issue and collect contextual information -- Commit resources changed within collected context into version control system (CVS, SVN, etc) using description pulled from the issue tracking server -- Automatically close issue in the issue tracking server upon completion, optionally attach a patch and/or list of changed files. Am I missing something? Eugene, you may want to take another look at it. You can now define your own queries (exactly like thw web interface) as well as run many of the most common predefined queries (like "most important", "updated recently" and in the next version "unresolved assigned to me"). Jira dashboard is about more than just allowing you to comment and resolve on some issues. It was designed to allow you to access *all* of the features of jira. If you wanted to assign a bunch of issues to yourself based off of some priority, how would you do that from the task view? You would either have to have the category already there (cluttering up the view) or create a temporary category. At the very least, you would have to open each one in the issue editor and assign it to yourself. A more user friendly approach is to have 'somewhere else' where you can do ad-hoc queries and perform actions on the results. This is what the Issue Navigator was designed to do. It provides structured access to queries so you can do 'stuff' to the results. What it *doesn't* do well is provide a persistent view of often used queries. That is what the Task list is good at. Having an action on the issue navigator to move the current search to the task view would be a really nice feature to have. I totally agree that having a list of active issues and integrating them into the Team workflow is a great idea (who wouldn't), but you still need to do something to an issue to get it to match one of the queries in your task list (usually by assigning it to yourself). The bugzilla plugin does this by integrating with the search dialog and Jira does it by using the issue navigator. Perhaps Mik doesn't see this as such a big deal because all issues are auto assigned to him and hence automatically show up in his task list? When you have an inbox or when the issues start out unsassigned you do need a convenient way to find the next most important issue(s) and assign them to yourself. (In reply to comment #22) > Eugene, you may want to take another look at it. You can now define your own > queries (exactly like thw web interface) as well as run many of the most common > predefined queries (like "most important", "updated recently" and in the next > version "unresolved assigned to me"). So, may we expect to have these features available as query editor/wizard for Mylar's task view? > Jira dashboard is about more than just allowing you to comment and resolve on > some issues. It was designed to allow you to access *all* of the features of > jira. If you wanted to assign a bunch of issues to yourself based off of some > priority, how would you do that from the task view? You would either have to > have the category already there (cluttering up the view) or create a temporary > category. At the very least, you would have to open each one in the issue > editor and assign it to yourself. > > A more user friendly approach is to have 'somewhere else' where you can do > ad-hoc queries and perform actions on the results. This is what the Issue > Navigator was designed to do. It provides structured access to queries so you > can do 'stuff' to the results. What it *doesn't* do well is provide a > persistent view of often used queries. That is what the Task list is good at. > Having an action on the issue navigator to move the current search to the task > view would be a really nice feature to have. I see no harm to have query pointing to the inbox of temporary query that is being edited to get results interesting in given time. > I totally agree that having a list of active issues and integrating them into > the Team workflow is a great idea (who wouldn't), but you still need to do > something to an issue to get it to match one of the queries in your task list > (usually by assigning it to yourself). The bugzilla plugin does this by > integrating with the search dialog and Jira does it by using the issue > navigator. Perhaps Mik doesn't see this as such a big deal because all issues > are auto assigned to him and hence automatically show up in his task list? > When you have an inbox or when the issues start out unsassigned you do need a > convenient way to find the next most important issue(s) and assign them to > yourself. I do agree that bulk change/edit actions in issues a great feature, but you may as well provide as provider specific menu's in the Mylar's task view. yes, i can't see any reason for not having the query wizard on the task view. I had actually started to implement this, but got sidetracked on other things. If there is an entry is in your task view it is a task and can therefore have its context activated. If the issue 'doesn't belong to you', should you really be allowed to activate it? To me, tasks are things that have to get done. Logically you would only want to see the stuff you need to get done in your task view. If an issue is assigned to someone else, should you really be working on it? To me, activating a task means 'i am actively working on it' and for Jira this may actually mean setting the issue status to in progress (something that can only be done if you are the assignee). Of course, this is only my point of view and the way i would like to work with Mylar. Others may have different opinions and should be free to set up their task view however they like. Eugene, can you please describe the queries that you have in your task view and how you interact with them? By the way, I'm working with a client who uses Jira and is considering using Mylar for reporting. I'll need to implement some basic Mylar-Jira integration to make it work. So far, I've looked into using the Jira Dashboard core to talk to the Jira server. The Jira Dashboard API seems to work great for this. The approach I'm taking is to add support for Jira Filters to the task list in the same way as Bugzilla Queries currently work. This will allow users to collect contexts for Jira issues and use the web UI or Jira Dashboard for all other Jira interaction. (In reply to comment #25) Wesley, aren't Brock working on the same thing? And he wrote that Jira Dashboard thing. I think what I need (Bugzilla queries for Jira in the Task list) might be a very small subset of what Brock has in mind, but it depends on how he ends up implementing it. If Brock implements something that does this and more, that would be great. Meanwhile, his API is easy to use and seems to do the trick for basic importing of the issues for Jira filters defined using the Web UI. I may not need more than that plus the Jira Dashboard. (In reply to comment #27) > I think what I need (Bugzilla queries for Jira in the Task list) might be a > very small subset of what Brock has in mind, Do you mean bugzilla issues imported into Jira like in search box at https://issues.apache.org/jira/secure/Dashboard.jspa ? > but it depends on how he ends up > implementing it. If Brock implements something that does this and more, that > would be great. Meanwhile, his API is easy to use and seems to do the trick for > basic importing of the issues for Jira filters defined using the Web UI. I may > not need more than that plus the Jira Dashboard. I guess there are two things: query wizard and the query itself (created by wizard, from saved query or web link). If you both are planning to make this code available it would be great if you can cooperate... Hi Eugene, that isn't what I meant. Sorry for the confusion. I just need to be able to show Jira query (filter) results as tasks in the Mylar tasklist so contexts can be collected. The filters would be defined using the Jira web interface so I don't have plans to work on any wizards, query UI, or integration with the Jira Dashboard, although I'd like to use it to download the issues. Brock, is there some overlap here with how you plan to implement Mylar integration for the Jira Dashboard? It does look like there is some overlap. I have already added support for creating new Jira repository clients and am currently working on the task/task category externalization which is needed for adding queries to the task list. From what you have said, you don't need the query UI at all as you are just going to show the user's server defined filters. Is this correct? Can you tell me what sorts of issues these queries match and what the user will be doing with them in the task view. I am trying to get a better understanding of what people are using the task list for. (In reply to comment #30) > It does look like there is some overlap. I have already added support for > creating new Jira repository clients and am currently working on the task/task > category externalization which is needed for adding queries to the task list. Although I don't have rights to send code, I've prototyped the externalization part and submitted a fix for a bug I ran into that should help (Bug #124222). I didn't do anything with the "Registry" though as I don't really know how it works yet, or whether it's needed. > From what you have said, you don't need the query UI at all as you are just > going to show the user's server defined filters. Is this correct? Yes. > Can you tell me what sorts of issues these queries match and what the user will > be doing with them in the task view. I am trying to get a better understanding > of what people are using the task list for. My understanding is that developers will have the standard "Open tasks assigned to me" query, and will use the task list mostly just to activate and deactivate Mylar contexts for those tasks. (In reply to comment #31) > > Can you tell me what sorts of issues these queries match and what the user will > > be doing with them in the task view. I am trying to get a better understanding > > of what people are using the task list for. > > My understanding is that developers will have the standard "Open tasks assigned > to me" query, and will use the task list mostly just to activate and deactivate > Mylar contexts for those tasks. Personally I narrow down these tasks/issues to the current version only... and it is actually not so convenient to jump into such saved query in Jira's web ui. That was just an example, any query could be specified. But yes, this does require jumping to the web ui. Do you re-define your queries often? (In reply to comment #33) > That was just an example, any query could be specified. But yes, this does > require jumping to the web ui. Do you re-define your queries often? I ended up with taking any query and altering it to the current scope without saving it and keep query editor always on. Here are a few comments for issues Eugene's responses may not have addressed: - Issues that don't belong to you: yes you should be able to activate them. For example, if you review someone else's task, you are accumulating time working on that issue, might be accumulating context, etc. - Administrative operations (e.g. reassigning a bunch of issues to yourself): no support this yet, but it is on the drawing board. The easiest thing right now is for the issue tracker plug-ins to add actions to the task list. It will also be needed for the Task Planner (e.g. add all planned tasks to a target release). - Assigning issues to yourself: my model is that everyone who is responsible for doing their own assignment has a query/filter for the "inbox" category in their task list. Also, I'm concerned that the current 'APIs' are still too painful for eacy extensibility. Brock had a great suggestion (in email) of making local tasks be a repository (bug 124321). I'm going to use that and the generic query (bug 123845) as a driver for cleaning them up some, and hope to have that done before the end of the week. So please expect some changes. Brock, Wesley, note that the following improvements have been made in the mylar.tasklist modularity: - There is now a single generic task editor, and the Bugzilla editor page is added to it via extension point. - The tangled ITaskHandler has been refactored out (yay) - What used to be called the registry is now referred to as the task archive. - ITaskRepositoryClient is now AbstractTaskRepositoryClient and contains some common functionality. We might still create an interface, but there's no point of doing that if too many clients need to cast down to the implementation type (i.e. the issue with JavaElement/IJavaElement). Things that still need improvement: - Task externalizes - Repository specific settings - Local tasks might turn into repository Hi Mik, I have some basic Jira support I'd like to contribute. There is still a bit more work to do on it but I'm finding I'm spending more time keeping up with your constant refactoring than improving or testing the Jira support. The changes you've been making are great and I've been able to delete some classes from the Jira plugin. But it would really help if the Jira code was included in your refactoring to keep it from going stale the minute I stop updating it. Would it be possible to contribute the code as is to a sandbox and then work on it from there? (In reply to comment #37) > I have some basic Jira support I'd like to contribute... Mik, please take it. I can't wait to get my hands on it. :-) I feel your pain Wesley, and can't wait to get your stuff in there either, and to be considering this second client when improving the APIs. A couple of days ago I created a mylar.jira component that should serve as the infrastructure for contributions. Will post on this report once it's committed. I'm having trouble settling on the name for the extension point. Currently it is: - plugin.xml: repositoryClient - UI: JIRA Repository Client I'm wondering if it should be: - plugin.xml: repositoryConnector - UI: JIRA Repository Connector Client seems a bit implementation-ish, and connector a bit more obvious to users? Any other ideas? (In reply to comment #40) Connector is definetely better. Team providers are using "repository type" on the UI. Another options could be: -- issue tracker type -- issue repository link/adapter/provider/link -- issue source (type) Good suggestions. Since team providers are using "repository type", which expands to "source repository type", it seems that we should do the same. But I really don't like the word "issue" because:
- it's a euphamism for "problem"
- it's not accurate for many tasks like (e.g. "refactor foo" is not an issue)
"bug" and "report" are even worse. So while "task" isn't perfect, I think we should stick with it, which gets us:
- plugin.xml extension point: repositoryType
- UI:
- Select a Task Repository Type: (was repository Kind)
- Bugzilla
- JIRA
- feature name: JIRA/Bugzilla Connector
(In reply to comment #42) By the way, how about local task repository? Are you going to decouple it into its own provider? Wesley, there are now two projects for you to commit patches to: mylar.jira and mylar.jira.tests. Please use bug 126842 for integration patches. It would be useful if they were focused on individually testable units of functionality. There is considerably more generic support now, so the integration layer should end up quite thin and I can help trim down your patches where necessary. What's your current dependency on JIRA Dashboard core? Via JAR or via plugin? Eugene, before considering what to do about making local tasks a repository I have to decouple the physical and logical storage of tasks, and get rid of the remaining coupling of ITaskListElement to UI stuff like Font and Icon: - bug 126775: fix task archive and category duplication - bug 125438: make tasklist icons overlay-based Sounds great. I'm currently depending on the Jira Dashboard as a plugin. It doesn't seem to work as a jar because of a dependency on the plugin class and because the Eclipse plugin mechanism is used to contribute some necessary implementation to the core plugin. I currently have .core, .core.soap, and .core.xmlrpc Jira Dashboard projects open in my workspace. Sounds good. Brock and I discussed this briefly and the best way to mange this might be to have our feature depend on the Jira dashboard core feature so that the update manager deals with this. Alternatively we could consider a jar dependency, but that would likely require EMO approval. (In reply to comment #46) > Sounds good. Brock and I discussed this briefly and the best way to mange this > might be to have our feature depend on the Jira dashboard core feature so that > the update manager deals with this. Alternatively we could consider a jar > dependency, but that would likely require EMO approval. From the end user point of view jar dependency is easier to deal with. I can be wrong, but update managed does not allow to resolve features deployed on other update sites. Done a while back. Other enhancements should be new bug reports. |