Community
Participate
Working Groups
I need support for the attribute factory to be dynamically created based on the RepositoryTaskData since the attributes and their mappings could be specific to an installation of a repository (such as different attributes for different versions).
Created attachment 59085 [details] patch
Rob: please review after 2.0M1 goes out (tomorrow).
Comment on attachment 59085 [details] patch It turns out that the simple solution provided does not entirely fix this problem since the ITaskDataHandler has the method getDateForAttributeType which is dependent on the attributes. Maybe these methods should be moved to within the RepositoryTaskData or should both take the RepositoryTaskData so that they can provide the best result.
Created attachment 59392 [details] Dynamic Attribute Factory Creation I have created a new patch for this issue. Now, to get the AbstractAttributeFactory, you must pass in the repository url, repository kind, and artifact type. There is a DEFAULT_ARTIFACT_TYPE that is used when there are no differences between artifact types. Also, I have moved the getDateForAttributeType method to the AbstractAttributeFactory since each of the artifact types may have different date representations. Could you please apply this patch soon as it can quickly become obsolete since it affects a large number of projects
Created attachment 59394 [details] mylar/context/zip
Does the factory really need to be task specific? Wouldn't it suffice to have one per repository?
The connector that I am working on has many different artifact types per repository. By allowing multiple artifact types mylar will be able to better support more different systems for contributing tasks to mylar.
Looking good, just a couple thoughts... You need to differentiate taskData on what we call task 'kind' (see Task.java's getKind, setKind). So method/parameter names need to reflect this i.e. taskData.getArtifactType() should be .getTaskKind(). So that said I guess the 'default' kind is Task.REPOSITORY_KIND_LOCAL but each connector should be setting their's to some logical value (i.e. Bugizlla's is 'Bug' now).
I have no objects against the patch but we there has been some discussion about refactoring the AttributeFactory API (bug 150680) in order to separate the presentation from the data model. I think the attribute factory should only provide a mapping from Mylar attribute keys to repository attribute keys. The actual attributes should be constructed by connectors when the task data is initialized (and not through the factory).
Created attachment 59434 [details] getAttributeFactory Patch Here is the new patch. I updated the name to be taskKind
Patch applied and ip log updated. I'll update the porting guide. (In reply to comment #9) > I have no objects against the patch but we there has been some discussion about > refactoring the AttributeFactory API (bug 150680) in order to separate the > presentation from the data model. For a number of reasons this patch highlighted the need to re-architect this completely. TaskData holding onto options and the factory must be stopped.
A couple classes didn't get committed on last attempt (weren't in change set). They are now committed. Further to your comment Steffen, lets schedule this refactoring for after EclipseCon since it is (more-or-less) implementation detail and is going to require -major- changes.
Yes, that will give us a chance to do some more brainstorming about this at EclipseCon :).
