[hbase-thirdparty] branch master updated: HBASE-24858 Exclude the current modules jar from the shading step (#31)

[zh...@apache.org]

This is an automated email from the ASF dual-hosted git repository.

zhangduo pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/hbase-thirdparty.git


The following commit(s) were added to refs/heads/master by this push:
     new a680d07  HBASE-24858 Exclude the current modules jar from the shading step (#31)
a680d07 is described below

commit a680d07fb51f560bfaa24add7bfeba15a52c946e
Author: Josh Elser <el...@apache.org>
AuthorDate: Sun Aug 16 22:59:14 2020 -0400

    HBASE-24858 Exclude the current modules jar from the shading step (#31)
    
    When a module's jar from the previous build of that module is left in
    place, replacing the main artifact for that module, the next build of
    that module will happen to pick up the shaded jar and try to re-shaded
    that jar.
    
    This is unexpected, as we're reading through all of the module's
    dependencies and unpackaging/relocating each of them. We do not expect
    to be getting them from the modules main artifact.
    
    The easy solution is that we just always exclude this modules jar. Given
    that these modules have no source (just a repacking of thirdparty
    projects), this is safe for us to do. Best as I can tell, the resulting
    jars are equivalently built.
    
    Signed-off-by: Duo Zhang <zh...@apache.org>
---
 hbase-shaded-jersey/pom.xml | 5 +++++
 hbase-shaded-jetty/pom.xml  | 5 +++++
 2 files changed, 10 insertions(+)

diff --git a/hbase-shaded-jersey/pom.xml b/hbase-shaded-jersey/pom.xml
index e365ed4..05514a8 100644
--- a/hbase-shaded-jersey/pom.xml
+++ b/hbase-shaded-jersey/pom.xml
@@ -101,6 +101,11 @@
                   <exclude>jakarta.validation:jakarta.validation-api</exclude>
                   <exclude>org.glassfish.hk2.external:jakarta.inject</exclude>
                   <exclude>org.javassist:javassist</exclude>
+                  <!-- On the "next" build, exclude a lingering shaded jar if it exists (user did not `clean`).
+                    Maven will happily pick up the previous shaded jar and try to include that in the N+1th build
+                    if we don't exclude it. This will result in a failure in the ServicesResourceTransformer claiming
+                    that we've already packaged a services file once. -->
+                  <exclude>org.apache.hbase.thirdparty:hbase-shaded-jersey</exclude>
                 </excludes>
               </artifactSet>
               <transformers>
diff --git a/hbase-shaded-jetty/pom.xml b/hbase-shaded-jetty/pom.xml
index 7fe4e32..e4dd093 100644
--- a/hbase-shaded-jetty/pom.xml
+++ b/hbase-shaded-jetty/pom.xml
@@ -90,6 +90,11 @@
                       produce. See below for how to exclusion of transitive dependencies.
                     -->
                   <exclude>javax.servlet:javax.servlet-api</exclude>
+                  <!-- On the "next" build, exclude a lingering shaded jar if it exists (user did not `clean`).
+                    Maven will happily pick up the previous shaded jar and try to include that in the N+1th build
+                    if we don't exclude it. This will result in a failure in the ServicesResourceTransformer claiming
+                    that we've already packaged a services file once. -->
+                  <exclude>org.apache.hbase.thirdparty:hbase-shaded-jetty</exclude>
                 </excludes>
               </artifactSet>
               <transformers>