I really don't know what is going on here, but please, please, please :) don't undo the tidy-up with the maven profiles. That was a serious win because it was not tidy before. I actually remember suggesting something like the cleanup in the past to Alex and he suggested that I look into it (with some warnings), but I never got to it, so I was really pleased to see when Chris did. I think this counts as something that is more logical/accessible (in terms of understanding) to anyone new who might want to get involved with Royale. There must be a way to keep that and also address whatever needs there are for release steps (I hope).
On Fri, May 1, 2020 at 8:04 PM Alex Harui <[email protected]> wrote: > Hi Chris, > > If what you say about "activeByDefault" is true, I don't understand why I > had to specify "-main" in the profiles in the releasesteps in order to get > this to work in the past. If we restore the "main" profile that is > activebydefault, I don't understand why the other profiles couldn't > activate the "main" profile. > > My concern is that specifying no modules as we used to is not quite the > same as specifying a single project called royale-framework-parent which > isn't clear to me that it is a module or project, and there will be > difference that we have to spend time looking for. > > My 2 cents, > -Alex > > I have to stop work for tonight, so will see where we are in my morning. > > On 5/1/20, 12:56 AM, "Christofer Dutz" <[email protected]> wrote: > > 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" <[email protected]>: > > 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:[email protected]> > Sent: Friday, May 1, 2020 10:01 AM > To: [email protected]<mailto:[email protected]> > 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 <[email protected]> > Gesendet: Freitag, 1. Mai 2020 08:29 > An: [email protected] <[email protected]> > 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" <[email protected]> > 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%7Cc5b527930a4c406e79f708d7eda51ec4%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637239165756301163&sdata=q%2BPQ9%2Bf9WvVSL3e0x%2FGr3ao7wMVgbJgdrNkxuWQXAdM%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" <[email protected]> > 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" < > [email protected]> 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" < > [email protected]>: > > 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:[email protected]> > Sent: Friday, May 1, 2020 12:32 AM > To: [email protected]<mailto: > [email protected]> > 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" < > [email protected]> 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: > [email protected]> > Sent: Thursday, April 30, 2020 10:49 PM > To: [email protected]<mailto: > [email protected]> > 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%7Cc5b527930a4c406e79f708d7eda51ec4%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637239165756301163&sdata=AH%2FiNcm%2F6uSUsgWfNwRMqRxhnecMt3OfyOvPY4UlpYU%3D&reserved=0 > > On 4/30/20, 12:41 PM, "Christofer Dutz" < > [email protected]> 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" > <[email protected]>: > > 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" < > [email protected]> 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: > [email protected]> > Sent: Thursday, April 30, 2020 > 9:32 PM > To: [email protected]<mailto: > [email protected]> > 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%7Cc5b527930a4c406e79f708d7eda51ec4%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637239165756301163&sdata=4QXwlQfxtrs1qrvnkdnDJ9z7oyAc2ENxbn%2BkqK4uVwg%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 > > > > > > > > > > > > > > > > > > >
