Maven Changes Plugin
  1. Maven Changes Plugin
  2. MCHANGES-259

Create modularity for supporting multiple issue management systems

    Details

    • Type: Improvement Improvement
    • Status: Closed Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.5
    • Fix Version/s: 2.6
    • Component/s: other issue-trackers
    • Labels:
      None
    • Number of attachments :
      1

      Description

      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.

        Activity

        Hide
        Benson Margulies added a comment -

        1. Enums. For each constant listed in the enum, there is one instance for the entire JVM. It has whatever fields and methods you declare on the enum. So, you are declaring a collection of named singletons which have a common contract.

        2. Here's the modularity dilemma as I saw it. If we want to seriously support multiple IMSs, there is a lot of work to do. The comment at the top that we only support 'changes + 1' is there for a good reason given the code. So, I felt that I either had to tackle the big job of actually making it operate on and iterate over multiple systems, or I wanted to enforce the restriction. Now, I could scope the creation and use of the new object(s) to within the blocks for the individual IMSs, I realize, and leave things no worse off then they were. I'll do that.

        3. If you prefer an interface, I think I'll rename the class from Abstract to Default, and add the interface. Unless you prefer the non-JIRA case to start out with no mappings, in which case I'd add the JIRA subclass.

        Generally, I want to point out that this whole business is somewhat off to one side of the patch that started all this. All IMSes that I know are configurable. So, with or without this stuff, we still need to keep the original patch code that allows the user to configure their own mappings. I wonder if we should release what's currently checked in before continuing with any variation on this.

        Show
        Benson Margulies added a comment - 1. Enums. For each constant listed in the enum, there is one instance for the entire JVM. It has whatever fields and methods you declare on the enum. So, you are declaring a collection of named singletons which have a common contract. 2. Here's the modularity dilemma as I saw it. If we want to seriously support multiple IMSs, there is a lot of work to do. The comment at the top that we only support 'changes + 1' is there for a good reason given the code. So, I felt that I either had to tackle the big job of actually making it operate on and iterate over multiple systems, or I wanted to enforce the restriction. Now, I could scope the creation and use of the new object(s) to within the blocks for the individual IMSs, I realize, and leave things no worse off then they were. I'll do that. 3. If you prefer an interface, I think I'll rename the class from Abstract to Default, and add the interface. Unless you prefer the non-JIRA case to start out with no mappings, in which case I'd add the JIRA subclass. Generally, I want to point out that this whole business is somewhat off to one side of the patch that started all this. All IMSes that I know are configurable. So, with or without this stuff, we still need to keep the original patch code that allows the user to configure their own mappings. I wonder if we should release what's currently checked in before continuing with any variation on this.
        Hide
        Dennis Lundberg added a comment -

        2. That'd be great.

        3. I prefer to have an interface, and an abstract class with common implementation pieces. Also a JIRA subclass is better than a general purpose Default implementation, since the implementation in there is specific to JIRA.

        The patch for this issue doesn't contradict your original patch to make the mappings configurable. IMO we should do both.

        Show
        Dennis Lundberg added a comment - 2. That'd be great. 3. I prefer to have an interface, and an abstract class with common implementation pieces. Also a JIRA subclass is better than a general purpose Default implementation, since the implementation in there is specific to JIRA. The patch for this issue doesn't contradict your original patch to make the mappings configurable. IMO we should do both.
        Hide
        Benson Margulies added a comment -

        OK, here's the disconnect on the second part of (3). Before I got here, the code was just assuming that all IMSs used the same strings. And, for all I know, several IMSs do agree on those three strings. So, I preserved this. If you want to put those three mappings into JIRA and leave others empty until someone fills in correct mappings, I'll do that.

        Show
        Benson Margulies added a comment - OK, here's the disconnect on the second part of (3). Before I got here, the code was just assuming that all IMSs used the same strings. And, for all I know, several IMSs do agree on those three strings. So, I preserved this. If you want to put those three mappings into JIRA and leave others empty until someone fills in correct mappings, I'll do that.
        Hide
        Dennis Lundberg added a comment -

        Yes, that's my preference, to keep things as separate as possible.

        If we need the same mappings for Trac, then we should add a TracIMS class that we use for Trac. That way we are one step ahead of where we currently are: all supported IMSes have their own implementation and type mapping.

        Show
        Dennis Lundberg added a comment - Yes, that's my preference, to keep things as separate as possible. If we need the same mappings for Trac, then we should add a TracIMS class that we use for Trac. That way we are one step ahead of where we currently are: all supported IMSes have their own implementation and type mapping.
        Hide
        Benson Margulies added a comment -

        /Users/benson/asf/mvn/plugins/maven-changes-plugin svn log -r1134984
        ------------------------------------------------------------------------
        r1134984 | bimargulies | 2011-06-12 17:08:34 -0400 (Sun, 12 Jun 2011) | 3 lines

        MCHANGES-259 Start to build some modularity that knows that we have multiple
        issue management systems at work in here. This is just the beginning.

        ------------------------------------------------------------------------
        /Users/benson/asf/mvn/plugins/maven-changes-plugin

        Show
        Benson Margulies added a comment - /Users/benson/asf/mvn/plugins/maven-changes-plugin svn log -r1134984 ------------------------------------------------------------------------ r1134984 | bimargulies | 2011-06-12 17:08:34 -0400 (Sun, 12 Jun 2011) | 3 lines MCHANGES-259 Start to build some modularity that knows that we have multiple issue management systems at work in here. This is just the beginning. ------------------------------------------------------------------------ /Users/benson/asf/mvn/plugins/maven-changes-plugin

          People

          • Assignee:
            Benson Margulies
            Reporter:
            Benson Margulies
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: