Hi Yishay,
relying on "activeByDefault" is bad. Cause as soon as you just select one
single other profile, the activeByDefault profile gets disabled.
So if you have a profile "buildMainModules" and that's active by default, and
(as the name says) adds the main modules and you now want to have them also
build the SWF parts, you enable "witt-swf" profile and nothing is built at all
... now you manually need to enable the buildMainModules profile too to
continue. That's just bad style.
So if the maven folks have to live with this inconvenience just because in case
of an Ant scripted release you didn't want to just add “-pl
royale-framework-parent" or even "-pl ." (which should do the same) ... then I
can't help you folks.
Chris
Am 01.05.20, 09:26 schrieb "Yishay Weiss" <yishayj...@hotmail.com>:
Hi Chris,
Can you explain why the cleanup was necessary? If Alex is right, and as a
result of this cleanup is that an Ant tasks in releasesteps.xml is no longer
working as expected, then someone needs to spend time to make sure the rest of
the tasks are.
It could be that the best way ends up keeping your changes and adding “-pl
royale-framework-parent” to the wagon call, but I’d like to make sure this
refactor is actually necessary. Frankly, I don’t think it should have been
merged in without testing the release steps.
Thanks,
Yishay
From: Christofer Dutz<mailto:christofer.d...@c-ware.de>
Sent: Friday, May 1, 2020 10:01 AM
To: dev@royale.apache.org<mailto:dev@royale.apache.org>
Subject: Re: wagon:upload problems
I Alex,
If you do that you're undoing all the cleanup I had been doing. Please
don't do that.
I sent you what's needed to make it run in only one module, so could you
please just use that?
I also said there were two things wrong. Uploading it for every module was
one and the included pattern being wrong s the second. If you fix both, you
should be set.
Chris
________________________________
Von: Alex Harui <aha...@adobe.com.INVALID>
Gesendet: Freitag, 1. Mai 2020 08:29
An: dev@royale.apache.org <dev@royale.apache.org>
Betreff: Re: wagon:upload problems
Could be that the answer is in this commit:
9e410b29b5f11c832a0005a7feb6d85d6419d3ac
The way it was setup before was that all <modules> were specified in
profiles. If you look at the Upload task from that commit, it turns off the
main profile and enables the upload profile thus keeping wagon from rummaging
through the modules. I think if we set it up that way again, it will work
better.
HTH,
-Alex
On 4/30/20, 10:55 PM, "Alex Harui" <aha...@adobe.com.INVALID> wrote:
Looking through the history, it looks like we've been trying to get
Maven to not have Wagon run on the modules. Here's a post that implies that
the way we specified the modules in the profile should have kept the submodules
from running:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstackoverflow.com%2Fquestions%2F10682186%2Fin-maven-can-a-profile-override-the-modules-to-not-include-any&data=02%7C01%7Caharui%40adobe.com%7Cdc910752a8ea4cd571d608d7ed9446ca%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637239093412064925&sdata=U11mif2CXNYO0oEdjfYfTJ3FI1LD0yULS90KBS2p0wQ%3D&reserved=0
It is interesting that the mechanism in that post seems to no longer be
working. But it is definitely the goal to not have the submodules in the run.
HTH,
-Alex
On 4/30/20, 2:51 PM, "Alex Harui" <aha...@adobe.com.INVALID> wrote:
Yes, Yishay should try that the "-pl royale-framework-parent" but
will it then search for artifacts generated by the submodules? I got concerned
when you said there would only be one .asc file. There should be one per .swc.
Don't know if it is related, but I went to the staging server and
found that there were several staging repos open. I thought it wouldn't open a
new one until the previous one was closed. None of the staging repos are
complete. Some contain only compiler and typedefs. Others the framework but
with examples and manualtests as sibling to framework. In the past all 3 of
compiler, typedefs, and framework end up in the staging repo. Thus, we need to
understand how staging repos work. Does it open a staging repo per IP?
Thanks
-Alex
On 4/30/20, 2:43 PM, "Christofer Dutz" <christofer.d...@c-ware.de>
wrote:
Hi folks,
are you actually reading what I wrote? I thought I had
explained why it's running so often?
You can see that it's executing the upload thing for every
maven module in the project (You can see the titles of the projects changing)
Please just try and add the "-pl royale-framework-parent" to
the command line and it should only run for the main module.
And if you adjust the "include" pattern back to "**/*.asc" then
it should deploy all asc files.
I would also expect this to be the root cause of the general
deployment problems ...
I could imagine if you deploy every artifact 160 times that
Nexus might kick you.
Chris
Am 30.04.20, 23:37 schrieb "Yishay Weiss"
<yishayj...@hotmail.com>:
I’m out of time for the next 16 hours or so. BTW, the
artifacts were probably uploaded days ago. So in theory we could continue with
the release and figure this out at some other time.
Thanks.
From: Alex Harui<mailto:aha...@adobe.com.INVALID>
Sent: Friday, May 1, 2020 12:32 AM
To: dev@royale.apache.org<mailto:dev@royale.apache.org>
Subject: Re: wagon:upload problems
I hope to have time to think about this more later (about 7
hours). I think we want to run Wagon in a way that from the main pom, it will
know about all of the artifacts to upload from all of the SWCs, etc.
I think that's what the reactor does (look through the
poms) but it seems to want to upload the parent source-release every time. So
maybe try the param Chris suggested so it only tries framework-parent, but then
it might miss the other artifacts.
BTW, do you have a log of the typedefs upload to see if it
did the same thing?
-Alex
On 4/30/20, 2:26 PM, "Yishay Weiss"
<yishayj...@hotmail.com> wrote:
> My hunch is that specifying <includes> causes this
loop.
That wasn’t it. It completed one run and went on to the
next run. I now realize that instead of waiting for it to finish and seeing
whether or not it’ll run again I can just look at this line, which happens in
the beginning
Building Apache Royale: Framework: Themes:
Jewel-Light-NoFlat-Secondary-Violet-Theme 0.9.7 [66/157]
66/157 means it’s gonna run 157 times before it
finished.
From: Alex Harui<mailto:aha...@adobe.com.INVALID>
Sent: Thursday, April 30, 2020 10:49 PM
To: dev@royale.apache.org<mailto:dev@royale.apache.org>
Subject: Re: wagon:upload problems
Hi Chris,
As I understand it, Yishay is only running one Wagon
call. The Jewel calls are not being run, but in that one Wagon call, the
source-release for the parent is being uploaded many times and it doesn't look
like it is trying to upload the artifacts. Check out the log he posted at [1].
How did we give the commands incorrectly that caused it to do what it did?
[1]
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpaste.apache.org%2Ftpdkh&data=02%7C01%7Caharui%40adobe.com%7Cdc910752a8ea4cd571d608d7ed9446ca%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637239093412064925&sdata=xOfm3EHaR6KTKCsHjM9jvAo99JDJIeit6R5ybIABilM%3D&reserved=0
On 4/30/20, 12:41 PM, "Christofer Dutz"
<christofer.d...@c-ware.de> wrote:
Hi folks,
Just to try it out ... almost anyone that has setup
his credentials in the settings.xml could try to deploy asjs by running:
mvn clean deploy
-Papache-release,apache-release,with-distribution,option-with-swf
On the develop branch.
It would automatically build the same artifacts,
sign them and instead of creating a staging repo, would upload them to the
SNAPSHOT repo.
Would be really interesting on if you really are
having these upload problems. And I mean anyone could test this without having
to be RM.
It's just one command, nothing more and you can't
even mess up anything as the code isn't changed.
And by the way ... the releasesteps.xml does
actually deploy a large portion of the artifacts multiple times ...
The ant target uploadSWCs already deploys the
entire artifact tree ... there's no need for uploadJewelDark and
uploadJewelLight
Chris
Am 30.04.20, 20:43 schrieb "Alex Harui"
<aha...@adobe.com.INVALID>:
Gee I hope that didn't cause that IP to be
blocked by Apache. Keep that in mind if you have trouble uploading from the CI
server next time you try. Find the IP address of the CI server and ask Infra
if it got blocked. There is a chance that Azure blocked as well. I guess I'll
find out if I have to pay Azure a huge bandwidth overage bill or not.
It does tell us something about the reliability
of the connection on a windows machine in the US vs your computer outside the
US.
Anyway, I think you can test locally with the
.asc files and figure out the right params.
Good luck,
-Alex
On 4/30/20, 11:34 AM, "Yishay Weiss"
<yishayj...@hotmail.com> wrote:
I suspect this might be related to recent
maven profile changes not meshing well with the release script targets. I’ll
see what I can dig up.
From: Yishay
Weiss<mailto:yishayj...@hotmail.com>
Sent: Thursday, April 30, 2020 9:32 PM
To:
dev@royale.apache.org<mailto:dev@royale.apache.org>
Subject: RE: wagon:upload problems
>I think it might be repeating the upload
for each project.
Upload happens 67 times [1] in a loop. That
explains why even on the CI server after 5.5 hours it finally failed [2].
[1]
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpaste.apache.org%2Fzh3rj&data=02%7C01%7Caharui%40adobe.com%7Cdc910752a8ea4cd571d608d7ed9446ca%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637239093412064925&sdata=Syb2ciB8Gvla6e9StWn8g355cI8Rx8dv3kReCjH%2B4VM%3D&reserved=0
[2]
[exec] [INFO] BUILD FAILURE
[exec] [INFO]
------------------------------------------------------------------------
[exec] [INFO] Total time: 05:36 h
[exec] [INFO] Finished at:
2020-04-30T18:01:58Z
[exec] [INFO]
------------------------------------------------------------------------
[exec] [ERROR] Failed to execute goal
org.codehaus.mojo:wagon-maven-plugin:2.0.0:upload (default-cli) on project
Effects: Error handling resource: Failed to transfer file http
s://repository.apache.org/service/local/staging/deploy/maven2/org/apache/royale/framework/Jewel-Light-NoFlat-Emphasized-Emerald-Theme/0.9.7/Jewel-Light-NoFlat-Emphasized-Emerald-Th
eme-0.9.7-js.swc with status code 400 ->
[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
Effects: Error
handling resource
