[ 
http://jira.codehaus.org/browse/MCHANGES-259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=269620#action_269620
 ] 

Dennis Lundberg commented on MCHANGES-259:
------------------------------------------

I was thinking of having an Interface (or abstract class to start with) that 
holds the mappings. Perhaps we can make do with a simple Map object for it. 
That Map object would then be sent to the IssueAdapter from an (IMS specific) 
implementation of a report or announcement.

One of the problems with the current plugin design is that there is a lot of 
duplicate code between the Report mojo and the Announcement mojo, when it comes 
to parameters. The parameters often needs to be duplicated between the two 
mojos for every new IMS. What I would like is to have some kind of a 
configuration object that is specific to each IMS.

One way to do it would be to have something similar to the <archive> 
configuration used in the archiving plugins (JAR, WAR, EAR). That configuration 
is a Modello model which is reused between several plugins. Unfortunately that 
would require people to change their configuration for the Changes Plugin, but 
on the other hand we would get something that is much easier to maintain and 
extend.

> Create modularity for supporting multiple issue management systems
> ------------------------------------------------------------------
>
>                 Key: MCHANGES-259
>                 URL: http://jira.codehaus.org/browse/MCHANGES-259
>             Project: Maven 2.x Changes Plugin
>          Issue Type: Improvement
>          Components: other issue-trackers
>    Affects Versions: 2.5
>            Reporter: Benson Margulies
>            Assignee: Benson Margulies
>
> In discussion of MCHANGES-245, Dennis notes the need for some global 
> modularity for capturing the behavior of the different issue management 
> systems. I'm creating this JIRA as a hat-rack to hang this work off of.
> My plan is to start by creating something very simple in the way of an 
> abstract class, which can be elaborated as we go.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Reply via email to