> is not yet set up (onboarded)
Yeah. That can be the case. I don't perform this step. Let me file an INFRA
ticket now - maybe they just show me a self-service link, I don't know, lol.
Best,
tison.
Tamás Cservenák 于2023年5月24日周三 14:12写道：
> Also,
>
> As I see, the incubator opendal project is n
Thank you!
Then it may not be my config issue. I'll ask the INFRA team and retry later.
Since the URL can be opened from the browser, I was wondering if there is
something wrong from my side :P
Best,
tison.
Tamás Cservenák 于2023年5月24日周三 14:04写道：
> Howdy,
>
> The Maven deploy failure happened
Also,
As I see, the incubator opendal project is not yet set up (onboarded) on
repository.apache.org (may be wrong, though).
So best bet is to ask #infra on Slack or create infra issue
https://issues.apache.org/jira/projects/INFRA/issues
Thanks
T
On Wed, May 24, 2023 at 8:03 AM Tamás Cservenák
Howdy,
The Maven deploy failure happened as the remote end (ASF Nexus) responded
with HTTP 500 "Server error".
Please ask infra what happened (was there some known issue to service) or
alike.
Maven cannot do anything in these cases, this is out of it's reach, and as
the server said "I have a bad
Hi,
https://github.com/apache/incubator-opendal/pull/2301 Here is the branch
I'm testing for deploying a snapshot Maven artifact with apache parent pom
for an incubating project.
When I run it locally by `mvn -X -P apache-release clean deploy`, it fails
in the uploading step with log[1].
It seem
Hi Tamás,
> So IMHO there is NO (and I see no) difference between 1 or more checksum
> algorithm used, unless you have some more information or some conditions you
> did not mention...
This is a latency sensitive bug. Lots of irrelevant things affected how the
problem appeared for different re
Jacob,
in this stack it is not checksum transport that failed but maven metadata
(maven-metadata.xml upload), while the server error is same as before
(org.apache.http.NoHttpResponseException: ...:443 failed to respond). So
IMHO there is NO (and I see no) difference between 1 or more checksum
algo
Hi Michael,
It is a little tricky for us to reproduce right at the moment but I can try and
reconstruct the problematic set up if you have a snapshot you would like me to
try.
-Original Message-
From: Michael Osipov
Sent: Tuesday, May 23, 2023 5:05 AM
To: dev@maven.apache.org
Subject:
Hi Tamás,
Thank you for opening the JIRA ticket and PR. Here is a lightly edited logs
from a build that got BUILD FAILURE
```
[INFO] Error stacktraces are turned on.
[INFO] Scanning for projects...
[WARNING]
[WARNING] Some problems were encountered while building the effective model for
...:tas
Created https://issues.apache.org/jira/browse/MRESOLVER-361 to track the
issue.
On Fri, May 19, 2023 at 11:27 PM Finkelman, Jacob
wrote:
> During a maven publish if the server closes the TCP connection after the
> upload of an asset sometimes the publish will fail with a failed to respond
> whil
Jacob,
Could you show a stack how build fails when there is only 1 checksum in
play? (the -Daether.checksums.algorithms=MD5 case).
Thanks
T
On Fri, May 19, 2023 at 11:27 PM Finkelman, Jacob
wrote:
> During a maven publish if the server closes the TCP connection after the
> upload of an asset
Hi,
some time ago I had the problem described in
https://issues.apache.org/jira/browse/MDEPLOY-118: The company I was working
wants to build multiple native artifacts of the same software on different
machines and deploy them. Since additional platforms / build hosts may be added
later as nee
On 2023/05/22 16:29:05 "Finkelman, Jacob" wrote:
> Would changing that type signature automatically add retries for the
> checksums when using the wagon transport? If not, what else would need to be
> done to add retries? Would that help with the native transport at all?
Yes, fixing the closed i
13 matches
Mail list logo
