[GitHub] [maven-dependency-plugin] dependabot[bot] opened a new pull request #98: Bump maven-dependency-analyzer from 1.11.3-SNAPSHOT to 1.11.3
dependabot[bot] opened a new pull request #98: URL: https://github.com/apache/maven-dependency-plugin/pull/98 Bumps [maven-dependency-analyzer](https://github.com/apache/maven-dependency-analyzer) from 1.11.3-SNAPSHOT to 1.11.3. Commits See full diff in https://github.com/apache/maven-dependency-analyzer/commits/maven-dependency-analyzer-1.11.3";>compare view [](https://help.github.com/articles/configuring-automated-security-fixes) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- Dependabot commands and options You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Created] (MASSEMBLY-941) file modes removed for tarball assembly since 3.2.0
Christopher Tubbs created MASSEMBLY-941: --- Summary: file modes removed for tarball assembly since 3.2.0 Key: MASSEMBLY-941 URL: https://issues.apache.org/jira/browse/MASSEMBLY-941 Project: Maven Assembly Plugin Issue Type: Bug Components: permissions Reporter: Christopher Tubbs My project (Apache Accumulo) is using the apache-23.pom parent POM with the predefined `source-release-tar` descriptor using the `single` goal. Using version 3.1.1 of this plugin, file permissions are preserved. However, since 3.2.0, file permissions seem to be ignored, and tarballs created with this plugin have executable permission removed from scripts. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MRESOLVER-134) Unsatisfiable Range header causing 416 HTTP error
[ https://issues.apache.org/jira/browse/MRESOLVER-134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17185473#comment-17185473 ] Dmitriy Panov commented on MRESOLVER-134: - Could you please advise how to do that properly? Here is an easy way to reproduce the problem [https://github.com/DmPanov/maven-resolver/commit/a4e8bdf7046155aba89362542f750ca788646e2b] > Unsatisfiable Range header causing 416 HTTP error > - > > Key: MRESOLVER-134 > URL: https://issues.apache.org/jira/browse/MRESOLVER-134 > Project: Maven Resolver > Issue Type: Bug > Components: resolver >Affects Versions: 1.3.3 >Reporter: Dmitriy Panov >Priority: Major > Attachments: broken_m2.zip > > > h3. How to reproduce > Put partially downloaded artifacts from attachment (corrupted probably due to > MNG-4706 and MRESOLVER-25) into ~/.m2/repository and try to resolve > org.junit.jupiter:junit-jupiter-api:5.0.0 > h3. Expected outcome > Artifacts are resolved > h3. Actual outcome > Caused by: org.eclipse.aether.transfer.ArtifactTransferException: Could not > transfer artifact org.junit.jupiter:junit-jupiter-api:jar:5.0.0 from/to > central (https://repo1.maven.org/maven2/): status code: 416, reason phrase: > Range Not Satisfiable (416)Caused by: > org.eclipse.aether.transfer.ArtifactTransferException: Could not transfer > artifact org.junit.jupiter:junit-jupiter-api:jar:5.0.0 from/to central > (https://repo1.maven.org/maven2/): status code: 416, reason phrase: Range Not > Satisfiable (416) at > org.eclipse.aether.connector.basic.ArtifactTransportListener.transferFailed(ArtifactTransportListener.java:52) > at > org.eclipse.aether.connector.basic.BasicRepositoryConnector$TaskRunner.run(BasicRepositoryConnector.java:369) > at > org.eclipse.aether.util.concurrency.RunnableErrorForwarder$1.run(RunnableErrorForwarder.java:75) > at > org.eclipse.aether.connector.basic.BasicRepositoryConnector$DirectExecutor.execute(BasicRepositoryConnector.java:628) > at > org.eclipse.aether.connector.basic.BasicRepositoryConnector.get(BasicRepositoryConnector.java:262) > at > org.eclipse.aether.internal.impl.DefaultArtifactResolver.performDownloads(DefaultArtifactResolver.java:499) > at > org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:400) > ... 31 more > h3. Workaround > Pass -Daether.connector.resumeDownloads=false > > Issue is still present in 1.5.0 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (JXR-156) 3.1.0 Not In Maven Central
Melloware created JXR-156: - Summary: 3.1.0 Not In Maven Central Key: JXR-156 URL: https://issues.apache.org/jira/browse/JXR-156 Project: Maven JXR Issue Type: Task Components: maven2 jxr plugin Affects Versions: 3.0.0 Reporter: Melloware I see you have 3.1.0 tagged in GitHub but not released in Maven Central? Our company is getting a security violation on 3.0.0 because it uses Xalan 2.7.0. I see its fixed in GitHub but not released? -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MJAVADOC-662) find a bug when generating static fields' javadoc.
[
https://issues.apache.org/jira/browse/MJAVADOC-662?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jin Xu updated MJAVADOC-662:
Description:
{code:java}
protected static final int MultiTime = 1 << 4;
{code}
will become
{code:java}
/** Constant MultiTime=1 << 4 */
protected static final int MultiTime = 1 << 4;
{code}
after calling fix operation.
And notice that the << in the doc is NOT allowed by html, thus will fail the
javadoc jar generation.
should use << instead.
I think I can fix it, but I'm too tired today, tomorrow I will see if I can get
some time for the fix.
was:
{code:java}
protected static final int MultiTime = 1 << 4;
{code}
will become
{code:java}
/** Constant MultiTime=1 << 4 */
protected static final int MultiTime = 1 << 4;
{code}
after calling fix operation.
And notice that the << in the doc is NOT allowed by html, should use <<
instead.
I think I can fix it, but I'm too tired today, tomorrow I will see if I can get
some time for the fix.
> find a bug when generating static fields' javadoc.
> --
>
> Key: MJAVADOC-662
> URL: https://issues.apache.org/jira/browse/MJAVADOC-662
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: fix
>Reporter: Jin Xu
>Priority: Major
>
> {code:java}
> protected static final int MultiTime = 1 << 4;
> {code}
> will become
> {code:java}
> /** Constant MultiTime=1 << 4 */
> protected static final int MultiTime = 1 << 4;
> {code}
> after calling fix operation.
> And notice that the << in the doc is NOT allowed by html, thus will fail the
> javadoc jar generation.
> should use << instead.
> I think I can fix it, but I'm too tired today, tomorrow I will see if I can
> get some time for the fix.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (MJAVADOC-662) find a bug when generating static fields' javadoc.
Jin Xu created MJAVADOC-662:
---
Summary: find a bug when generating static fields' javadoc.
Key: MJAVADOC-662
URL: https://issues.apache.org/jira/browse/MJAVADOC-662
Project: Maven Javadoc Plugin
Issue Type: Bug
Components: fix
Reporter: Jin Xu
{code:java}
protected static final int MultiTime = 1 << 4;
{code}
will become
{code:java}
/** Constant MultiTime=1 << 4 */
protected static final int MultiTime = 1 << 4;
{code}
after calling fix operation.
And notice that the << in the doc is NOT allowed by html, should use <<
instead.
I think I can fix it, but I'm too tired today, tomorrow I will see if I can get
some time for the fix.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (MNG-6979) MavenSession.getCurrentProject may return an incorrect project in a multimodule build
[
https://issues.apache.org/jira/browse/MNG-6979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
George Gastaldi updated MNG-6979:
-
Priority: Major (was: Critical)
> MavenSession.getCurrentProject may return an incorrect project in a
> multimodule build
> -
>
> Key: MNG-6979
> URL: https://issues.apache.org/jira/browse/MNG-6979
> Project: Maven
> Issue Type: Bug
> Components: core
>Affects Versions: 3.6.3
>Reporter: George Gastaldi
>Priority: Major
> Attachments: project.zip
>
>
> Having an extension that just displays the current project, like in:
> {code:java}
> @Singleton
> @Named
> public class BuildModuleSelector extends AbstractMavenLifecycleParticipant {
> @Inject
> private Logger logger;
> @Override
> public void afterProjectsRead(MavenSession session) throws
> MavenExecutionException {
> logger.info(session.getCurrentProject().toString());
>
> session.setProjects(Collections.singletonList(session.getCurrentProject()));
> }
> }
> {code}
> Will fail to resolve the current project when executed in the root of a
> project that depends on a module with the same parent.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (MEAR-280) Reproducible Builds: make entries in output ear files reproducible (order + timestamp)
[
https://issues.apache.org/jira/browse/MEAR-280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17179014#comment-17179014
]
Marat Abrarov edited comment on MEAR-280 at 8/26/20, 12:09 PM:
---
This issue looks being still actual because Maven EAR Plugin generates not
reproducible EARs when skinnyWars option is used
({{true}} in {{configuration}} of Maven EAR Plugin).
[MEAR-280|https://github.com/mabrarov/dockerfile-test/compare/develop...MEAR-280]
branch of mabrarov/dockerfile-test repository can be used for reproducing this
issue (requires Maven EAR Plugin and [Maven Artifact
Plugin|https://github.com/apache/maven-artifact-plugin] to be built and
installed into local maven repository).
With skinnyWars option:
{code:bash}
$ git clone https://github.com/mabrarov/dockerfile-test.git && \
cd dockerfile-test && \
git checkout 0220cef03f2029aa10222d9af776ee1f79a4ae9a && \
./mvnw clean install -e -DskipTests -Ddocker.skip=true && \
./mvnw clean verify -e -DskipTests artifact:buildinfo -Dreference.repo=central
-Ddocker.skip=true
...
[WARNING] size mismatch ear-1.1.7-SNAPSHOT.ear: investigate with diffoscope
target/reference/ear-1.1.7-SNAPSHOT.ear ear/target/ear-1.1.7-SNAPSHOT.ear
[WARNING] Reproducible Build output summary: 1 files ok, 1 different
[WARNING] see diff target/reference/app-image-1.1.7-SNAPSHOT.buildinfo
app-image/target/app-image-1.1.7-SNAPSHOT.buildinfo
[INFO]
[INFO] Reactor Summary for dockerfile-test 1.1.7-SNAPSHOT:
[INFO]
[INFO] dockerfile-test SUCCESS [ 1.381 s]
[INFO] war SUCCESS [ 1.190 s]
[INFO] ear SUCCESS [ 0.484 s]
[INFO] base-image . SUCCESS [ 1.275 s]
[INFO] hollow-image ... SUCCESS [ 0.163 s]
[INFO] app-image .. SUCCESS [ 0.242 s]
[INFO]
[INFO] BUILD SUCCESS
[INFO]
[INFO] Total time: 5.373 s
[INFO] Finished at: 2020-08-17T17:30:00+03:00
[INFO]
$ docker run --rm -t -w $(pwd) -v $(pwd):$(pwd):ro
registry.salsa.debian.org/reproducible-builds/diffoscope
target/reference/ear-1.1.7-SNAPSHOT.ear ear/target/ear-1.1.7-SNAPSHOT.ear
--- target/reference/ear-1.1.7-SNAPSHOT.ear
--- target/reference/ear-1.1.7-SNAPSHOT.ear
+++ ear/target/ear-1.1.7-SNAPSHOT.ear
├── zipinfo -v {}
│ @@ -283,15 +283,15 @@
│minimum file system compatibility required: MS-DOS, OS/2 or NT FAT
│minimum software version required to extract: 2.0
│compression method: deflated
│compression sub-type (deflation): normal
│file security status: not encrypted
│extended local header: no
│file last modified on (DOS date/time): 2020 Aug 17 14:23:02
│ - 32-bit CRC value (hex): f3f3d0e7
│ + 32-bit CRC value (hex): 2af2d57d
│compressed size:2523 bytes
│uncompressed size: 3687 bytes
│length of filename: 51 characters
│length of extra field: 0 bytes
│length of file comment: 0 characters
│disk number on which file begins: disk 1
│apparent file type: binary
├── org.mabrarov.dockerfile-test-war-1.1.7-SNAPSHOT.war
│ ├── zipinfo -v {}
│ │ @@ -26,15 +26,15 @@
│ │version of encoding software: 2.0
│ │minimum file system compatibility required: MS-DOS, OS/2 or NT FAT
│ │minimum software version required to extract: 2.0
│ │compression method: deflated
│ │compression sub-type (deflation): normal
│ │file security status: not encrypted
│ │extended local header: no
│ │ - file last modified on (DOS date/time): 2020 Aug 17 17:36:34
│ │ + file last modified on (DOS date/time): 2020 Aug 17 17:36:40
│ │32-bit CRC value (hex): 64f3c575
│ │compressed size:179 bytes
│ │uncompressed size: 241 bytes
│ │length of filename: 20 characters
│ │length of extra field: 0 bytes
│ │length of file comment: 0 characters
│ │disk number on which file begins: disk 1
│ │ @@
[jira] [Comment Edited] (SUREFIRE-1835) failsafe plugin's verify goal does not honor `mvn --fail-at-end`
[
https://issues.apache.org/jira/browse/SUREFIRE-1835?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17185112#comment-17185112
]
Tibor Digana edited comment on SUREFIRE-1835 at 8/26/20, 11:24 AM:
---
[~nitor-jonasb]
You should send an email to d...@maven.apache.org (see [Project Mailing
Lists|https://maven.apache.org/mailing-lists.html]) and discuss the
implementation approach.
I found the same problem at the
[stackoverflow|https://stackoverflow.com/questions/4174696/making-maven-run-all-tests-even-when-some-fail]
as well.
was (Author: tibor17):
[~nitor-jonasb]
You should send an email to
> failsafe plugin's verify goal does not honor `mvn --fail-at-end`
>
>
> Key: SUREFIRE-1835
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1835
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Failsafe Plugin
>Affects Versions: 2.20.1, 3.0.0-M4
> Environment: Maven 3.6.3
>Reporter: Jonas Berlin
>Priority: Minor
>
> If I run {color:#ff}{{mvn --fail-at-end verify}}{color} on a multi-module
> project with the following configuration in several modules
> {{}}
> {{ maven-failsafe-plugin}}
> {{ 3.0.0-M4}}
> {{ }}
> {{ }}
> {{ }}
> {{ integration-test}}
> {{ verify}}
> {{ }}
> {{ }}
> {{ }}
> {{ }}
> {{ }}
> {{ ${integration.test.glob}}}
> {{ }}
> {{ }}
> {{}}
> h2. Expected behaviour:
> Due to the {{{color:#FF}--fail-at-end{color}}} flag, tests of all modules
> are run regardless of failures and after that the maven build fails in case
> of failures.
> h2. Actual behaviour:
> The "verify" goal halts the build at the first module with a problem. If I
> add true in the
> section, it *does* run tests of all modules, but then the maven build exits
> with success regardless of failures.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (SUREFIRE-1835) failsafe plugin's verify goal does not honor `mvn --fail-at-end`
[
https://issues.apache.org/jira/browse/SUREFIRE-1835?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17185112#comment-17185112
]
Tibor Digana commented on SUREFIRE-1835:
[~nitor-jonasb]
You should send an email to
> failsafe plugin's verify goal does not honor `mvn --fail-at-end`
>
>
> Key: SUREFIRE-1835
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1835
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Failsafe Plugin
>Affects Versions: 2.20.1, 3.0.0-M4
> Environment: Maven 3.6.3
>Reporter: Jonas Berlin
>Priority: Minor
>
> If I run {color:#ff}{{mvn --fail-at-end verify}}{color} on a multi-module
> project with the following configuration in several modules
> {{}}
> {{ maven-failsafe-plugin}}
> {{ 3.0.0-M4}}
> {{ }}
> {{ }}
> {{ }}
> {{ integration-test}}
> {{ verify}}
> {{ }}
> {{ }}
> {{ }}
> {{ }}
> {{ }}
> {{ ${integration.test.glob}}}
> {{ }}
> {{ }}
> {{}}
> h2. Expected behaviour:
> Due to the {{{color:#FF}--fail-at-end{color}}} flag, tests of all modules
> are run regardless of failures and after that the maven build fails in case
> of failures.
> h2. Actual behaviour:
> The "verify" goal halts the build at the first module with a problem. If I
> add true in the
> section, it *does* run tests of all modules, but then the maven build exits
> with success regardless of failures.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MDEP-644) Reintroduce the verbose option for dependency:tree
[ https://issues.apache.org/jira/browse/MDEP-644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17185090#comment-17185090 ] Olof Larsson commented on MDEP-644: --- [~ilavallee], okay great! Then I'll happily keep my money. Thanks :). So how can I help out testing this? How do I go about running it locally? Is there an easy way to do so, or must I build it locally myself? > Reintroduce the verbose option for dependency:tree > -- > > Key: MDEP-644 > URL: https://issues.apache.org/jira/browse/MDEP-644 > Project: Maven Dependency Plugin > Issue Type: New Feature > Components: tree >Reporter: John Lin >Assignee: Elliotte Rusty Harold >Priority: Major > Labels: intern > Fix For: 3.2.0 > > > The verbose option for dependency:tree is removed in maven-dependency-plugin > 3.0. This issue is to reintroduce the option. > In verbose mode the dependency tree shows dependencies that were omitted for: > being a duplicate of another; conflicting with another's version and/or > scope; and introducing a cycle into the dependency tree. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [maven-surefire] Tibor17 edited a comment on pull request #240: [SUREFIRE-1658] TCP/IP Channel for forked Surefire JVM. Extensions API and SPI. Polymorphism for remote and local process commu
Tibor17 edited a comment on pull request #240: URL: https://github.com/apache/maven-surefire/pull/240#issuecomment-680766589 @danberindei You'r right, the link does not work. We can update the HTML of course and fix it. The reason why the element is called `forkNode` is the fact that it is not only about "connecting" two JVMs. It is still in a development. The initial idea was to call the fork JVM a "node" because there are user requirements to fork the JAR file in another place. Basically the tests may run in a distinct IP address, h/w, VM, etc. Therefore there is the name `node` because we may add more factories (where the `ForkNodeFactory ` is the first one) below the node itself and the test execution would become distributed over some nodes in your infrastructure. Imaging a factory which produces e.g. `ForkExecutor`. Currently we are building and executing a JAR in `target/surefire` for Nix systems and in temp directory for Windows by default. The user may change this behavior and distribute the execution to any h/w node, not only the local one as we know it right now. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-invoker-plugin] pzygielo opened a new pull request #25: [MINVOKER-268] - add missing space
pzygielo opened a new pull request #25: URL: https://github.com/apache/maven-invoker-plugin/pull/25 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-surefire] Tibor17 edited a comment on pull request #240: [SUREFIRE-1658] TCP/IP Channel for forked Surefire JVM. Extensions API and SPI. Polymorphism for remote and local process commu
Tibor17 edited a comment on pull request #240: URL: https://github.com/apache/maven-surefire/pull/240#issuecomment-680766589 @danberindei You'r right, the link does not work. We can update the HTML of course and fix it. The reason why the element is call it `forkNode` is the fact that it is still in a development. The initial idea was to call the fork JVM a node because there are user requirements to fork the JAR file in another place. Basically the tests may run in a distinct IP address, h/w, VM, etc. Therefore there is the name `node` because we may add more factories (where the `ForkNodeFactory ` is the first one) below the node itself and the test execution would become distributed over some nodes in your infrastructure. Imaging a factory which produces e.g. `ForkExecutor`. Currently we are building and executing a JAR in `target/surefire` for Nix systems and in temp directory for Windows by default. The user may change this behavior and distribute the execution to any h/w node, not only the local one as we know it right now. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-surefire] Tibor17 commented on pull request #240: [SUREFIRE-1658] TCP/IP Channel for forked Surefire JVM. Extensions API and SPI. Polymorphism for remote and local process communicatio
Tibor17 commented on pull request #240: URL: https://github.com/apache/maven-surefire/pull/240#issuecomment-680766589 @danberindei You'r right, the link does not work. We can update the HTML of course and fix it. The reason why the element is call it `forkNode` is the fact that it is still in a development. The initial idea was to call the fork JVM a node because there are user requirements to fork the JAR file in another place. Basically the tests may run in a distinct IP address, h/w, VM, atc. Therefore there is the name `node` because we may add more factories (where the `ForkNodeFactory ` is the first one) below the node itself and the test execution would become distributed over some nodes in your infrastructure. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MRESOLVER-134) Unsatisfiable Range header causing 416 HTTP error
[ https://issues.apache.org/jira/browse/MRESOLVER-134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17185007#comment-17185007 ] Michael Osipov commented on MRESOLVER-134: -- Do you think you could provide a debug log with HttpClient header log enabled? > Unsatisfiable Range header causing 416 HTTP error > - > > Key: MRESOLVER-134 > URL: https://issues.apache.org/jira/browse/MRESOLVER-134 > Project: Maven Resolver > Issue Type: Bug > Components: resolver >Affects Versions: 1.3.3 >Reporter: Dmitriy Panov >Priority: Major > Attachments: broken_m2.zip > > > h3. How to reproduce > Put partially downloaded artifacts from attachment (corrupted probably due to > MNG-4706 and MRESOLVER-25) into ~/.m2/repository and try to resolve > org.junit.jupiter:junit-jupiter-api:5.0.0 > h3. Expected outcome > Artifacts are resolved > h3. Actual outcome > Caused by: org.eclipse.aether.transfer.ArtifactTransferException: Could not > transfer artifact org.junit.jupiter:junit-jupiter-api:jar:5.0.0 from/to > central (https://repo1.maven.org/maven2/): status code: 416, reason phrase: > Range Not Satisfiable (416)Caused by: > org.eclipse.aether.transfer.ArtifactTransferException: Could not transfer > artifact org.junit.jupiter:junit-jupiter-api:jar:5.0.0 from/to central > (https://repo1.maven.org/maven2/): status code: 416, reason phrase: Range Not > Satisfiable (416) at > org.eclipse.aether.connector.basic.ArtifactTransportListener.transferFailed(ArtifactTransportListener.java:52) > at > org.eclipse.aether.connector.basic.BasicRepositoryConnector$TaskRunner.run(BasicRepositoryConnector.java:369) > at > org.eclipse.aether.util.concurrency.RunnableErrorForwarder$1.run(RunnableErrorForwarder.java:75) > at > org.eclipse.aether.connector.basic.BasicRepositoryConnector$DirectExecutor.execute(BasicRepositoryConnector.java:628) > at > org.eclipse.aether.connector.basic.BasicRepositoryConnector.get(BasicRepositoryConnector.java:262) > at > org.eclipse.aether.internal.impl.DefaultArtifactResolver.performDownloads(DefaultArtifactResolver.java:499) > at > org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:400) > ... 31 more > h3. Workaround > Pass -Daether.connector.resumeDownloads=false > > Issue is still present in 1.5.0 -- This message was sent by Atlassian Jira (v8.3.4#803005)
