Details

    • Type: Sub-task Sub-task
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      None

      Description

      It's a best practice to have a separate reactor pom from parent pom. More details in FLUME-2199.

        Issue Links

          Activity

          Hide
          Brock Noland added a comment -

          Andrew Bayer would you have a couple minutes to share your best practices?

          As I understand it the root pom should only do aggregation while the parent pom should do everything that is inherited by the modules. Is that correct?

          Show
          Brock Noland added a comment - Andrew Bayer would you have a couple minutes to share your best practices? As I understand it the root pom should only do aggregation while the parent pom should do everything that is inherited by the modules. Is that correct?
          Hide
          Andrew Bayer added a comment -

          Yes, do separate them if you possibly can - if you're just running mvn clean install with no special magic (i.e., no javadoc aggregation, site gen, etc, and any assembly is in a separate module, not in the top-level POM), you'll be ok, but if you're doing anything at all strange (which, most likely, you are!), it's much, much cleaner to have a separate hive-parent/pom.xml or something like that, with the common build plugin configs, dependency management sections, properties, etc that need to be inherited by everything else, and then have everything else, including the top-level POM, inherit from that parent. The parent would still be one of the modules in the top-level POM, but that works out ok. Then you can do whatever whacky aggregation stuff you need in the top-level POM while being sure they'll run after all the other modules - if everything inherits from the top-level POM, it's gotta build before everything else, which can lead to needing to do a second mvn call for site/javadoc aggregation/etc or you end up picking up stale bits (or the build barfs if there isn't already an artifact of the submodule in question with a new version, etc)...

          I'm a bit passionate on this subject, but I think the evidence backs me up: separating inheritance from reactor tends to make a faster, cleaner and more reliable build.

          Show
          Andrew Bayer added a comment - Yes, do separate them if you possibly can - if you're just running mvn clean install with no special magic (i.e., no javadoc aggregation, site gen, etc, and any assembly is in a separate module, not in the top-level POM), you'll be ok, but if you're doing anything at all strange (which, most likely, you are!), it's much, much cleaner to have a separate hive-parent/pom.xml or something like that, with the common build plugin configs, dependency management sections, properties, etc that need to be inherited by everything else, and then have everything else, including the top-level POM, inherit from that parent. The parent would still be one of the modules in the top-level POM, but that works out ok. Then you can do whatever whacky aggregation stuff you need in the top-level POM while being sure they'll run after all the other modules - if everything inherits from the top-level POM, it's gotta build before everything else, which can lead to needing to do a second mvn call for site/javadoc aggregation/etc or you end up picking up stale bits (or the build barfs if there isn't already an artifact of the submodule in question with a new version, etc)... I'm a bit passionate on this subject, but I think the evidence backs me up: separating inheritance from reactor tends to make a faster, cleaner and more reliable build.

            People

            • Assignee:
              Unassigned
              Reporter:
              Brock Noland
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:

                Development