Details

      Description

      Currently, names in those mojos are inconsistent with the rest and moreover, they do not correspond to the naming in the POM reference. Let's align the following to resemble element names in the POM:

      Mojo class name goal name POM element report file
      CimReport
      CiManagementReport
      cim
      ci-management
      ciManagement integration.html
      ci-management.html
      MailingListsReport mailing-list
      mailing-lists
      mailingLists mail-lists.html
      mailing-lists.html
      TeamListReport
      TeamReport
      project-team
      team
      developers, contributors team-list.html
      team.html
      LicenseReport
      LicensesReport
      license
      licenses
      licenses license.html
      licenses.html
      IssueTrackingReport
      IssueManagementReport
      issue-tracking
      issue-management
      issueManagement issue-tracking.html
      issue-management.html
      ScmReport scm scm source-repository.html
      scm.html
      ProjectSummaryReport
      SummaryReport
      summary project-summary.html
      summary.html
      ProjectIndexPageReport
      IndexReport
      index index.html
      There are no Sub-Tasks for this issue.

        Activity

        Hide
        michael-o Michael Osipov added a comment -

        Since this is a breaking change, this can be done for the next major only.

        Show
        michael-o Michael Osipov added a comment - Since this is a breaking change, this can be done for the next major only.
        Hide
        hboutemy Hervé Boutemy added a comment -

        perhaps we should align class names on outputName instead

        Show
        hboutemy Hervé Boutemy added a comment - perhaps we should align class names on outputName instead
        Hide
        michael-o Michael Osipov added a comment -

        Hervé, I do only partially agree.

        • integration is not a useful name, integration in what? Maybe continuous-integration would be even better.
        • mail-lists is fine as long as the class name contains the plural, as well as the mojo.
        • team-list, here I disagree because we already have project-X. It would rather prefer to reuse that pattern.
        Show
        michael-o Michael Osipov added a comment - Hervé, I do only partially agree. integration is not a useful name, integration in what? Maybe continuous-integration would be even better. mail-lists is fine as long as the class name contains the plural, as well as the mojo. team-list , here I disagree because we already have project-X . It would rather prefer to reuse that pattern.
        Hide
        michael-o Michael Osipov added a comment -

        Hervé, since some time has passed I have though about this lately, I like to split the ticket in two phases:

        1. phase: Introduce new mojos in 2.9 which resemble the name in the POM rather than custom names (See description) and deprecate the old ones.
        2. phase. With release 3.0 remove deprecated mojos and have the new ones only. Given that my MPIR dependencies need to be aligned first (Maven 3.x only), I am certain that this process will take more than six months.

        Show
        michael-o Michael Osipov added a comment - Hervé, since some time has passed I have though about this lately, I like to split the ticket in two phases: 1. phase: Introduce new mojos in 2.9 which resemble the name in the POM rather than custom names (See description) and deprecate the old ones. 2. phase. With release 3.0 remove deprecated mojos and have the new ones only. Given that my MPIR dependencies need to be aligned first (Maven 3.x only), I am certain that this process will take more than six months.
        Hide
        hboutemy Hervé Boutemy added a comment -

        yes, we need to find steps to improve the situation, and define target in a meaningful way: I updated issue description with a table and stroked values for changes to try to clearly describe proposed changes

        if we create 2 Mojos, people who use the plugin in reporting/plugins/plugin section without configuring reportSets/reportSet/reports/report, i.e. having "full" reports, will have changed reports twice: I don't think this is a good idea, since lazy people will not understand (2 files is not an issue, but 2 entries in menu is an issue)

        then we need to be cautious and precisely describe what "deprecating" means here: IMHO a deprecated Mojo requires to not create its report, or it will wreck havock on "full" reports
        And we can't have any warning displayed, since we can't detect if the report was explicitely configured or only part of "full" report
        Then I don't think having duplicated Mojos improves anything: it could have improved life for people configuring reportSets (with a warning and clean explanation warning message on how to use the new goal), but it would be at the price of direct users not even aware or reportSets

        then IMHO, 3.0 is not about removing duplicated Mojos but about adding introducing visible change

        the invisible change, that is the Mojo class name change, can be done independently: in 2.9 if you want

        Show
        hboutemy Hervé Boutemy added a comment - yes, we need to find steps to improve the situation, and define target in a meaningful way: I updated issue description with a table and stroked values for changes to try to clearly describe proposed changes if we create 2 Mojos, people who use the plugin in reporting/plugins/plugin section without configuring reportSets/reportSet/reports/report , i.e. having "full" reports, will have changed reports twice: I don't think this is a good idea, since lazy people will not understand (2 files is not an issue, but 2 entries in menu is an issue) then we need to be cautious and precisely describe what "deprecating" means here: IMHO a deprecated Mojo requires to not create its report, or it will wreck havock on "full" reports And we can't have any warning displayed, since we can't detect if the report was explicitely configured or only part of "full" report Then I don't think having duplicated Mojos improves anything: it could have improved life for people configuring reportSets (with a warning and clean explanation warning message on how to use the new goal), but it would be at the price of direct users not even aware or reportSets then IMHO, 3.0 is not about removing duplicated Mojos but about adding introducing visible change the invisible change, that is the Mojo class name change, can be done independently: in 2.9 if you want
        Hide
        michael-o Michael Osipov added a comment -

        First of all, thanks for the table. It makes the stuff more readable.

        I am aware that w/o explicit configuration people will be confused – granted. With deprecation I meant live side by side until 3.0. I fully understand your concerns and share them though I do not fully understand what you proposal is. Changing class names in 2.9 is OK. Do you propose to make a hard break in 3.0 with a note in the front page about deprecation of names in 2.9?

        If I understood you properly, you are proposing:

        1. phase: Make internal renaming of classes, properties, etc. and add a change note to the front page.
        2. phase: Rename goals ands output filenames, update note.

        Show
        michael-o Michael Osipov added a comment - First of all, thanks for the table. It makes the stuff more readable. I am aware that w/o explicit configuration people will be confused – granted. With deprecation I meant live side by side until 3.0. I fully understand your concerns and share them though I do not fully understand what you proposal is. Changing class names in 2.9 is OK. Do you propose to make a hard break in 3.0 with a note in the front page about deprecation of names in 2.9? If I understood you properly, you are proposing: 1. phase: Make internal renaming of classes, properties, etc. and add a change note to the front page. 2. phase: Rename goals ands output filenames, update note.

          People

          • Assignee:
            michael-o Michael Osipov
            Reporter:
            michael-o Michael Osipov
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:

              Development