Strange. I tried it a few days ago and it worked for me. We shouldn't need a settings-security.xml file. Are you sure that wagon was launched with the -Drm.username and -Drm.password parameters set to something valid?
I thought you had problems with typedefs as well. You can apply a filter to filter out the really long paths in Jewel Themes. I'm pretty sure I was successful using Windows, but it could have been before the Jewel themes. -Alex On 4/29/20, 8:00 PM, "Yishay Weiss" <[email protected]> wrote: It occurred to me it might be a long paths issue. Something doesn’t add up because I was able to use wagon to upload the compiler artifacts and typedefs. A test for that would be to see if step 11 upload works on CI. I just tried and it fails [1]. I’ll have more time in approximately 10 hours. [1] java.io.FileNotFoundException: C:\Users\ApacheRoyaleCI\.m2\settings-security.xml (The system cannot find the file specified) From: Alex Harui<mailto:[email protected]> Sent: Wednesday, April 29, 2020 11:58 PM To: [email protected]<mailto:[email protected]> Subject: Re: Optimize wagon:upload Yes, we are having problems again with the upload from Windows to staging. My hope was that by running Wagon by itself we'd get the chance to continue from the point of failure with "mvn -rf" but that appears to not be the case. The second hope was that reducing the number of files to be uploaded by having the RM only upload the asc files would help, but that is apparently also not the case. If you want to make one more test, you can try uploading the bits to SVN. Copy the local-release-dir into the SVN for, say, dist.a.o/dev/royale and see If you can add and commit it. The CI Server could pull from there and upload to staging if we find that CI server has a more reliable connection. It is unfortunate that this problem has been difficult to fix, but once we find a way to do it, then it should be easier for future RMs. Thanks for sticking with it, -Alex On 4/29/20, 1:22 PM, "Yishay Weiss" <[email protected]> wrote: wagon:upload is practically unusable to me as it stands, so even limiting the uplpad to .asc files does not work from my computer. If we wanted to work around that we would need to take the second approach you suggested, which is to upload the .asc files to the CI server somehow. I might spend some time tomorrow to see if Chris’s untested PR helps. Either way, this requires some work. From: Alex Harui<mailto:[email protected]> Sent: Wednesday, April 29, 2020 9:01 PM To: [email protected]<mailto:[email protected]> Subject: Re: Optimize wagon:upload I'd be surprised if Git fails as well, although Git does some fancy encoding so may not be pushing as many separate files. DropBox might be a better test where you drop 500+ .asc files into a DropBox folder and see if it fails as it uploads them. And that's why I'm suggesting that effort be spend on a workaround where the CI server pushes the bits, but it is up to you how you spend your time. We can certainly teach the CI server to download .asc files from some GitHub URL. The big question that hasn't been tested yet is whether the CI server would have the same failure issues uploading the big bits to staging. If you have time, that's what I recommend that you do next. If we find that the CI server is reliable pushing bits to staging then that is our workaround. If it has the same issues, then the workaround may be to push the bits to GH and have someone with more reliable internet push to staging. -Alex On 4/29/20, 10:36 AM, "Yishay Weiss" <[email protected]> wrote: It ‘hangs’, no message. I can do the Git test, but I’d be really surprised if that failed. From: Alex Harui<mailto:[email protected]> Sent: Wednesday, April 29, 2020 8:10 PM To: [email protected]<mailto:[email protected]> Subject: Re: Optimize wagon:upload So to me, a good test would be to copy all of the .asc files to the internet somewhere else. Push them all to a git repo, or to dropbox or some other cloud storage via a git command or a script. Because if that works for you, it really points the finger at some aspect of Windows networking not communicating well with the staging server. Also, is it really "hanging" as in you have to kill maven or does it just fail at some point? And if it fails does it give you the option to continue where it failed? -Alex On 4/29/20, 10:05 AM, "Yishay Weiss" <[email protected]> wrote: I put the flag there just as a test. If it does what the documentation says it should it should be helpful for bigger bulks, but I haven’t gotten it to work. Yes, the total of .asc files is I think less than an mb, and yet even this hangs for me. From: Alex Harui<mailto:[email protected]> Sent: Wednesday, April 29, 2020 6:58 PM To: [email protected]<mailto:[email protected]> Subject: Re: Optimize wagon:upload Try turning off the optimize flag in the ant script where it calls Maven. If you are just uploading individual .asc files it is far less data than pushing all of the binary bits. -Alex On 4/29/20, 7:18 AM, "Yishay Weiss" <[email protected]> wrote: Has anyone got this [1] to work? Didn’t for me. I got [exec] [ERROR] Failed to execute goal org.codehaus.mojo:wagon-maven-plugin:2.0.0:upload (default-cli) on project royale-framework-parent: Error handling resource : Wagon https does not support optimize upload -> [Help 1] [exec] org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.codehaus.mojo:wagon-maven-plugin:2.0.0:upload (default-cli) on project [1] https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.mojohaus.org%2Fwagon-maven-plugin%2Fupload-mojo.html%23optimize&data=02%7C01%7Caharui%40adobe.com%7Ca14962fa9b7f4c9b9cde08d7ecb29d3d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637238124302336004&sdata=QmVQZ2SpWid69pyKUGZXmw3ijpGCzpHP1GdfChXuqHA%3D&reserved=0
