Community
Participate
Working Groups
We have several use cases for providing access to repository task attributes (currently encapsulated by RepositoryTaskData) directly from AbstractTask. These include any decorations or sortings of tasks that depend on attributes (e.g., sorting by Bugzilla Severity or adding a text decoration for the reporter of a bug). As part of this we will have to determine how much of this information is suitable to store in memory, and potentiall create a JavaModel style cache for the attributes.
This will require a significant refactoring of the task data storage, i.e. separating configuration from attribute values. I have started some of the work (e.g. AbstractAttributeMapper) but it will take more time to work out the API. I would suggest to use bug 179254 to drive the requirements and do this for the editor first keeping the current offline task data model. In a second step the model can be changed to not redundandanty store the configuration. This will most likely require extension points for converting existing task data and some type of versioning support which seems to be out of scope for 2.3.
Steffen, this particular issue is requesting access to the task data values (I believe all listed use cases require only read-only access). I am not saying that configuration should not be decoupled, but it is not required to address access to the current values. On a side note, related to your configuration refactoring, it may be a good idea to somehow store configuration data using common API and not proprietary connector-specific structures.
(In reply to comment #2) > Steffen, this particular issue is requesting access to the task data values (I > believe all listed use cases require only read-only access). I am not saying > that configuration should not be decoupled, but it is not required to address > access to the current values. The current API only allows to load the full data and I am concerned that without decoupling the configuration data the memory and performance overhead will be to high. Optimizing that would largely overlap with the proposed refactoring therefore I am suggesting to push this issue to 3.0 and do the refactoring first. > On a side note, related to your configuration refactoring, it may be a good idea > to somehow store configuration data using common API and not proprietary > connector-specific structures. Yes, that should be considered.
Steffen: I have added this to the next meeting agenda. I want us to have a design discussion about this because this is the way that we had originally implemented repository task data (there was a "has a" relationship between a task and its repository data) and we learned a few lessons along the way when we de-coupled it from AbstractTask. We should now have enough experience to get this right.
Pushing target milestone due to time constraints.
We need to devote some time to this discussion along with the custom attributes discussion / tagging if we're going to converge on this in time for 3.0. Added this as a discussion item to next week's conference call agenda.
Most of the TaskData refactoring that was planned for 3.0 is now complete (bug 226822). The current architecture has additional abstraction that allows connectors to control more of the externalization, mapping and structure of task data. An additional layer that abstracts repository configuration from attributes has also been added but repository configuration is still stored in task attributes as well. Further separation would require additional generalization, e.g. a robust storage and format for repository configuration, which is out of scope of the current release. This means task data and task attributes are still a rather heavy weight data structure that is not suitable for keeping it in memory for decoration or sorting. Connectors may copy certain attributes explicitly to the task list as part of synchronization and we could consider making that extensible or adding a separate cache that would allow to cache attribute values (rather than the actual TaskAttribute objects). In terms of API TaskData is available by invoking TasksUi.getTaskDataManager().getTaskData(Task) which seems sufficient for now. Considering the open bugs for 3.0 I would like to reschedule further improvements for a future release.
Sounds right to me. In order to guard against API misuse and Task List bloat we will need to make the recommended use of arbitrary attributes very clear in the API docs.
Mylyn has been restructured, and our issue tracking has moved to GitHub [1]. We are closing ~14K Bugzilla issues to give the new team a fresh start. If you feel that this issue is still relevant, please create a new one on GitHub. [1] https://github.com/orgs/eclipse-mylyn
