Bigtop
  1. Bigtop
  2. BIGTOP-1248

artifact version can be replaced during build

    Details

    • Type: Improvement Improvement
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: backlog
    • Fix Version/s: None
    • Component/s: build
    • Labels:
      None

      Description

      Artifact version can be replaced during build:

      1. requirement

      some vendors use bigtop to build packages including different components. The code in component is already changed. so they need to change artifact version and deploy artifact to vendor's maven repo. bigtop is expected to change artifact version during build

      2. bigtop existing implementation

      artifact version is hardcoded. for example, hadoop artifact version in bigtop 0.6 is 2.0.5-alpha

      3. bigtop expected behavior

      bigtop is expected to change artifact version. For example,
      in bigtop 0.6, hadoop-auth-2.0.5-alpha can be hadoop-auth-2.0.5-alpha-bigtop-0.6.jar.
      in abc vendor, hadoop-auth-2.0.5-alpha can be hadoop-auth-2.0.5-alpha-abc-0.2.jar

      4. solution/implementation

      We may implement artifact version replacement in do-component-build according to BASE_VERSION in bigtop.mk

      for example, HADOOP_BASE_VERSION=2.0.5-alpha is changed to HADOOP_BASE_VERSION=2.0.5-alpha-bigtop-0.6 in bigtop.mk
      hadoop artifact version will be changed to 2.0.5-alpha-bigtop-0.6.

      Different components have different implementation. Hadoop component may use versions:set -DnewVersion

        Activity

        Hide
        Konstantin Boudnik added a comment -

        Patch is a great starting point indeed!
        Also, if a vendor doesn't alter the - in this example - hadoop bits, then there's no need to change the name of the libs. If the said vendor does add anything into the hadoop code base - then by definition the version of the artifacts would have to be altered in the Hadoop build. I am sorta missing the usefulness of this functionality for the public at large, but I will hold to my comments until I see the patch.

        Show
        Konstantin Boudnik added a comment - Patch is a great starting point indeed! Also, if a vendor doesn't alter the - in this example - hadoop bits, then there's no need to change the name of the libs. If the said vendor does add anything into the hadoop code base - then by definition the version of the artifacts would have to be altered in the Hadoop build. I am sorta missing the usefulness of this functionality for the public at large, but I will hold to my comments until I see the patch.
        Hide
        Andrew Purtell added a comment -

        vendor build hadoop/hbase rpm with bigtop. vendor expect bigtop can change hadoop artifact version as hadoop-2.2.0-vendor-1.0.jar (in existing bigtop, artifact version is hadoop-2.2.0.jar)

        Then how about a patch from you that makes optional string substitutions on the RPM and DEB control files Guo Ruijing?

        Show
        Andrew Purtell added a comment - vendor build hadoop/hbase rpm with bigtop. vendor expect bigtop can change hadoop artifact version as hadoop-2.2.0-vendor-1.0.jar (in existing bigtop, artifact version is hadoop-2.2.0.jar) Then how about a patch from you that makes optional string substitutions on the RPM and DEB control files Guo Ruijing ?
        Hide
        Guo Ruijing added a comment - - edited

        The JIRA is trying to resolve the issue:

        vendor can use bigtop to release vendor's specific distro. the vendor want to change artifact version during build. For example,

        1) vendor download hadoop/hbase code from apache.

        2) vendor change code in hadoop/hbase

        3) vendor build hadoop/hbase rpm with bigtop. vendor expect bigtop can change hadoop artifact version as hadoop-2.2.0-vendor-1.0.jar (in existing bigtop, artifact version is hadoop-2.2.0.jar)

        the JIRA is created to replace artifact version during build.

        Show
        Guo Ruijing added a comment - - edited The JIRA is trying to resolve the issue: vendor can use bigtop to release vendor's specific distro. the vendor want to change artifact version during build. For example, 1) vendor download hadoop/hbase code from apache. 2) vendor change code in hadoop/hbase 3) vendor build hadoop/hbase rpm with bigtop. vendor expect bigtop can change hadoop artifact version as hadoop-2.2.0-vendor-1.0.jar (in existing bigtop, artifact version is hadoop-2.2.0.jar) the JIRA is created to replace artifact version during build.
        Hide
        Konstantin Boudnik added a comment -

        Sorry, I am not sure what are you trying to solve? Is it a need to keep bigtop.mk and pom.xml versions aligned? Or else?

        Show
        Konstantin Boudnik added a comment - Sorry, I am not sure what are you trying to solve? Is it a need to keep bigtop.mk and pom.xml versions aligned? Or else?

          People

          • Assignee:
            Unassigned
            Reporter:
            Guo Ruijing
          • Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated:

              Development