Accumulo
  1. Accumulo
  2. ACCUMULO-1521

If poms need to be sorted, they just get sorted

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Won't Fix
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: scripts
    • Labels:
      None

      Description

      If the pom is not sorted and you run mvn clean package, it will immediately fail stating the poms aren't sorted. Rather than making me run mvn clean -Psort, it should just always run the sort profile.

      Or sorted poms should not be required to package

        Activity

        Hide
        John Vines added a comment -

        It just seems strange to me. I'm making modifications of both pom and code, and I wanted to do a test build. And it failed because I didn't sort it first. So I just sorted it and did the operation again. I just can't imagine a case where a developer will make changes, attempt to package, and NOT follow it up with just doing the sorting.

        But I guess it is the better way to go. Having the build fail when it happens will notify the perpetrator that they messed up. Otherwise you could have a perpetually bad pom in svn. There is the option of having jenkins using a different profile to provide the different feedback, but it's not worth the effort IMO.

        Show
        John Vines added a comment - It just seems strange to me. I'm making modifications of both pom and code, and I wanted to do a test build. And it failed because I didn't sort it first. So I just sorted it and did the operation again. I just can't imagine a case where a developer will make changes, attempt to package, and NOT follow it up with just doing the sorting. But I guess it is the better way to go. Having the build fail when it happens will notify the perpetrator that they messed up. Otherwise you could have a perpetually bad pom in svn. There is the option of having jenkins using a different profile to provide the different feedback, but it's not worth the effort IMO.
        Hide
        Christopher Tubbs added a comment -

        things will be compiled before committing anyway

        Can you guarantee this? I don't know of any way to guarantee this. But, we can check for it by verifying the POM structure, like we are currently doing. If somebody commits a poorly structured POM, I want the CI server to fail... not to just fix the user's failure to do their due diligence to test before committing. This is no different than adding a checkstyle plugin to the build as so many other projects do. I also don't want to build a clean checkout, only to find that what was built did not match what was checked out, because the plugin just resorted the POM without my knowledge.

        If things are being edited in the pom for the release, then there's something wrong

        Things aren't being edited in the pom for the release. The problem is that this plugin will potentially edit the pom during a release if you make it automatically sort during a build. The release plugin runs through the build, running all the tests. I suppose we could change things so that the verify happens instead of sort during a release build. But that means that the release artifacts cannot be easily reproduced without excessive documentation to explain why a profile should be activated during a release (tagging), but not when reproducing the release (building the tag).

        I prefer the explicit practice of: when you change the POM, make sure you change it in a way that conforms to the standards that are enforced. Then, everybody else who never want to touch a POM can go on about their business without the concern of "why did my POM change when I built? what changes were made and why? how do I fix them?". Those questions should be scoped to the user who made the POM change that disrupted the sort/structure. And verify is the only way we can enforce this.

        However (in spite of my attempts to explain the potential problems in detail), I also don't feel very strongly about this.

        Show
        Christopher Tubbs added a comment - things will be compiled before committing anyway Can you guarantee this? I don't know of any way to guarantee this. But, we can check for it by verifying the POM structure, like we are currently doing. If somebody commits a poorly structured POM, I want the CI server to fail... not to just fix the user's failure to do their due diligence to test before committing. This is no different than adding a checkstyle plugin to the build as so many other projects do. I also don't want to build a clean checkout, only to find that what was built did not match what was checked out, because the plugin just resorted the POM without my knowledge. If things are being edited in the pom for the release, then there's something wrong Things aren't being edited in the pom for the release. The problem is that this plugin will potentially edit the pom during a release if you make it automatically sort during a build. The release plugin runs through the build, running all the tests. I suppose we could change things so that the verify happens instead of sort during a release build. But that means that the release artifacts cannot be easily reproduced without excessive documentation to explain why a profile should be activated during a release (tagging), but not when reproducing the release (building the tag). I prefer the explicit practice of: when you change the POM, make sure you change it in a way that conforms to the standards that are enforced. Then, everybody else who never want to touch a POM can go on about their business without the concern of "why did my POM change when I built? what changes were made and why? how do I fix them?". Those questions should be scoped to the user who made the POM change that disrupted the sort/structure. And verify is the only way we can enforce this. However (in spite of my attempts to explain the potential problems in detail), I also don't feel very strongly about this.
        Hide
        John Vines added a comment -

        The cleanup will not create a backup file if it's already sorted, so the issue of it creating a backup file in the tarball is moot since things will be compiled before committing anyway. If things are being edited in the pom for the release, then there's something wrong with the release process.

        I can see the check being part of the release process, but using them for just doing a build seems excessive.

        Show
        John Vines added a comment - The cleanup will not create a backup file if it's already sorted, so the issue of it creating a backup file in the tarball is moot since things will be compiled before committing anyway. If things are being edited in the pom for the release, then there's something wrong with the release process. I can see the check being part of the release process, but using them for just doing a build seems excessive.
        Hide
        Christopher Tubbs added a comment -

        This basically falls into the same category as source formatting standards. Would you want the java formatting standards to be applied on every build? Or just a check for compliance? I've never seen the former done... but the latter is common practice. I followed this convention.

        Show
        Christopher Tubbs added a comment - This basically falls into the same category as source formatting standards. Would you want the java formatting standards to be applied on every build? Or just a check for compliance? I've never seen the former done... but the latter is common practice. I followed this convention.
        Hide
        Christopher Tubbs added a comment -

        We do not want to sort automatically, because sorting creates backup files that could be included in a tarball or other package during a release, and it also can cause problems with the release plugin's checks to ensure that there are no outstanding edits prior to building for a release (you don't want to edit the source tree during a build).

        This plugin was only added as a convenience to apply some maven standards to the POM, or organization that some people were adding manually when they edited the POM. You almost never need to touch the POM, though, so automatically sorting has the potential to create more problems than it helps.

        Show
        Christopher Tubbs added a comment - We do not want to sort automatically, because sorting creates backup files that could be included in a tarball or other package during a release, and it also can cause problems with the release plugin's checks to ensure that there are no outstanding edits prior to building for a release (you don't want to edit the source tree during a build). This plugin was only added as a convenience to apply some maven standards to the POM, or organization that some people were adding manually when they edited the POM. You almost never need to touch the POM, though, so automatically sorting has the potential to create more problems than it helps.
        Hide
        John Vines added a comment -

        It's a requirement that has no real impact on actually building the damn thing. We trust the pom sorter enough to make it the validation point for having things sorted, so why is it a problem if it sorts automatically?

        Show
        John Vines added a comment - It's a requirement that has no real impact on actually building the damn thing. We trust the pom sorter enough to make it the validation point for having things sorted, so why is it a problem if it sorts automatically?
        Hide
        Josh Elser added a comment -

        It's activating it when the normal build process forces you to.

        .. again, when you made the poms not sorted in the first place.

        Show
        Josh Elser added a comment - It's activating it when the normal build process forces you to. .. again, when you made the poms not sorted in the first place.
        Hide
        John Vines added a comment - - edited

        It's not really a case of activating it when you want it. It's activating it when the normal build process forces you to. The only difference is whether or not there's a second step of user intervention involved. Not the same thing.

        Show
        John Vines added a comment - - edited It's not really a case of activating it when you want it. It's activating it when the normal build process forces you to. The only difference is whether or not there's a second step of user intervention involved. Not the same thing.
        Hide
        David Medinets added a comment -

        +1 for automatic handling of sorting.

        Show
        David Medinets added a comment - +1 for automatic handling of sorting.
        Hide
        Josh Elser added a comment -

        I'm not arguing with you about unsorted poms not being directly useful, but you still did something that caused them to be unsorted. I like the poms being sorted (and have converted my projects to use it too).

        I suppose it's just a matter of opinion. I like being specific and activating that profile when I want to. You don't. Does anyone else care?

        Show
        Josh Elser added a comment - I'm not arguing with you about unsorted poms not being directly useful, but you still did something that caused them to be unsorted. I like the poms being sorted (and have converted my projects to use it too). I suppose it's just a matter of opinion. I like being specific and activating that profile when I want to. You don't. Does anyone else care?
        Hide
        John Vines added a comment -

        But it makes no difference because you can't DO anything with the unsorted poms

        Show
        John Vines added a comment - But it makes no difference because you can't DO anything with the unsorted poms
        Hide
        Josh Elser added a comment -

        Aren't you worried about your files being magically changed without you being aware of it? Yes a backup is made locally, but personally, I prefer to be explicit and know when I made a change that un-sorted the poms and then let an external tool try to re-sort them.

        Show
        Josh Elser added a comment - Aren't you worried about your files being magically changed without you being aware of it? Yes a backup is made locally, but personally, I prefer to be explicit and know when I made a change that un-sorted the poms and then let an external tool try to re-sort them.

          People

          • Assignee:
            Unassigned
            Reporter:
            John Vines
          • Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development