Uploaded image for project: 'HBase'
  1. HBase
  2. HBASE-27340

Artifacts with resolved profiles

    XMLWordPrintableJSON

Details

    • Improvement
    • Status: Resolved
    • Minor
    • Resolution: Fixed
    • None
    • 2.6.0, 2.5.1, 3.0.0-alpha-4
    • build, pom
    • None
    • Reviewed
    • Hide
      Published poms now contain runtime dependencies only; build and test time dependencies are stripped. Profiles are also now resolved and in-lined at publish time. This removes the need/ability of downstreamers shaping hbase dependencies via enable/disable of hbase profile settings (Implication is that now the hbase project publishes artifacts for hadoop2 and for hadoop3, and so on).
      Show
      Published poms now contain runtime dependencies only; build and test time dependencies are stripped. Profiles are also now resolved and in-lined at publish time. This removes the need/ability of downstreamers shaping hbase dependencies via enable/disable of hbase profile settings (Implication is that now the hbase project publishes artifacts for hadoop2 and for hadoop3, and so on).

    Description

      Brainstorming/Discussion. The maven-flatten-plugin makes it so published poms are 'flattened'. The poms contain the runtime-necessary dependencies only, 'build' and 'test' dependencies and plugins are dropped, versions are resolved out of properties, and so on. The published poms are the barebones minimum needed to run.

      With a switch, the plugin can also make it so the produced poms have all profiles 'resolved' – making it so the produced poms have all resolved hadoop2 or hadoop3 dependencies baked-in – based off which profile we used building.

      (I've been interested in this flattening technique since I ran into a downstreamer using hbase from a gradle build. Gradle does not respect profiles. You can't specify that the gradle build pull in hbase with hadoop3 dependencies using 'profiles'. I notice too our gjacoby , apurtell et al. up on the dev list talking about making a hadoop3 set of artifacts...who might be interested in this direction).

      The attached patch adds the flatten plugin so folks can take a look-see. It uncovers some locations where our versioning on dependencies is not explicit. The workaround practiced here was adding hadoop2/hadoop3 profiles into sub-modules that were missing them or moving problematic dependencies that were outside of profiles under profiles in sub-modules that had them already. For the latter, if the dependency specified excludes, the excludes were moved up to the parent pom profile (parent pom profiles have dependencyManagement sections... sub-modules have explicit dependency mentions... checks with dependency:tree seem to show excludes continue to be effective).

      This is the switch that flattens profiles:           <embedBuildProfileDependencies>true</embedBuildProfileDependencies>

      This is the sort of complaint we had when the flatten plugin was having trouble figure dependency versions – particularly hadoop versions

      [ERROR] Failed to execute goal org.codehaus.mojo:flatten-maven-plugin:1.3.0:flatten (flatten) on project hbase-hadoop2-compat: 3 problems were encountered while building the effective model for org.apache.hbase:hbase-hadoop2-compat:2.5.1-SNAPSHOT

      [ERROR] [WARNING] 'build.plugins.plugin.version' for org.codehaus.mojo:flatten-maven-plugin is missing. @

      [ERROR] [ERROR] 'dependencies.dependency.version' for org.apache.hadoop:hadoop-mapreduce-client-core:jar is missing. @

      [ERROR] [ERROR] 'dependencies.dependency.version' for javax.activation:javax.activation-api:jar is missing. @

      Attachments

        Issue Links

          Activity

            People

              stack Michael Stack
              stack Michael Stack
              Votes:
              0 Vote for this issue
              Watchers:
              6 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: