Uploaded image for project: 'Nuxeo Platform'
  1. Nuxeo Platform
  2. NXP-18650

Review sample Nuxeo Package configuration to ease up install on HF distributions

    Details

      Description

      The default configuration for Nuxeo Packages uses the following convention:

      in assembly.xml:

      <filter token="DISTRIB_VERSION" value="${nuxeo.distribution.version}" />
      

      in package.xml:

      <platforms>
        <platform>cap-@DISTRIB_VERSION@</platform>
        <platform>cap-@DISTRIB_VERSION@-HF*</platform>
      </platforms>
      

      This produces weird mapping wrt HF version on master SNAPSHOT modules, for instance:

      https://connect.nuxeo.com/nuxeo/site/marketplace/package/nuxeo-drive
      1.6.0-SNAPSHOT Target platforms : cap-8.1-SNAPSHOT, cap-8.1-SNAPSHOT-HF*

      (cap-8.1-SNAPSHOT-HF* will not match any distribution version)

      This produces also weird configurations on maintenance branches, again with drive here:
      1.5.5-SNAPSHOT Target platforms : cap-7.10-HF02-SNAPSHOT, cap-7.10-HF02-SNAPSHOT-HF*

      As a result, it's quite difficult to install a SNAPSHOT package on a SNAPSHOT (HF or not) distribution, even if this produces valid configurations at release time (not HF releases, other releases)

      As an alternative, it would be good to make these configurations suitable for maintenance too, as it's been done on smart-search addon (for instance), see solution at https://github.com/nuxeo/marketplace-smart-search/commit/73480de5675d0c7cc27d014b8f2a0ae2a37c7104

      in assembly.xml:

      <filter token="DISTRIB_VERSION" value="${package.target.version}" />
      <filter token="SNAPSHOT_SUFFIX" value="${package.snapshot.suffix}" />
      

      in package.xml:

      <platforms>
        <platform>cap-@DISTRIB_VERSION@@SNAPSHOT_SUFFIX@</platform>
        <platform>cap-@DISTRIB_VERSION@-HF*@SNAPSHOT_SUFFIX@</platform>
      </platforms>
      

      in main package pom.xml:

      <properties>
        <package.target.version>7.10</package.target.version>
        <package.snapshot.suffix>-SNAPSHOT</package.snapshot.suffix>
      </properties>
      
      [...]
      
      <profiles>
        <profile>
          <id>release</id>
          <properties>
            <package.snapshot.suffix></package.snapshot.suffix>
          </properties>
      </profile>
      

        Attachments

          Issue Links

            Activity

            Hide
            jcarsique Julien Carsique added a comment -

            There are multiple subjects:

            • the use of HF distributions,
            • the set of the "-HF*" pattern,
            • the target compliance for maintenance packages.

            I guess you're addressing the question backwards:

            Review sample Nuxeo Package configuration to ease up install on HF distributions

            Install on HF distributions is not a covered usage. That can be discussed and implemented but for now, there's no reason to ease up a bad practice, even less to show it in the samples.
            => If you have a legitimate use case, please describe it. Then we'll be able to work on making those distributions usable.

            There's already a JIRA ticket handling that subject: NXP-14085 - Make the MP system usable with "hotfixed distribution"
            Once/if implemented, the solution must work without any change in the current assemblies.

            About a Nuxeo Package requiring a Hotfix Package, please read NXDOC/Package Manifest.

            The use of the "HF-" pattern was a solution to avoid hardcoding the HF compliance in the Java code at a time when there was no valid use case for a HF distribution. That can be reviewed if all the packages now have to mention both "cap-@DISTRIB_VERSION@" and "cap-@DISTRIB_VERSION@-HF" targets.
            As you highlighted:

            • the target on the SNAPSHOT version are not really accurate, it will become accurate once released:
              "cap-8.1-SNAPSHOT, cap-8.1-SNAPSHOT-HF*" => "cap-8.1, cap-8.1-HF*"
            • the target on maintenance branches must be reviewed after branch creation, hardcoding the release reference:
              "cap-@DISTRIB_VERSION@" and "cap-@DISTRIB_VERSION@-HF*" => "cap-7.10, cap-7.10-HF*" instead of "cap-7.10-HF02-SNAPSHOT, cap-7.10-HF02-SNAPSHOT-HF*"

            << As a result, it's quite difficult to install a SNAPSHOT package on a SNAPSHOT (HF or not) distribution, even if this produces valid configurations at release time (not HF releases, other releases) >>
            You described a "wrong" development use case (nuxeo-drive). The install of a SNAPSHOT package on a SNAPSHOT distribution works fine (see 3d below).
            Let's look at the known use cases during the 8.1 development cycle:

            - - a b c d
            - - release distribution
            7.10
            development distribution
            8.1-SNAPSHOT
            hotfix distribution
            7.10-HF02
            maintenance distribution
            7.10-HF02-SNAPSHOT
            1 release package (1.0)
            cap-7.10, cap-7.10-HF*
            OK NA OK OK
            2 development package (1.1-SNAPSHOT)
            cap-8.1-SNAPSHOT, ...
            NA OK NA NA
            3 maintenance package (1.0-SNAPSHOT)
            cap-7.10-HF02-SNAPSHOT, ...
            KO NA KO OK
            4 maintenance package (1.0-SNAPSHOT)
            cap-7.10, cap-7.10-HF*
            OK NA OK OK

            Case 3a may be an issue but most of the time the package would not work, missing the HF01 changes (and sometimes also the HF02-SNAPSHOT changes).
            Case 3c is not an issue while we do not support the hotfix distributions and don't have a valid use case for that.

            So, the current implementation covers all the known use cases (production, development, continuous integration).

            4) A slight improvement on the release process would additionally cover the potentially legitimate use case 4a plus the controversial hotfix case 4c.
            Since it's rarely needed, it is currently manually done: this requires only one simple change on maintenance branch creation:

            -    <platform>cap-@DISTRIB_VERSION@</platform>
            -    <platform>cap-@DISTRIB_VERSION@-HF*</platform>
            +    <platform>cap-7.10</platform>
            +    <platform>cap-7.10-HF*</platform> 

            That can/should be automated. It should be easy to replace @DISTRIB_VERSION@ with 7.10 (the release value).

            We can even still introduce a nuxeo.target.version property, equal to ${nuxeo.distribution.version} during dev and to the release version during maintenance, which would keep the assembly unchanged and nicely bring back the version management in the POM:

            -        <filter token="DISTRIB_VERSION" value="${nuxeo.distribution.version}" />
            +        <filter token="DISTRIB_VERSION" value="${target.distribution.version}" />
            
            +  <properties>
            +    <target.distribution.version>${nuxeo.distribution.version}</target.distribution.version>
            +  </properties> 

            About your solution:

            -        <filter token="DISTRIB_VERSION" value="${nuxeo.distribution.version}" />
            +        <filter token="DISTRIB_VERSION" value="${package.target.version}" />
            +        <filter token="SNAPSHOT_SUFFIX" value="${package.snapshot.suffix}" /> 
            
            -    <platform>cap-@DISTRIB_VERSION@</platform>
            -    <platform>cap-@DISTRIB_VERSION@-HF*</platform>
            +    <platform>cap-@DISTRIB_VERSION@@SNAPSHOT_SUFFIX@</platform>
            +    <platform>cap-@DISTRIB_VERSION@-HF*@SNAPSHOT_SUFFIX@</platform> 
            
            +  <properties>
            +    <package.target.version>7.10</package.target.version>
            +    <package.snapshot.suffix>-SNAPSHOT</package.snapshot.suffix>
            +  </properties> 

            This also needs to be done on maintenance branch creation but seems harder to automate because of the version split.

            Show
            jcarsique Julien Carsique added a comment - There are multiple subjects: the use of HF distributions, the set of the "-HF*" pattern, the target compliance for maintenance packages. I guess you're addressing the question backwards: Review sample Nuxeo Package configuration to ease up install on HF distributions Install on HF distributions is not a covered usage. That can be discussed and implemented but for now, there's no reason to ease up a bad practice, even less to show it in the samples. => If you have a legitimate use case, please describe it. Then we'll be able to work on making those distributions usable. There's already a JIRA ticket handling that subject: NXP-14085 - Make the MP system usable with "hotfixed distribution" Once/if implemented, the solution must work without any change in the current assemblies. About a Nuxeo Package requiring a Hotfix Package, please read NXDOC/Package Manifest . The use of the " HF- " pattern was a solution to avoid hardcoding the HF compliance in the Java code at a time when there was no valid use case for a HF distribution. That can be reviewed if all the packages now have to mention both " cap-@DISTRIB_VERSION@ " and " cap-@DISTRIB_VERSION@-HF " targets. As you highlighted: the target on the SNAPSHOT version are not really accurate, it will become accurate once released: " cap-8.1-SNAPSHOT, cap-8.1-SNAPSHOT-HF* " => " cap-8.1, cap-8.1-HF* " the target on maintenance branches must be reviewed after branch creation, hardcoding the release reference: " cap-@DISTRIB_VERSION@" and "cap-@DISTRIB_VERSION@-HF* " => " cap-7.10, cap-7.10-HF* " instead of " cap-7.10-HF02-SNAPSHOT, cap-7.10-HF02-SNAPSHOT-HF* " << As a result, it's quite difficult to install a SNAPSHOT package on a SNAPSHOT (HF or not) distribution, even if this produces valid configurations at release time (not HF releases, other releases) >> You described a "wrong" development use case (nuxeo-drive). The install of a SNAPSHOT package on a SNAPSHOT distribution works fine (see 3d below). Let's look at the known use cases during the 8.1 development cycle: - - a b c d - - release distribution 7.10 development distribution 8.1-SNAPSHOT hotfix distribution 7.10-HF02 maintenance distribution 7.10-HF02-SNAPSHOT 1 release package (1.0) cap-7.10, cap-7.10-HF* OK NA OK OK 2 development package (1.1-SNAPSHOT) cap-8.1-SNAPSHOT, ... NA OK NA NA 3 maintenance package (1.0-SNAPSHOT) cap-7.10-HF02-SNAPSHOT, ... KO NA KO OK 4 maintenance package (1.0-SNAPSHOT) cap-7.10, cap-7.10-HF* OK NA OK OK Case 3a may be an issue but most of the time the package would not work, missing the HF01 changes (and sometimes also the HF02-SNAPSHOT changes). Case 3c is not an issue while we do not support the hotfix distributions and don't have a valid use case for that. So, the current implementation covers all the known use cases (production, development, continuous integration). 4) A slight improvement on the release process would additionally cover the potentially legitimate use case 4a plus the controversial hotfix case 4c. Since it's rarely needed, it is currently manually done: this requires only one simple change on maintenance branch creation: - <platform>cap-@DISTRIB_VERSION@</platform> - <platform>cap-@DISTRIB_VERSION@-HF*</platform> + <platform>cap-7.10</platform> + <platform>cap-7.10-HF*</platform> That can/should be automated. It should be easy to replace @DISTRIB_VERSION@ with 7.10 (the release value). We can even still introduce a nuxeo.target.version property, equal to ${nuxeo.distribution.version } during dev and to the release version during maintenance, which would keep the assembly unchanged and nicely bring back the version management in the POM: - <filter token= "DISTRIB_VERSION" value= "${nuxeo.distribution.version}" /> + <filter token= "DISTRIB_VERSION" value= "${target.distribution.version}" /> + <properties> + <target.distribution.version>${nuxeo.distribution.version}</target.distribution.version> + </properties> About your solution: - <filter token= "DISTRIB_VERSION" value= "${nuxeo.distribution.version}" /> + <filter token= "DISTRIB_VERSION" value= "${ package .target.version}" /> + <filter token= "SNAPSHOT_SUFFIX" value= "${ package .snapshot.suffix}" /> - <platform>cap-@DISTRIB_VERSION@</platform> - <platform>cap-@DISTRIB_VERSION@-HF*</platform> + <platform>cap-@DISTRIB_VERSION@@SNAPSHOT_SUFFIX@</platform> + <platform>cap-@DISTRIB_VERSION@-HF*@SNAPSHOT_SUFFIX@</platform> + <properties> + < package .target.version>7.10</ package .target.version> + < package .snapshot.suffix>-SNAPSHOT</ package .snapshot.suffix> + </properties> This also needs to be done on maintenance branch creation but seems harder to automate because of the version split.

              People

              • Votes:
                0 Vote for this issue
                Watchers:
                3 Start watching this issue

                Dates

                • Created:
                  Updated: