Hi, just a point to add about my initial setup. I assume the config for a newbie is based on the wiki, so he has the environment vars setup (is a requerimient for now), but he doesn't have maven repository filled since he never tried to build.
But one thing is clear, all process is very complex and filled with many points that is our main problem to get traction. People coming is unable to enter Royale world unless is perseverant and recover from various failed tries. Hope it would be some way to simplify all this to a minimum. Maybe the only JS option, that will be hopefully what 90% of users would want from use, could a super easy process, simple and with very few internal process that ensures folks can succeed in 99% of cases. In the other hand, if they want SWF stuff, then we have all the complexity with flash player, debugger, and other adobe stuff that is an additional set of things with other requerimients About videos, is ok for me to do both. The objective is to do 2-3 min videos that will make a difference. Ultra short videos with just straight to the core info are proven very useful, so we need something in that way if we want people to join Royale. thanks El vie., 24 may. 2019 a las 4:40, Alex Harui (<[email protected]>) escribió: > Over in Ant, there are some rules (at least for now). I don't remember > exactly, but I think it is: > > Either define all 3 variables (PLAYERGLOBAL_HOME, AIR_HOME, > FLASHPLAYER_DEBUGGER) or don't define any of them. > > Nobody has had the time to make the other combinations work. The > rationale is that either someone took the time to set up the Adobe stuff or > they didn't. And so, when long-time committers like yourself and Carlos > are testing, you may not be testing in a true newbie's configuration as we > wouldn't expect them to have any environment variables set, while you and > Carlos probably have at least some of them set since that used to be the > requirement. > > The same may be true for Maven. I still haven't found time to look, > hoping one of you will eventually understand the logic behind this stuff > and figure it out so I can keep making progress on the release automation. > > In the TestAdapters, IIRC, some of the compiler tests can run without > Adobe artifacts and/or Flash Player Debugger. A SWF is built, then > SWFDump'd (but never launched in a Flash Player) and the dump is compared > against a reference dump. I know AntTestAdapter does this, I don't > remember if MavenTestAdapter does, hence what I wrote about no point in > running tests in JS-Only if there are no SWF artifacts and/or no Adobe > artifacts. > > So, IMO, either define all 3 environment variables for Ant or don't define > any. And for Maven, the same might be true. If you want to spend the time > getting other combinations to work, fine, but IMO the two main scenarios > are 1) You have the Adobe stuff and want SWF artifacts, or 2) You don't > have the Adobe stuff nor any environment variables and don’t want SWF > artifacts. Maybe we don't have to skip tests in those setups. I don't > know. > > HTH, > -Alex > > On 5/23/19, 3:36 PM, "Greg Dove" <[email protected]> wrote: > > 'If our tests require Flash, then there is no point in running them if > there are no SWF artifacts.' > > This is just an info dump, in case the following is useful: > (short version) My failing combination is a) FLASHPLAYER_DEBUGGER is > defined and b) PLAYERGLOBAL_HOME is not defined and/or local m2 does > not > contain playerglobal swc > But this is just with standard maven build, not with profiles or > anything > specified. Also on windows, in case that matters in any way. > > (Details) > I am still getting to grips with 'profiles' in maven. I probably read > about > that at one point and have used them, but will go back to refresh my > knowledge (now that I understand more of the basics). > I did observe that the MavenTestAdapter has a getPlayerGlobal method > which > looks for the swc in the tests for compiler (not compiler-jx), this > still > tries to run the tests if playerglobal is missing (and assuming the > debug > player is available), but the player has bad bytecode (e.g. error > dialogs > like TypeError: Error #2023: Class ASDateTests1933741105634631672$ must > inherit from Sprite to link to the root.) > > When I look at getPlayerglobal() inside MavenTestAdapter I do see > something > a little confusing (to me). > > It checks to see if PLAYERGLOBAL_HOME is defined. If it is not, it > bails > and returns null. This will cause an error later in testing > But PLAYERGLOBAL_HOME does not appear to be used to find the > playerglobal > swc anywhere else, so this check may not even be relevant. > if PLAYERGLOBAL_HOME is defined, then it ignores it and looks for the > swc > in System.getProperty("mavenLocalRepoDir"). This is why I think it > finds it > after it has been cached in local m2 and perhaps why things continue to > work when it is removed from the pom dependencies. > > However, if I unset FLASHPLAYER_DEBUGGER env var then the tests phase > passes and the build continues on to completion. > So my failing combination is a) FLASHPLAYER_DEBUGGER is defined and b) > PLAYERGLOBAL_HOME is not defined and/or local m2 does not contain > playerglobal swc > > > > On Fri, May 24, 2019 at 7:33 AM Alex Harui <[email protected]> > wrote: > > > I guess I am not making a clear statement. I understand you are > trying to > > help others, but unless you have tested from scratch with both > generating > > SWF artifacts and not generating SWF artifacts then you haven't > actually > > helped everyone, just those who want the same set of artifacts you > are > > expecting. > > > > I would not expect any solution to include an Adobe artifact without > using > > a profile to include it. > > > > You might need two videos, one for generating SWF artifacts and one > for > > not. > > > > If our tests require Flash, then there is no point in running them if > > there are no SWF artifacts. > > > > Thanks, > > -Alex > > > > On 5/23/19, 11:06 AM, "Carlos Rovira" <[email protected]> > wrote: > > > > Hi Alex, > > > > I'm not getting this working only for me, in fact my motivation > was > > exactly > > the opposite. The final motivation is to able to do a short > video to > > post > > on an Apache Royale youtube channel, since is something many, > many > > people > > requested. And something I think will give us more users and > exposure. > > > > I was working without problem each day. I tried to remove > repository > > folder > > to simulate a "day 0" like a new user to see if all was working. > The > > result > > was it was failing. > > > > Now with a dependency added in compiler's pom and a profile > added in > > the > > wiki instructions, I was able to build from scratch. Other's can > try > > this > > to proof is a solution for anyone. > > > > IOW, If a new user tries the wiki steps some days ago he'd found > royale > > didn't build, and fails with the error exposed here, and will get > > stuck. > > Now, hopefully he will get it working. > > > > For me is ok, all you say (maybe the only thing I don't agree is > put > > skipTests to false as an official way to make maven build work > > officially, > > since in maven tests are mandatory, and you must opt-out, with a > > profile o > > via command line, but official build should work with normal > tests in a > > first execution). > > > > About having a repository or not: This should not matter, but > the fact > > is > > it currently does, independently of what any of us want. I, as > you, > > would > > want the simplest way to build, that could be always the same, > but > > there's > > a difference in a first maven build of royale against the > subsequent > > builds, that can be simplified (removing the -s settings... and > the > > -Pprofile..). I didn't design the process, but is what we have > now. So > > is > > important to test against an empty repository folder, unless we > change > > the > > build process and get it more simpler, what I don't expect to > happen > > anytime soon, since all of us have many things on plate right > now. > > > > I think we all understand the goals, and that we have two sets of > > outputs. > > Right now, I only know how to get one of them. If there's other > one you > > know you can post it here and I can put on wiki, or directly > modify > > wiki > > page that is the official one. If you can do the second, it > would be > > great > > since it will be more accurate to what you have in mind. > > > > If you have no time fo now what we can do is: > > 2 > > a) I can reintroduce the "-Putils" line in the wiki as something > to do > > in a > > concrete case, since right now (at the time we are writing > this), as > > you > > posted is important in a concrete situation, but not in building > from > > scratch (for now until your changes will be merged). > > > > b) As soon as you get your branch working and merged in develop, > you > > should > > change the wiki to conform to the needs of the changes you will > > introduce > > in your branch. I'll be interested in give a hand here and test > it > > againts > > an empty repo, and from a Mac, and help to refine the process > and the > > wiki > > if needed. > > > > About the planned video, since is a time consuming work maybe > better to > > postpone until your work is merged so I can create one that > doesn't get > > obsolete in few days. > > > > It's ok for you? > > > > thanks > > > > > > > > El jue., 23 may. 2019 a las 18:29, Alex Harui > > (<[email protected]>) > > escribió: > > > > > > > > > > > On 5/23/19, 3:04 AM, "Carlos Rovira" <[email protected]> > > wrote: > > > > > > Hi Alex, > > > > > > El jue., 23 may. 2019 a las 3:49, Alex Harui > > (<[email protected] > > > >) > > > escribió: > > > > > > > Before we go too far in any one direction, I may not be > able to > > > respond > > > > fully to this thread today as there seems to be a lot to > catch > > up > > > on, but > > > > let me try to summarize the goals of the Maven build. > > > > > > > > 1) There are some helper jars (compiler-build-tools and > > > > compiler-jburg-types). They are built by the "utils" > > profile. They > > > > haven't changed in develop, but they will change in > 0.9.6. > > They've > > > been > > > > changed in the release_practice branch. So folks will > need to > > use > > > the > > > > "utils" profile whenever we (rarely) change those jars. > > > > > > > > > > > Ok, so we should put in wiki that utils profile is needed > for > > that > > > case, > > > but not for "initial" build case. I'm worried to try to > simplify > > > instructions and process to minumun needs to avoid new > comers > > > confusion. > > > So, I'll mention utils profile as a special case to > execute when > > > needed. > > > > > > As soon as I merge release_practice into develop, you will > need to > > use the > > > utils profile to build from scratch. > > > > > > > 2) Adobe will probably never publish official > playerglobal on > > Maven. > > > > There is a whole bunch of logic in the Mavenizer to > address > > licensing > > > > acceptance issues. > > > > > > > > > > For what we discussed in the thread, seems playerglobal is > > already on > > > maven > > > official repos, so my guest is we are served with that and > don't > > need > > > adobe > > > host it in a maven repo. > > > > > > Adobe has not given permission to distribute playerglobal in > this > > way so > > > we cannot use it. > > > > > > > > > > > 3) IIRC, the most recent changes were to allow the Maven > build > > to > > > work > > > > without requiring SWF versions of artifacts and probably > > > > playerglobal/airglobal. So, adding hard requirements to > > > playerglobal will > > > > defeat this capability unless those dependencies are in > the > > > appropriate > > > > Maven profile. > > > > > > > > > > Right now we need to do this: > > > > > > mvn -s settings-template.xml clean install > > -Pgenerate-swcs-for-swf > > > so this means something is not working ok in a clean > environment > > for > > > first > > > build/install? > > > For now, the current instructions works, but if that's the > case, > > we > > > should > > > try to fix this in the future, although seems this is not > urgent > > while > > > people is capable of build Royale in the current way. > > > > > > The goal for Maven, like the goal for the Ant builds, is to not > > require > > > Adobe artifacts and build JS-only versions. Building SWF > versions is > > > opt-in. I'm not surprised there are bugs after these changes, > but > > the > > > solutions should consider that there are two different sets of > > output. > > > > > > > > > > > 4) The CI builds (builds.a.o and apachroyalecibuild) are > good > > > reference > > > > examples of Maven building things correctly on Windows. > You > > can > > > compare > > > > your setup and console output to those builds. > > > > > > > > > > I was building without problem and still can build without > > problem. My > > > concern was for the case people tries to build maven for > the > > first > > > time, > > > and was where I found problems. This problems are as well > not > > > reproduced in > > > machines that are already working, since they pass the > initial > > setup. > > > > > > > > > > > > > > 5) There might be some assumption that airglobal and/or > > playerglobal > > > exist > > > > to determine whether the build is going to try to output > SWF > > > versions of > > > > the artifacts or not. > > > > > > > > 6) The default, IIRC, is to not require > airglobal/playerglobal > > and > > > build a > > > > JS-Only set of artifacts similar to how it is done in > the Ant > > builds. > > > > > > > > > > So, this wiki walkthrough: > > > > > > > > > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fwiki%2FBuild-Apache-Royale-with-Maven&data=02%7C01%7Caharui%40adobe.com%7C216792e9f44d47dff61208d6dfcf2157%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636942478056043286&sdata=tv9uPSXTrChT%2FGaw%2F2XtrpFcxJ46vDyzjH7jfYz6piU%3D&reserved=0 > > > is describing whole process without differentiation. > > > can be updated to build with maven SWF/JS and in the other > hand > > only > > > JS? > > > I think the actual page description us for SWF/JS, and I > > personally > > > never > > > try / or know how to build just JS, what would be very > > interesting > > > since > > > many people will really only build for JS, and if sometime > in the > > > future we > > > have other interesting target like WebAsembly, will want > to add > > it and > > > build JS/WEBASM > > > > > > I was unaware of the page so it didn’t get updated with these > > changes to > > > not require SWF artifacts. So it does need updating, but it > would > > be best > > > to first make it clear that there are two sets of output. > > > > > > > > > > > Unfortunately, that means that most of the ideas I've > read > > while > > > skimming > > > > over this thread so far may not be correct. > > > > > > > > > > I think you have to have in mind that we all was working > right > > with our > > > current environment and that the problem comes from try to > start > > from > > > scratch. Subsequents builds instructions are simpler since > > requires > > > shorter > > > instructions. > > > You should try to rename your "repository" folder and > create a > > new one > > > and > > > try to build with maven to see what you find and if we can > > improve > > > actual > > > findings. > > > > > > Someday I will find time to do that. May not be today. It > is, IMO, > > more > > > important for others to understand the goals and how this stuff > > works so it > > > isn't all on me. My understanding of Maven, which I am not an > > expert, is > > > that what is in your local repository shouldn’t matter. Maven > goes > > and > > > gets the dependencies you ask for in the pom.xml. The only > "trick" > > is how > > > the Mavenizer extension works. That is the only thing that > doesn't > > fetch > > > from Maven Central. So renaming or flushing the repository > > "shouldn't" > > > make a difference and someone should figure out why, but only > after > > making > > > sure the configurations make sense. Maybe all of the SWC POMs > in > > > royale-asjs need a profile that opt-in the SWF artifacts. That > > might be > > > the actual issue. And maybe we set skipTests=false in the > compiler > > if not > > > using SWF artifacts via some profile. > > > > > > The key point is that you can't just "get it working for > you". We > > have to > > > maintain the two sets of outputs for others. > > > > > > HTH, > > > -Alex > > > > > > > > > > -- > > Carlos Rovira > > > > > https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C216792e9f44d47dff61208d6dfcf2157%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636942478056043286&sdata=3lU8ntUGoybH%2BtfvVQNOtDS6NLDn4HIwaj75I82dQqM%3D&reserved=0 > > > > > > > > > -- Carlos Rovira http://about.me/carlosrovira
