Got my fingers crossed. I don’t know if you took note that I reviewed the staging repos and none of them are complete. I just saw a note that a new staging repo will get created if the last one saw a failure so maybe that’s why we have so many. So you may need to upload royale-compiler and royale-typedefs again (and add that -N switch). And drop all of the old repos if you don’t think you’ll need them anymore.
Are you just trying to upload .asc files or the whole thing? -Alex From: Yishay Weiss <[email protected]> Reply-To: "[email protected]" <[email protected]> Date: Friday, May 1, 2020 at 9:15 AM To: "[email protected]" <[email protected]> Subject: RE: wagon:upload problems That seems to be working. I’m seeing [exec] [INFO] Building Apache Royale: Framework: Parent 0.9.7 Instead of something like Building Apache Royale: Framework: Themes: Jewel-Light-NoFlat-Secondary-Violet-Theme 0.9.7 [66/157] Where the [n/157] implies it’s running in a loop. I’ll report back when it’s finished. Thanks. From: Alex Harui <[email protected]> Sent: Friday, May 1, 2020 7:07:21 PM To: [email protected] <[email protected]> Subject: Re: wagon:upload problems Bummer. I was afraid that the project list would only be modules and parent would have special treatment. I just saw this on maven.a.o (https://maven.apache.org/ref/3.1.0/maven-embedder/cli.html<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmaven.apache.org%2Fref%2F3.1.0%2Fmaven-embedder%2Fcli.html&data=02%7C01%7Caharui%40adobe.com%7Ca137c301932646fa821708d7edeace96%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637239465080274038&sdata=OLLrPcSGKGlWXeUljhlY1qtGg831VIdTeMe4iQomKAE%3D&reserved=0>) -N,--non-recursive Do not recurse into sub-projects You might give that a shot if you have time. Good luck, -Alex On 5/1/20, 8:57 AM, "Yishay Weiss" <[email protected]> wrote: This is what I’m getting when adding <arg value="-pl"/> <arg value="royale-framework-parent"/> [exec] [DEBUG] Looking up lifecycle mappings for packaging maven-archetype from ClassRealm[project>org.apache.royale.framework:royale-simple-typedef-archet ype:0.9.7, parent: ClassRealm[maven.api, parent: null]] [exec] [ERROR] [ERROR] Could not find the selected project in the reactor: royale-framework-parent @ [exec] [ERROR] Could not find the selected project in the reactor: royale-framework-parent -> [Help 1] [exec] org.apache.maven.MavenExecutionException: Could not find the selected project in the reactor: royale-framework-parent From: Alex Harui<mailto:[email protected]> Sent: Friday, May 1, 2020 6:50 PM To: [email protected]<mailto:[email protected]> Subject: Re: wagon:upload problems I would like to stick to technical reality and facts instead of theory and assumptions. 1) Right below the section quoted from https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmaven.apache.org%2Fguides%2Fintroduction%2Fintroduction-to-profiles.html&data=02%7C01%7Caharui%40adobe.com%7C53d5691ffa3a4194752008d7ede857ef%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637239454480967693&sdata=EE%2B0lTJiBwTYyYT4Jfou7J5Q8QtgJbpilH5EP%2Fru1EM%3D&reserved=0<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmaven.apache.org%2Fguides%2Fintroduction%2Fintroduction-to-profiles.html&data=02%7C01%7Caharui%40adobe.com%7Ca137c301932646fa821708d7edeace96%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637239465080274038&sdata=hfOm7FcxBpKwlkrfQs0T7c1nTVTbp99QCzXPJLJNodw%3D&reserved=0> is official maven documentation (and not StackOverflow), it says: " Deactivating a profile Starting with Maven 2.0.10, one or more profiles can be deactivated using the command line by prefixing their identifier with either the character '!' or '-' as shown below: mvn groupId:artifactId:goal -P !profile-1,!profile-2 This can be used to deactivate profiles marked as activeByDefault or profiles that would otherwise be activated through their activation config." I hadn't noticed until now that it sort of conflicts with the part Chris quoted. 2) Technically speaking, how will adding one activebydefault profile undo all of the other profile changes? Isn't adding the main profile to the 5 or 6 other profiles that need it equivalent 3) We are only trying to use Maven in the same way that Chris said he is using for one of his other project's snapshot release which is to deploy to a local directory and use Wagon. Again, technically speaking, what is the difference between that other project's use of modules vs Royale's? Or maybe Wagon does upload everything once for each module but smaller projects don't notice. Or is that project also specifying the parent project when they use Wagon? 4) We are also trying to solve a "reality" vs "theory" problem. Maven Wagon should "just work" but we've seen problems with Windows machines in the past as well as now. The evidence indicates that when Piotr did the release we weren't uploading everything multiple times yet Piotr was still having issues on Windows. We learned yesterday that the CI Windows server uploaded for 5.5 hours until it finally failed while I think Yishay usually experiences a failure in 30 minutes. So we are trying to find a workaround for crappy connections on Windows. So there are lots of unanswered questions. I think they are: A) is there a difference between specifying no modules in a profile vs specifying the parent as the only project B) Under what conditions does Nexus generate a new staging folder? C) Is there a difference between the having modules in the top-level of the pom vs in an activebydefault profile that is activated by the other profiles that need it. IMO, it is up to Yishay on how he spends his time on this and we should all be grateful for his patience and effort. IMO, the next thing to try may be specifying the “-pl royale-framework-parent" so we can at least see what it does. My 2 cents, -Alex On 5/1/20, 4:20 AM, "Yishay Weiss" <[email protected]> wrote: This has nothing to do with Ant. I have not run a single Ant build since I began this release. We are discussing a change in configuration which apparently has made the way we have been using Maven to stage our artifacts malfunction. This took me days to debug, and I don’t want the next RM to be in the same situation. I’ve broken things, and cost people time in the past. That happens to everyone. But let’s please take responsibility, and do out best so that it doesn’t happen again. Thanks. From: Carlos Rovira<mailto:[email protected]> Sent: Friday, May 1, 2020 12:01 PM To: Apache Royale Development<mailto:[email protected]> Subject: Re: wagon:upload problems Hi, please don't undo the things be already fixed in Maven. That will mean for me an ANT first - Maven second movement, and that should not be the case as we always discussed here. Both build tools are equally important, and lots of improvements where done so going back is not a good way to go. Remember we are having current problems since we are stepping out to the standard release process the rest of projects have. So we shouldn't do more things that are not supported or standard since that will mean more time invenstead and the release not done. My concern it that we should keep things simple for the new contributors and for the normal workflow, even if this makes things more complicated for one execution during a release which is currently done once a year. Ok you are planning on speeding things up a little, but even if it's one execution per month, this should not have a negative effect on every build done multiple times a day by multiple people. Can you first try what Chris exposed? He already earned the credit in build system that nobody here have. So if he suggest to do something, based on credits, I think we should try it, since until now all his contributions made us to go one step closer to solve this problem. Thanks El vie., 1 may. 2020 a las 10:27, Christofer Dutz (< [email protected]>) escribió: > Hi Alex ... > > So let me copy this from the official maven documentation found here: > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmaven.apache.org%2Fguides%2Fintroduction%2Fintroduction-to-profiles.html&data=02%7C01%7Caharui%40adobe.com%7C53d5691ffa3a4194752008d7ede857ef%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637239454480967693&sdata=EE%2B0lTJiBwTYyYT4Jfou7J5Q8QtgJbpilH5EP%2Fru1EM%3D&reserved=0<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmaven.apache.org%2Fguides%2Fintroduction%2Fintroduction-to-profiles.html&data=02%7C01%7Caharui%40adobe.com%7Ca137c301932646fa821708d7edeace96%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637239465080284027&sdata=VWhbLCKwmv4aR4RlEYIdyvxhX4nqtabK%2Fi6IwnVb6FI%3D&reserved=0> > "Profiles can also be active by default using a configuration like the > following: > > <profiles> > <profile> > <id>profile-1</id> > <activation> > <activeByDefault>true</activeByDefault> > </activation> > ... > </profile> > </profiles> > This profile will automatically be active for all builds unless another > profile in the same POM is activated using one of the previously described > methods. All profiles that are active by default are automatically > deactivated when a profile in the POM is activated on the command line or > through its activation config." > > I have no Idea why you needed to disable the profile, but I have to admit > in the old state the hierarchies of profiles was a nightmare. > > My concern it that we should keep things simple for the new contributors > and for the normal workflow, even if this makes things more complicated for > one execution during a release which is currently done once a year. Ok you > are planning on speeding things up a little, but even if it's one execution > per month, this should not have a negative effect on every build done > multiple times a day by multiple people. > > Stackoverflow is not a good tutor ... you usually get one answer that > might address the one problem you were having but that usually doesn't know > about the other constraints. Also you really don't get good explanations > most of the time so you don't even know what you're doing and what the > implications are. I would consider myself a Maven expert with really a lot > of experience with different situations. So please trust my before > copy-pasting some half-baked "solution" from stack overflow. > > I will do my best to help you folks help you adjust the ant scripts as > much as possible. > > > Chris > > > > Am 01.05.20, 10:04 schrieb "Alex Harui" <[email protected]>: > > 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%7C53d5691ffa3a4194752008d7ede857ef%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637239454480967693&sdata=CjQhouHxzME08sye%2FrUMt%2Bb4cXXPHfg0xWlV19JES9g%3D&reserved=0<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%7Ca137c301932646fa821708d7edeace96%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637239465080284027&sdata=%2BdwjhcJ5vaMLJoyukvIvucAaykMAhXKdATmP2OQSlFA%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%7C53d5691ffa3a4194752008d7ede857ef%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637239454480967693&sdata=bt2zuUbE4v2VYsJ0TfKZbe3JYuruv4s0wGSqFnGwjEM%3D&reserved=0<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpaste.apache.org%2Ftpdkh&data=02%7C01%7Caharui%40adobe.com%7Ca137c301932646fa821708d7edeace96%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637239465080294025&sdata=RKd7lofoykrd2nfTwmX0LzsAn5RjlNqaIC10l9M9%2BcE%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%7C53d5691ffa3a4194752008d7ede857ef%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637239454480977693&sdata=rk7SOIFABUy7AN9OXn8ZpFnluouTVxRyQMQEQr%2ByYic%3D&reserved=0<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpaste.apache.org%2Fzh3rj&data=02%7C01%7Caharui%40adobe.com%7Ca137c301932646fa821708d7edeace96%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637239465080294025&sdata=SuXWER8S1z5ZbsI1KUqdAhY7KQC8pwMfjMaS68Nyffw%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 > > > > > > > > > > > > > > > > > > > > -- Carlos Rovira https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C53d5691ffa3a4194752008d7ede857ef%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637239454480977693&sdata=oZJCU4oNefN7eFQPnY7Sdn96DIkPScI2e%2Bg%2Bmh%2FPinQ%3D&reserved=0<https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Ca137c301932646fa821708d7edeace96%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637239465080304021&sdata=YLVvY40OZtf0vR5L9mFLcLuMpso5DoOa%2BhEG0K8thfw%3D&reserved=0> From: Alex Harui<mailto:[email protected]> Sent: Friday, May 1, 2020 7:07 PM Subject: Re: wagon:upload problems Bummer. I was afraid that the project list would only be modules and parent would have special treatment. I just saw this on maven.a.o (https://maven.apache.org/ref/3.1.0/maven-embedder/cli.html<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmaven.apache.org%2Fref%2F3.1.0%2Fmaven-embedder%2Fcli.html&data=02%7C01%7Caharui%40adobe.com%7Ca137c301932646fa821708d7edeace96%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637239465080304021&sdata=WIj0JEzl6lqMiWepg%2BsZw0QBhNWsAsOkq5D%2F2LLR17M%3D&reserved=0>) -N,--non-recursive Do not recurse into sub-projects You might give that a shot if you have time. Good luck, -Alex On 5/1/20, 8:57 AM, "Yishay Weiss" <[email protected]> wrote: This is what I’m getting when adding <arg value="-pl"/> <arg value="royale-framework-parent"/> [exec] [DEBUG] Looking up lifecycle mappings for packaging maven-archetype from ClassRealm[project>org.apache.royale.framework:royale-simple-typedef-archet ype:0.9.7, parent: ClassRealm[maven.api, parent: null]] [exec] [ERROR] [ERROR] Could not find the selected project in the reactor: royale-framework-parent @ [exec] [ERROR] Could not find the selected project in the reactor: royale-framework-parent -> [Help 1] [exec] org.apache.maven.MavenExecutionException: Could not find the selected project in the reactor: royale-framework-parent From: Alex Harui<mailto:[email protected]> Sent: Friday, May 1, 2020 6:50 PM To: [email protected]<mailto:[email protected]> Subject: Re: wagon:upload problems I would like to stick to technical reality and facts instead of theory and assumptions. 1) Right below the section quoted from https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmaven.apache.org%2Fguides%2Fintroduction%2Fintroduction-to-profiles.html&data=02%7C01%7Caharui%40adobe.com%7C53d5691ffa3a4194752008d7ede857ef%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637239454480967693&sdata=EE%2B0lTJiBwTYyYT4Jfou7J5Q8QtgJbpilH5EP%2Fru1EM%3D&reserved=0<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmaven.apache.org%2Fguides%2Fintroduction%2Fintroduction-to-profiles.html&data=02%7C01%7Caharui%40adobe.com%7Ca137c301932646fa821708d7edeace96%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637239465080314015&sdata=mFrWEvHnwkIu5DJ0qlhyhHWu57kSeptCx07OrlM3nho%3D&reserved=0> is official maven documentation (and not StackOverflow), it says: " Deactivating a profile Starting with Maven 2.0.10, one or more profiles can be deactivated using the command line by prefixing their identifier with either the character '!' or '-' as shown below: mvn groupId:artifactId:goal -P !profile-1,!profile-2 This can be used to deactivate profiles marked as activeByDefault or profiles that would otherwise be activated through their activation config." I hadn't noticed until now that it sort of conflicts with the part Chris quoted. 2) Technically speaking, how will adding one activebydefault profile undo all of the other profile changes? Isn't adding the main profile to the 5 or 6 other profiles that need it equivalent 3) We are only trying to use Maven in the same way that Chris said he is using for one of his other project's snapshot release which is to deploy to a local directory and use Wagon. Again, technically speaking, what is the difference between that other project's use of modules vs Royale's? Or maybe Wagon does upload everything once for each module but smaller projects don't notice. Or is that project also specifying the parent project when they use Wagon? 4) We are also trying to solve a "reality" vs "theory" problem. Maven Wagon should "just work" but we've seen problems with Windows machines in the past as well as now. The evidence indicates that when Piotr did the release we weren't uploading everything multiple times yet Piotr was still having issues on Windows. We learned yesterday that the CI Windows server uploaded for 5.5 hours until it finally failed while I think Yishay usually experiences a failure in 30 minutes. So we are trying to find a workaround for crappy connections on Windows. So there are lots of unanswered questions. I think they are: A) is there a difference between specifying no modules in a profile vs specifying the parent as the only project B) Under what conditions does Nexus generate a new staging folder? C) Is there a difference between the having modules in the top-level of the pom vs in an activebydefault profile that is activated by the other profiles that need it. IMO, it is up to Yishay on how he spends his time on this and we should all be grateful for his patience and effort. IMO, the next thing to try may be specifying the “-pl royale-framework-parent" so we can at least see what it does. My 2 cents, -Alex On 5/1/20, 4:20 AM, "Yishay Weiss" <[email protected]> wrote: This has nothing to do with Ant. I have not run a single Ant build since I began this release. We are discussing a change in configuration which apparently has made the way we have been using Maven to stage our artifacts malfunction. This took me days to debug, and I don’t want the next RM to be in the same situation. I’ve broken things, and cost people time in the past. That happens to everyone. But let’s please take responsibility, and do out best so that it doesn’t happen again. Thanks. From: Carlos Rovira<mailto:[email protected]> Sent: Friday, May 1, 2020 12:01 PM To: Apache Royale Development<mailto:[email protected]> Subject: Re: wagon:upload problems Hi, please don't undo the things be already fixed in Maven. That will mean for me an ANT first - Maven second movement, and that should not be the case as we always discussed here. Both build tools are equally important, and lots of improvements where done so going back is not a good way to go. Remember we are having current problems since we are stepping out to the standard release process the rest of projects have. So we shouldn't do more things that are not supported or standard since that will mean more time invenstead and the release not done. My concern it that we should keep things simple for the new contributors and for the normal workflow, even if this makes things more complicated for one execution during a release which is currently done once a year. Ok you are planning on speeding things up a little, but even if it's one execution per month, this should not have a negative effect on every build done multiple times a day by multiple people. Can you first try what Chris exposed? He already earned the credit in build system that nobody here have. So if he suggest to do something, based on credits, I think we should try it, since until now all his contributions made us to go one step closer to solve this problem. Thanks El vie., 1 may. 2020 a las 10:27, Christofer Dutz (< [email protected]>) escribió: > Hi Alex ... > > So let me copy this from the official maven documentation found here: > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmaven.apache.org%2Fguides%2Fintroduction%2Fintroduction-to-profiles.html&data=02%7C01%7Caharui%40adobe.com%7C53d5691ffa3a4194752008d7ede857ef%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637239454480967693&sdata=EE%2B0lTJiBwTYyYT4Jfou7J5Q8QtgJbpilH5EP%2Fru1EM%3D&reserved=0<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmaven.apache.org%2Fguides%2Fintroduction%2Fintroduction-to-profiles.html&data=02%7C01%7Caharui%40adobe.com%7Ca137c301932646fa821708d7edeace96%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637239465080314015&sdata=mFrWEvHnwkIu5DJ0qlhyhHWu57kSeptCx07OrlM3nho%3D&reserved=0> > "Profiles can also be active by default using a configuration like the > following: > > <profiles> > <profile> > <id>profile-1</id> > <activation> > <activeByDefault>true</activeByDefault> > </activation> > ... > </profile> > </profiles> > This profile will automatically be active for all builds unless another > profile in the same POM is activated using one of the previously described > methods. All profiles that are active by default are automatically > deactivated when a profile in the POM is activated on the command line or > through its activation config." > > I have no Idea why you needed to disable the profile, but I have to admit > in the old state the hierarchies of profiles was a nightmare. > > My concern it that we should keep things simple for the new contributors > and for the normal workflow, even if this makes things more complicated for > one execution during a release which is currently done once a year. Ok you > are planning on speeding things up a little, but even if it's one execution > per month, this should not have a negative effect on every build done > multiple times a day by multiple people. > > Stackoverflow is not a good tutor ... you usually get one answer that > might address the one problem you were having but that usually doesn't know > about the other constraints. Also you really don't get good explanations > most of the time so you don't even know what you're doing and what the > implications are. I would consider myself a Maven expert with really a lot > of experience with different situations. So please trust my before > copy-pasting some half-baked "solution" from stack overflow. > > I will do my best to help you folks help you adjust the ant scripts as > much as possible. > > > Chris > > > > Am 01.05.20, 10:04 schrieb "Alex Harui" <[email protected]>: > > 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%7C53d5691ffa3a4194752008d7ede857ef%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637239454480967693&sdata=CjQhouHxzME08sye%2FrUMt%2Bb4cXXPHfg0xWlV19JES9g%3D&reserved=0<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%7Ca137c301932646fa821708d7edeace96%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637239465080324004&sdata=V2ANkFg%2BkMbiYDSqKtLic%2FA89V7AuTGFOKo%2Ftf4R%2B3w%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%7C53d5691ffa3a4194752008d7ede857ef%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637239454480967693&sdata=bt2zuUbE4v2VYsJ0TfKZbe3JYuruv4s0wGSqFnGwjEM%3D&reserved=0<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpaste.apache.org%2Ftpdkh&data=02%7C01%7Caharui%40adobe.com%7Ca137c301932646fa821708d7edeace96%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637239465080324004&sdata=4AAvTBkKiDXnq%2BeynjmB4AgnjQGmlA%2BZ0QB7UpcoU1g%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%7C53d5691ffa3a4194752008d7ede857ef%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637239454480977693&sdata=rk7SOIFABUy7AN9OXn8ZpFnluouTVxRyQMQEQr%2ByYic%3D&reserved=0<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpaste.apache.org%2Fzh3rj&data=02%7C01%7Caharui%40adobe.com%7Ca137c301932646fa821708d7edeace96%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637239465080333998&sdata=rrCKyEqeryMELrE7sqhcLLsfEB6nQGnQ6KaUenk9NcE%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 > > > > > > > > > > > > > > > > > > > > -- Carlos Rovira https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C53d5691ffa3a4194752008d7ede857ef%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637239454480977693&sdata=oZJCU4oNefN7eFQPnY7Sdn96DIkPScI2e%2Bg%2Bmh%2FPinQ%3D&reserved=0<https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Ca137c301932646fa821708d7edeace96%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637239465080333998&sdata=sUC41CvEKkX6BT0xwHp%2BnAHeAC5B9C%2BMYaXBMtGsxkU%3D&reserved=0>
