Uploaded image for project: 'jclouds'
  1. jclouds
  2. JCLOUDS-1497

Fix jclouds-labs after JCLOUDS-1496

Attach filesAttach ScreenshotVotersWatch issueWatchersCreate sub-taskLinkCloneUpdate Comment AuthorReplace String in CommentUpdate Comment VisibilityDelete Comments
    XMLWordPrintableJSON

Details

    • Task
    • Status: Resolved
    • Major
    • Resolution: Fixed
    • None
    • 2.2.0
    • jclouds-core
    • None

    Description

      See https://builds.apache.org/job/jclouds-labs/46/
      In order to reproduce run in jclouds-labs

       mvn -DskipTests  install  -U -e -Psrc,doc,jenkins
      

      checkstyle-suppressions.xml is not found in jclouds-labs. checkstyle.xml is found because it is included in jclouds-resources.jar. Adding checkstyle-suppressions to jclouds-resources did not work either:

      checkstyle-6.1.1 does load supressions from the class path, but IMO incorrectly (see https://github.com/checkstyle/checkstyle/blob/checkstyle-6.1.1/src/main/java/com/puppycrawl/tools/checkstyle/filters/SuppressionsLoader.java )

      // check to see if the file is in the classpath
                          try {
                              final URL configUrl = SuppressionsLoader.class
                                      .getResource(aFilename);
                              if (configUrl == null) {
                                  throw new FileNotFoundException(aFilename);
                              }
                              uri = configUrl.toURI();
       

      This won't load stuff from jclouds-resources.jar on the classpath, but resources from checkstyle itself.
      Even using current checkstyle will not work, since this code has only been refactored but func-wise not altered.

      So we have only a limited number of options (beyond fixing checkstyle).

      1. Add the file/dir resources/checkstyle-suppressions.xml to jclouds (having an ugly dependency)
      2. Remove the check triggering the checkstyle problem.

      The check triggering the problem where we need the suppressions for, is the "header" module checking for the presence of the proper apache license header in each java file.

      May I suggest to remove the "header" check, since it is already covered by the apache-rat tool anyway? (Problem arises because some autogenerated transient code does not include the ASF license header.)

      Attachments

        Issue Links

        Activity

          This comment will be Viewable by All Users Viewable by All Users
          Cancel

          People

            Unassigned Unassigned
            oflebbe Olaf Flebbe
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved:

              Time Tracking

                Estimated:
                Original Estimate - Not Specified
                Not Specified
                Remaining:
                Remaining Estimate - 0h
                0h
                Logged:
                Time Spent - 2h 10m
                2h 10m

                Slack

                  Issue deployment