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

Externalize JIRA server timeout values to the configuration section

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 2.11
    • Component/s: None
    • Labels:
      None

      Description

      Based on the StackOverflow Question

      ----------------
      QUESTION:
      I have a maven-changes-plugin configured for a build process. Sometimes, JIRA intranet server is down and the build takes ages waiting for a long timeout on JIRA.

      Is there a way to configure the timeout?

      ANSWER:

      It does not appear so. The source for the RestJiraDownloader, the class that queries JIRA for issues, has hard-coded timeout values. Lines 562-566 indicate a connection timeout of 36 seconds and a receive timeout of 32 seconds.

        Activity

        Hide
        Mirko Friedenhagen added a comment - - edited

        Fixed with http://svn.apache.org/viewvc?view=revision&revision=1626316.

        I uploaded a SNAPSHOT to https://repository.apache.org/content/repositories/snapshots/org/apache/maven/plugins/maven-changes-plugin/2.11-SNAPSHOT/maven-changes-plugin-2.11-20140919.195826-187.pom

        Boris Pavlovic, please test whether the SNAPSHOT resolves this, I currently do not have an instance with this problem.

        You may set timeouts on the CLI with changes.connectionTimeout resp. changes.receiveTimout or by configuring:

           <plugins>
              <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-changes-plugin</artifactId>
                <version>2.11-SNAPSHOT</version>
                <configuration>
                  ...
                    <connectionTimeout>300000<connectionTimeout><!-- 5 minutes -->
                   <receiveTimout>300000<receiveTimout><!-- 5 minutes -->
                  ...
                </configuration>
              </plugin>
            </plugins>
        
        Show
        Mirko Friedenhagen added a comment - - edited Fixed with http://svn.apache.org/viewvc?view=revision&revision=1626316 . I uploaded a SNAPSHOT to https://repository.apache.org/content/repositories/snapshots/org/apache/maven/plugins/maven-changes-plugin/2.11-SNAPSHOT/maven-changes-plugin-2.11-20140919.195826-187.pom Boris Pavlovic , please test whether the SNAPSHOT resolves this, I currently do not have an instance with this problem. You may set timeouts on the CLI with changes.connectionTimeout resp. changes.receiveTimout or by configuring: <plugins> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-changes-plugin</artifactId> <version>2.11-SNAPSHOT</version> <configuration> ... <connectionTimeout>300000<connectionTimeout><!-- 5 minutes --> <receiveTimout>300000<receiveTimout><!-- 5 minutes --> ... </configuration> </plugin> </plugins>
        Hide
        Dennis Lundberg added a comment -

        Hi Mirko,

        If these new configuration parameters are unique to JIRA that should be reflected in the parameter names, i.e. jiraConnectionTimeout. The Changes plugin supports several issue management systems.

        Show
        Dennis Lundberg added a comment - Hi Mirko, If these new configuration parameters are unique to JIRA that should be reflected in the parameter names, i.e. jiraConnectionTimeout. The Changes plugin supports several issue management systems.
        Hide
        Mirko Friedenhagen added a comment -

        Hello, [~dennislundberg], this is already stated in the documentation. Other parameters like webUser, webPassword etc. are only used for JIRA as well. Maybe this is because JIRA was the first system

        Show
        Mirko Friedenhagen added a comment - Hello, [~dennislundberg] , this is already stated in the documentation. Other parameters like webUser, webPassword etc. are only used for JIRA as well. Maybe this is because JIRA was the first system
        Hide
        Dennis Lundberg added a comment -

        I'm sure that this is well documented. That is not the problem. The parameters you mention was most likely added when JIRA was the only supported "external" issue management system. Hence there was no need at the time to prefix them with "jira". We might consider deprecating those parameters and introducing new ones with a prefix, but that's another issue

        My concern is what happens when the Trac or Github fetchers wants a similar parameter. In my opinion it is wise at this time to prefix a new parameter with the issue management system it is used for, if it only works for one. If the parameter works for all issue management systems then there is no need for a prefix.

        Show
        Dennis Lundberg added a comment - I'm sure that this is well documented. That is not the problem. The parameters you mention was most likely added when JIRA was the only supported "external" issue management system. Hence there was no need at the time to prefix them with "jira". We might consider deprecating those parameters and introducing new ones with a prefix, but that's another issue My concern is what happens when the Trac or Github fetchers wants a similar parameter. In my opinion it is wise at this time to prefix a new parameter with the issue management system it is used for, if it only works for one. If the parameter works for all issue management systems then there is no need for a prefix.
        Hide
        Mirko Friedenhagen added a comment - - edited

        I took a look into the Github and Trac downloaders and there does not seem to be a simple way set timeouts, the clients are set up in depending libraries, so I committed http://svn.apache.org/viewvc?view=revision&revision=1626681. Thanks for your feedback, Dennis.

        Uploaded new SNAPSHOT https://repository.apache.org/content/repositories/snapshots/org/apache/maven/plugins/maven-changes-plugin/2.11-SNAPSHOT/maven-changes-plugin-2.11-20140922.080939-195.pom

        Show
        Mirko Friedenhagen added a comment - - edited I took a look into the Github and Trac downloaders and there does not seem to be a simple way set timeouts, the clients are set up in depending libraries, so I committed http://svn.apache.org/viewvc?view=revision&revision=1626681 . Thanks for your feedback, Dennis. Uploaded new SNAPSHOT https://repository.apache.org/content/repositories/snapshots/org/apache/maven/plugins/maven-changes-plugin/2.11-SNAPSHOT/maven-changes-plugin-2.11-20140922.080939-195.pom
        Hide
        Robert Scholte added a comment -

        I agree that we must be careful when specifying parameters, but a connection timeout sounds very general for me. So my choice would be to keep it as the original commit and add to the comments for which issue tracking systems it can be used, i.e just Jira for now. Otherwise we could end up with 5 connectionTimeouts for 5 different issue systems which actually refer to the same thing.

        Show
        Robert Scholte added a comment - I agree that we must be careful when specifying parameters, but a connection timeout sounds very general for me. So my choice would be to keep it as the original commit and add to the comments for which issue tracking systems it can be used, i.e just Jira for now. Otherwise we could end up with 5 connectionTimeouts for 5 different issue systems which actually refer to the same thing.
        Hide
        Mirko Friedenhagen added a comment -

        Robert Scholte, while a general parameter might be feasible in the future, right now neither Trac nor GitHub are an easy task to tackle as they hide their clients very deeply. In the spirit of releasing more often, I would go for the jira* solution and when we have a more general solution to take the unprefixed parameters as defaults for the other ones.

        Show
        Mirko Friedenhagen added a comment - Robert Scholte , while a general parameter might be feasible in the future, right now neither Trac nor GitHub are an easy task to tackle as they hide their clients very deeply. In the spirit of releasing more often, I would go for the jira* solution and when we have a more general solution to take the unprefixed parameters as defaults for the other ones.
        Show
        Mirko Friedenhagen added a comment - - edited I now had the chance to test my changes and had to commit another patch http://svn.apache.org/viewvc?view=revision&revision=1626972 , I uploaded the new SNAPSHOT as well ( https://repository.apache.org/content/repositories/snapshots/org/apache/maven/plugins/maven-changes-plugin/2.11-SNAPSHOT/maven-changes-plugin-2.11-20140923.102115-199.pom )
        Hide
        Mirko Friedenhagen added a comment -

        We did test this version successfully internally.

        Show
        Mirko Friedenhagen added a comment - We did test this version successfully internally.

          People

          • Assignee:
            Mirko Friedenhagen
            Reporter:
            Boris Pavlovic
          • Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development