Uploaded image for project: 'WildFly Core'
  1. WildFly Core
  2. WFCORE-6055

Make Galleon provisioning content zips unique per release

    XMLWordPrintable

Details

    Description

      For background see NEXUS-630 and WFLY-16977.

      Some maven repositories object to having two artifacts with an identical hash deployed. The various zip archives we use to allow transfer of galleon content into a feature pack build may not differ from release to release, and those newer releases cannot be deployed to such repositories.

      As at least a short-term solution to this I propose simply adding the relevant pom file into the zip, and then ignoring it when building the feature pack.

      A different solution would be to convert the zip to a jar, which would naturally include the pom information and a manifest in META-INF. That might be better, but for 27 Beta1 I'm inclined to go with the simplest change and give ourselves some time to think more about what to do going forward. The zip artifacts that are actually used in feature pack builds come from core, which means an update to core, so there isn't much time for Beta1 to go beyond the bare minimum.

      Note that I'm not completely clear on the conditions that trigger the NEXUS-630 condition, as Yeray hit it when doing a core release but it then went away for unclear reasons. David Hladky mentioned some possibilities related to whether some content had been sync to maven central. But in any case, it's unclear when it will happen so to avoid disruption to the upcoming releases I'd like to get at least a short term solution in place.

      Attachments

        Issue Links

          Activity

            People

              bstansbe@redhat.com Brian Stansberry
              bstansbe@redhat.com Brian Stansberry
              Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: