[jira] [Resolved] (HBASE-27074) TestProcedureSchedulerConcurrency.testConcurrentWaitWake is flaky

[Andrew Kyle Purtell (Jira)]

 [ 
https://issues.apache.org/jira/browse/HBASE-27074?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrew Kyle Purtell resolved HBASE-27074.
-
Fix Version/s: (was: 2.5.1)
   (was: 3.0.0-alpha-4)
 Assignee: (was: Andrew Kyle Purtell)
   Resolution: Cannot Reproduce

> TestProcedureSchedulerConcurrency.testConcurrentWaitWake is flaky
> -
>
> Key: HBASE-27074
> URL: https://issues.apache.org/jira/browse/HBASE-27074
> Project: HBase
>  Issue Type: Bug
>Affects Versions: 2.5.0
> Environment: Java version: 1.8.0_322
> OS name: "linux", version: "5.10.0-13-arm64", arch: "aarch64", family: "unix"
>Reporter: Andrew Kyle Purtell
>Priority: Minor
>
> This one might be architecture specific. Pending repro on x86_64. 
> org.apache.hadoop.hbase.procedure2.TestProcedureSchedulerConcurrency.testConcurrentWaitWake
>   Run 1:
> TestProcedureSchedulerConcurrency.testConcurrentWaitWake:60->testConcurrentWaitWake:145->Object.wait:-2
>  » Interrupted

>   Run 2: PASS



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Resolved] (HBASE-27071) TestMemStoreLAB is flaky

[Andrew Kyle Purtell (Jira)]

 [ 
https://issues.apache.org/jira/browse/HBASE-27071?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrew Kyle Purtell resolved HBASE-27071.
-
Fix Version/s: (was: 2.5.1)
   (was: 3.0.0-alpha-4)
   Resolution: Cannot Reproduce

> TestMemStoreLAB is flaky
> 
>
> Key: HBASE-27071
> URL: https://issues.apache.org/jira/browse/HBASE-27071
> Project: HBase
>  Issue Type: Bug
>Affects Versions: 2.5.0
> Environment: Java version: 1.8.0_322
> OS name: "linux", version: "5.10.0-13-arm64", arch: "aarch64", family: "unix"
>Reporter: Andrew Kyle Purtell
>Priority: Minor
>
> org.apache.hadoop.hbase.regionserver.TestMemStoreLAB.testLABChunkQueue
>   Run 1: TestMemStoreLAB.testLABChunkQueue » OutOfMemory GC overhead limit 
> exceeded
>   Run 2: TestMemStoreLAB.testLABChunkQueue » OutOfMemory GC overhead limit 
> exceeded
>   Run 3: PASS
> org.apache.hadoop.hbase.regionserver.TestMemStoreLAB.testLABRandomAllocation
>   Run 1: TestMemStoreLAB.testLABRandomAllocation » OutOfMemory GC overhead 
> limit exceeded
>   Run 2: TestMemStoreLAB.testLABRandomAllocation » OutOfMemory GC overhead 
> limit exceeded
>   Run 3: PASS
> org.apache.hadoop.hbase.regionserver.TestMemStoreLAB.testLABThreading
>   Run 1: TestMemStoreLAB.testLABThreading:166 » Runtime Deferred
>   Run 2: TestMemStoreLAB.testLABThreading:166 » Runtime Deferred
>   Run 3: PASS



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Resolved] (HBASE-27072) TestCoprocessorEndpointTracing.traceAsyncTableEndpoint is flaky

[Andrew Kyle Purtell (Jira)]

 [ 
https://issues.apache.org/jira/browse/HBASE-27072?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrew Kyle Purtell resolved HBASE-27072.
-
Fix Version/s: (was: 2.5.1)
   (was: 3.0.0-alpha-4)
   Resolution: Cannot Reproduce

> TestCoprocessorEndpointTracing.traceAsyncTableEndpoint is flaky
> ---
>
> Key: HBASE-27072
> URL: https://issues.apache.org/jira/browse/HBASE-27072
> Project: HBase
>  Issue Type: Bug
>Affects Versions: 2.5.0
> Environment: Java version: 1.8.0_322
> OS name: "linux", version: "5.10.0-13-arm64", arch: "aarch64", family: "unix"
>Reporter: Andrew Kyle Purtell
>Priority: Minor
>
> org.apache.hadoop.hbase.coprocessor.TestCoprocessorEndpointTracing.traceAsyncTableEndpoint
> 

>   Run 1: TestCoprocessorEndpointTracing.traceAsyncTableEndpoint:210 
> Expected: a collection containing (SpanKind with a name that a string 
> containing "COPROC_EXEC" and SpanKind with a parentSpanId that 
> "d2a7bb4f52ee70a2" and SpanData with StatusCode that is )
>  but: SpanKind with a name that a string containing "COPROC_EXEC" name 
> was "ZKConnectionRegistry.getMetaRegionLocations", SpanKind with a name that 
> a string containing "COPROC_EXEC" name was 
> "AsyncRegionLocator.getRegionLocation", SpanKind with a name that a string 
> containing "COPROC_EXEC" name was 
> "hbase.pb.RegionServerStatusService/RegionServerReport", SpanKind with a name 
> that a string containing "COPROC_EXEC" name was "RpcServer.process", SpanKind 
> with a name that a string containing "COPROC_EXEC" name was 
> "hbase.pb.RegionServerStatusService/RegionServerReport", SpanKind with a name 
> that a string containing "COPROC_EXEC" name was "Region.getScanner", SpanKind 
> with a name that a string containing "COPROC_EXEC" name was 
> "hbase.pb.ClientService/Scan", SpanKind with a name that a string containing 
> "COPROC_EXEC" name was "RegionScanner.close", SpanKind with a name that a 
> string containing "COPROC_EXEC" name was "RpcServer.process", SpanKind with a 
> name that a string containing "COPROC_EXEC" name was 
> "AsyncRegionLocator.getRegionLocation", SpanKind with a name that a string 
> containing "COPROC_EXEC" name was "hbase.pb.ClientService/ExecService", 
> SpanKind with a name that a string containing "COPROC_EXEC" name was 
> "RpcServer.process", SpanKind with a name that a string containing 
> "COPROC_EXEC" name was "AsyncRegionLocator.getRegionLocation", SpanKind with 
> a name that a string containing "COPROC_EXEC" name was "SCAN hbase:meta", 
> SpanKind with a name that a string containing "COPROC_EXEC" name was 
> "hbase.pb.ClientService/Scan", SpanKind with a name that a string containing 
> "COPROC_EXEC" name was "traceAsyncTableEndpoint"

>   Run 2: PASS



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Resolved] (HBASE-27154) Backport missing MOB related changes to branch-2

[Andrew Kyle Purtell (Jira)]

 [ 
https://issues.apache.org/jira/browse/HBASE-27154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrew Kyle Purtell resolved HBASE-27154.
-
Fix Version/s: (was: 2.6.0)
   (was: 2.5.1)
 Assignee: (was: Andrew Kyle Purtell)
   Resolution: Fixed

I believe the task(s) represented by this Jira are complete. Reopen if that is 
not the case.

> Backport missing MOB related changes to branch-2
> 
>
> Key: HBASE-27154
> URL: https://issues.apache.org/jira/browse/HBASE-27154
> Project: HBase
>  Issue Type: Bug
>  Components: mob
>Affects Versions: 2.6.0
>Reporter: Szabolcs Bukros
>Priority: Major
>
> While trying to backport https://issues.apache.org/jira/browse/HBASE-26969 to 
> branch-2 I have found that multiple major MOB related changes are missing. 
> This change is required for FileBased SFT correctness so the changes it 
> depends on should be backported first. Also any improvement to MOB stability 
> is usually welcomed.
> The missing changes I have found so far:
> https://issues.apache.org/jira/browse/HBASE-22749
> https://issues.apache.org/jira/browse/HBASE-23723
> https://issues.apache.org/jira/browse/HBASE-24163
> There is also a docs change describing the new MOB functionality. But 
> considering that the book is always generated based on master I think it is 
> safe to skip backporting it.
> https://issues.apache.org/jira/browse/HBASE-23198
> I'm planning to backport these changes one by one until we reach a state 
> where HBASE-26969  can be backported too.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Resolved] (HBASE-27365) Minimise block addition failures due to no space in bucket cache writers queue by introducing wait time

[Rajeshbabu Chintaguntla (Jira)]

 [ 
https://issues.apache.org/jira/browse/HBASE-27365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rajeshbabu Chintaguntla resolved HBASE-27365.
-
Resolution: Fixed

Thanks for reviews [~wchevreuil] for reviews. Committed to master and branch-2, 
2.4 and 2.5.

> Minimise block addition failures due to no space in bucket cache writers 
> queue by introducing wait time
> ---
>
> Key: HBASE-27365
> URL: https://issues.apache.org/jira/browse/HBASE-27365
> Project: HBase
>  Issue Type: Improvement
>  Components: BucketCache
>Affects Versions: 3.0.0-alpha-3
>Reporter: Rajeshbabu Chintaguntla
>Assignee: Rajeshbabu Chintaguntla
>Priority: Major
> Fix For: 2.6.0, 2.5.1, 3.0.0-alpha-4, 2.4.15
>
>
> Currently in bucket cache asynchronous caching mechanism introduced where 
> initially the blocks to be cached will be added to queue and writer threads 
> consume the blocks from the queue and write to bucket cache. In case if block 
> writing to bucket cache is slow then there is a chance that  queue of writer 
> threads become full  and following block additions will be failed. In case of 
> slower storages like s3 might introduce latencies even if we enable bigger 
> sizes of bucket cache using ephemeral storages. So we can allow configurable 
> wait time while adding blocks to queue so that chances of queue free up is 
> possible during the wait time and block addition failures can be minimised. 
> To avoid the performance impact of wait time in regular read paths we can use 
> the wait time mainly during background operations like compactions, flushes 
> or prefetches etc.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Re: About time for 2.5.1

[Andrew Purtell]

Sounds good Duo.

On Tue, Oct 4, 2022 at 5:15 AM 张铎(Duo Zhang)  wrote:

> Let's get HBASE-27401 in before 2.5.1. It is just some style fix about
> our javadoc and I think it will be done in a few days...
>
> Thanks.
>
> Bryan Beaudreault  于2022年10月4日周二
> 01:27写道：
> >
> > Thanks for your thoughts. I put a PR up a few moments ago for
> HBASE-27381.
> > I'll start up threads for discussing the other two points.
> >
> > On Mon, Oct 3, 2022 at 1:05 PM Andrew Purtell 
> wrote:
> >
> > > Thanks Bryan. Responses inline.
> > >
> > > On Tue, Sep 27, 2022 at 11:31 AM Bryan Beaudreault
> > >  wrote:
> > >
> > > > Thanks Andrew!
> > > >
> > > > One thing I noticed from 2.5.0 was that a few JIRAs were included in
> that
> > > > release which did not have the proper fixVersions set (so did not
> show up
> > > > in CHANGES.md
> > > ).
> > > I fixed 4 of them before realizing that may not be the way
> > > > we should handle it. See [1] for the 4 I fixed (which we could
> revert to
> > > > 2.5.1 if appropriate), there may be others.
> > > >
> > >
> > > JIRA is supposed to be the canonical source of fix version data, so if
> > > there have been mistakes, the most important thing to do is update JIRA
> > > with corrections. If I understand you correctly this is what you were
> > > doing, and that would be the correct course of action imho. Then, if
> there
> > > was a significant omission from the changelog (something critical or
> > > blocker, I would say), we could always put out another release
> announcement
> > > indicating the changelog corrections, or just do that anyway.
> > >
> > > For the 2.5.1 release I will make a note that the 2.5.0 part of the
> > > changelog should be regenerated too to pick up the corrections.
> > >
> > >
> > > > I have filed a few small bugs which I just set the fixVersion to
> 2.5.1
> > > and
> > > > will try to get PRs out for soon, but we could also push them out if
> > > > needed.
> > > >
> > > > I also have https://issues.apache.org/jira/browse/HBASE-27381
> > > 
> > > which would
> > > > be helpful to have opinions on since it might be worth fixing for
> 2.5.1
> > > if
> > > > possible. It's a recurrence of a past gnarly bug with some API
> > > > compatibility concerns.
> > > >
> > >
> > > +1 for removal. We should get this into the next 2.4 and 2.5 releases.
> I
> > > will defend the change.
> > >
> > > >
> > > > A 2.6.0 release this calendar year would be great! We have completed
> most
> > > > of the TLS work at this point. One other thing I was considering
> adding
> > > to
> > > > 2.6.0 was a backport of hbase-backups. There is a PR [2] from
> > > Mallikarjun,
> > > > we are currently evaluating internally. I think backporting to 2.x
> will
> > > > help get more exposure and contributions, since most people aren't
> > > running
> > > > 3.0-alpha and there's still a backlog of nice-to-haves in the "Phase
> 4"
> > > > jira [3] that have languished a bit. I realize this might even
> require a
> > > > VOTE thread given the past history? I was only going to bring it up
> if
> > > our
> > > > evaluation worked out, but seemed relevant to your 2.6.0 question.
> > > >
> > >
> > > Let's discuss what release criteria for TLS RPC might look like. We
> can set
> > > a tentative release date for 2.6.0 for the second week of December,
> with RC
> > > in the first week, to get things moving. Let's start a new thread on
> what
> > > kind of testing and qualification people would like to see. I have some
> > > thoughts on the minimum bar I would set as a RM.
> > >
> > > Regarding the proposed backport of hbase-backups, what I would suggest
> is
> > > raising a DISCUSS thread first. We shouldn't need a VOTE if we can get
> a
> > > consensus that the backport is fine, perhaps after giving the feature
> the
> > > usual qualification of "experimental" when performing a backport of
> this
> > > nature. An alternative viewpoint would be we should finish and polish
> the
> > > 3.0.0 release to ship backup. Help Duo finish it, get a 3.0.0 out that
> is
> > > not designated alpha. I do want to acknowledge the tradeoff... In
> order to
> > > make use of a backup feature released in 3.0.0, one would need to
> upgrade
> > > production to it, which may be a bridge too far; and so any
> significant use
> > > of it might be delayed, maybe for a long time, but if it were released
> in a
> > > 2.x version it would likely get near term evaluation. Anyway this would
> > > make a great separate DISCUSS thread :-) .
> > >
> > >
> > >
> > > >
> > > > [1]
> > > >
> > > >
> > >
> https://issues.apache.org/jira/browse/HBASE-27241?jql=text%20~%20%22%5C%22Seems%20this%20actually%20landed%20in%202.5.0%5C%22%22
> > > <
> https://issues.apache.org/jira/browse/HBASE-27241?jql=text%20~%20%22%5C%22Seems%20this%20actually%20landed%20in%202.5.0%5C%22%22
> >
> > > > [2] https://github.com/apache/hbase/pull/4770
> > > 
> > 

Re: About time for 2.5.1

[Duo Zhang]

Let's get HBASE-27401 in before 2.5.1. It is just some style fix about
our javadoc and I think it will be done in a few days...

Thanks.

Bryan Beaudreault  于2022年10月4日周二 01:27写道：
>
> Thanks for your thoughts. I put a PR up a few moments ago for HBASE-27381.
> I'll start up threads for discussing the other two points.
>
> On Mon, Oct 3, 2022 at 1:05 PM Andrew Purtell  wrote:
>
> > Thanks Bryan. Responses inline.
> >
> > On Tue, Sep 27, 2022 at 11:31 AM Bryan Beaudreault
> >  wrote:
> >
> > > Thanks Andrew!
> > >
> > > One thing I noticed from 2.5.0 was that a few JIRAs were included in that
> > > release which did not have the proper fixVersions set (so did not show up
> > > in CHANGES.md
> > ).
> > I fixed 4 of them before realizing that may not be the way
> > > we should handle it. See [1] for the 4 I fixed (which we could revert to
> > > 2.5.1 if appropriate), there may be others.
> > >
> >
> > JIRA is supposed to be the canonical source of fix version data, so if
> > there have been mistakes, the most important thing to do is update JIRA
> > with corrections. If I understand you correctly this is what you were
> > doing, and that would be the correct course of action imho. Then, if there
> > was a significant omission from the changelog (something critical or
> > blocker, I would say), we could always put out another release announcement
> > indicating the changelog corrections, or just do that anyway.
> >
> > For the 2.5.1 release I will make a note that the 2.5.0 part of the
> > changelog should be regenerated too to pick up the corrections.
> >
> >
> > > I have filed a few small bugs which I just set the fixVersion to 2.5.1
> > and
> > > will try to get PRs out for soon, but we could also push them out if
> > > needed.
> > >
> > > I also have https://issues.apache.org/jira/browse/HBASE-27381
> > 
> > which would
> > > be helpful to have opinions on since it might be worth fixing for 2.5.1
> > if
> > > possible. It's a recurrence of a past gnarly bug with some API
> > > compatibility concerns.
> > >
> >
> > +1 for removal. We should get this into the next 2.4 and 2.5 releases. I
> > will defend the change.
> >
> > >
> > > A 2.6.0 release this calendar year would be great! We have completed most
> > > of the TLS work at this point. One other thing I was considering adding
> > to
> > > 2.6.0 was a backport of hbase-backups. There is a PR [2] from
> > Mallikarjun,
> > > we are currently evaluating internally. I think backporting to 2.x will
> > > help get more exposure and contributions, since most people aren't
> > running
> > > 3.0-alpha and there's still a backlog of nice-to-haves in the "Phase 4"
> > > jira [3] that have languished a bit. I realize this might even require a
> > > VOTE thread given the past history? I was only going to bring it up if
> > our
> > > evaluation worked out, but seemed relevant to your 2.6.0 question.
> > >
> >
> > Let's discuss what release criteria for TLS RPC might look like. We can set
> > a tentative release date for 2.6.0 for the second week of December, with RC
> > in the first week, to get things moving. Let's start a new thread on what
> > kind of testing and qualification people would like to see. I have some
> > thoughts on the minimum bar I would set as a RM.
> >
> > Regarding the proposed backport of hbase-backups, what I would suggest is
> > raising a DISCUSS thread first. We shouldn't need a VOTE if we can get a
> > consensus that the backport is fine, perhaps after giving the feature the
> > usual qualification of "experimental" when performing a backport of this
> > nature. An alternative viewpoint would be we should finish and polish the
> > 3.0.0 release to ship backup. Help Duo finish it, get a 3.0.0 out that is
> > not designated alpha. I do want to acknowledge the tradeoff... In order to
> > make use of a backup feature released in 3.0.0, one would need to upgrade
> > production to it, which may be a bridge too far; and so any significant use
> > of it might be delayed, maybe for a long time, but if it were released in a
> > 2.x version it would likely get near term evaluation. Anyway this would
> > make a great separate DISCUSS thread :-) .
> >
> >
> >
> > >
> > > [1]
> > >
> > >
> > https://issues.apache.org/jira/browse/HBASE-27241?jql=text%20~%20%22%5C%22Seems%20this%20actually%20landed%20in%202.5.0%5C%22%22
> > 
> > > [2] https://github.com/apache/hbase/pull/4770
> > 
> > > [3] https://issues.apache.org/jira/browse/HBASE-17362
> > 
> > >
> > > On Tue, Sep 27, 2022 at 11:13 AM Andrew Purtell <
> > andrew.purt...@gmail.com>
> > > wrote:
> > >
> > > > We are already flattening and the proposed change adds release
> > artifacts
> > > > for hadoop3 using a new 

[jira] [Created] (HBASE-27411) Dependency on org.bouncycastle:bcprov-jdk15on:jar define multiple times

[Nick Dimiduk (Jira)]

Nick Dimiduk created HBASE-27411:


 Summary: Dependency on org.bouncycastle:bcprov-jdk15on:jar  define 
multiple times
 Key: HBASE-27411
 URL: https://issues.apache.org/jira/browse/HBASE-27411
 Project: HBase
  Issue Type: Task
  Components: build
Affects Versions: 3.0.0-alpha-4
Reporter: Nick Dimiduk


{noformat}
$ env 
JAVA_HOME=/Library/Java/JavaVirtualMachines/adoptopenjdk-11.jdk/Contents/Home 
mvn -T0.5C clean install -DskipTests

[INFO] Scanning for projects... 


[WARNING]   


[WARNING] Some problems were encountered while building the effective model for 
org.apache.hbase:hbase-server:jar:3.0.0-alpha-4-SNAPSHOT

[WARNING] 'dependencies.dependency.(groupId:artifactId:type:classifier)' must 
be unique: org.bouncycastle:bcprov-jdk15on:jar -> duplicate declaration of 
version (?) @ line 331, column 17  
[WARNING]   


[WARNING] It is highly recommended to fix these problems because they threaten 
the stability of your build.
 
[WARNING]   


[WARNING] For this reason, future Maven versions might no longer support 
building such malformed projects.   
   
[WARNING]
{noformat}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Resolved] (HBASE-23248) hbase openjdk11 compile error

[Nick Dimiduk (Jira)]

 [ 
https://issues.apache.org/jira/browse/HBASE-23248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Nick Dimiduk resolved HBASE-23248.
--
Resolution: Abandoned

> hbase openjdk11 compile error 
> --
>
> Key: HBASE-23248
> URL: https://issues.apache.org/jira/browse/HBASE-23248
> Project: HBase
>  Issue Type: Bug
>  Components: build, java
>Reporter: jackylau
>Priority: Major
> Attachments: log
>
>
> i find this 
> [https://stackoverflow.com/questions/49398894/unable-to-compile-simple-java-10-java-11-project-with-maven/55047110#55047110],
>  but it still can not solve this problem
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-shade-plugin:3.0.0:shade (default) on project 
> hbase-protocol-shaded: Error creating shaded jar: null: 
> IllegalArgumentException -> [Help 1][ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-shade-plugin:3.0.0:shade (default) on project 
> hbase-protocol-shaded: Error creating shaded jar: null: 
> IllegalArgumentException -> [Help 
> 1]org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute 
> goal org.apache.maven.plugins:maven-shade-plugin:3.0.0:shade (default) on 
> project hbase-protocol-shaded: Error creating shaded jar: null at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:212)
>  at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
>  at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
>  at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
>  at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
>  at 
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
>  at 
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
>  at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:307) at 
> org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:193) at 
> org.apache.maven.DefaultMaven.execute(DefaultMaven.java:106) at 
> org.apache.maven.cli.MavenCli.execute(MavenCli.java:863) at 
> org.apache.maven.cli.MavenCli.doMain(MavenCli.java:288) at 
> org.apache.maven.cli.MavenCli.main(MavenCli.java:199) at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native 
> Method) at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>  at 
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>  at java.base/java.lang.reflect.Method.invoke(Method.java:566) at 
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
>  at 
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229) 
> at 
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
>  at 
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)Caused
>  by: org.apache.maven.plugin.MojoExecutionException: Error creating shaded 
> jar: null at 
> org.apache.maven.plugins.shade.mojo.ShadeMojo.execute(ShadeMojo.java:546) at 
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
>  at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:207)
>  ... 20 moreCaused by: java.lang.IllegalArgumentException at 
> org.objectweb.asm.ClassReader.(Unknown Source) at 
> org.objectweb.asm.ClassReader.(Unknown Source) at 
> org.objectweb.asm.ClassReader.(Unknown Source) at 
> org.vafer.jdependency.Clazzpath.addClazzpathUnit(Clazzpath.java:201) at 
> org.vafer.jdependency.Clazzpath.addClazzpathUnit(Clazzpath.java:132) at 
> org.apache.maven.plugins.shade.filter.MinijarFilter.(MinijarFilter.java:95)
>  at 
> org.apache.maven.plugins.shade.mojo.ShadeMojo.getFilters(ShadeMojo.java:826) 
> at org.apache.maven.plugins.shade.mojo.ShadeMojo.execute(ShadeMojo.java:434) 
> ... 22 more



--
This message was sent by Atlassian Jira
(v8.20.10#820010)