On 2/28/18, 1:52 PM, "[email protected] on behalf of Carlos Rovira" <[email protected] on behalf of [email protected]> wrote:
>Hi Alex, >you're right, maybe this deserves more thinking,...in the actual approach, >I think that compiler should copy the same assets folder to target so SWF >can access it right? We could do that. Some folks don't think we should copy assets as part of the compiler, and that the publisher should be a separate thing. Whatever we do here will take time, so I'm probably not going to spend any time on it right now. Lots of other bigger fish to fry. At least folks can copy from bin/js-debug if they want to. I would recommend copying resources in your Maven and Ant scripts for now. Thanks, -Alex > >2018-02-28 18:13 GMT+01:00 Alex Harui <[email protected]>: > >> We could do that if we get enough complaints, but the nice thing about >>the >> way it currently works is that the output folder is all-inclusive. You >> can deploy (after a Maven build) the target/javascript/bin/js-release >> folder and your assets will be in there, and the URLs will be >> URL("assets/MyAsset.jpg"). In your proposal, the user has to remember >>to >> copy the assets folder as well, and the URLs will look like >> URL("../../../../assets/MyAsset.jpg") and the layout on the web server >> will have to have the same deep folder structure. >> >> Are you seeing long build times? We could just choose to not overwrite >> existing files. That might save time. >> >> My 2 cents, >> -Alex >> >> On 2/28/18, 8:40 AM, "[email protected] on behalf of Carlos >>Rovira" >> <[email protected] on behalf of [email protected]> wrote: >> >> >Hi, don't know if I understand right since all the things about the >> >compiler are beyond my scope, but what I'm suggesting is to realocate >> >resources. But don't know if this sounds crazy or not. In this way we >>can >> >support current outputs (JS and SWF) but prepare for future outputs >> >(WEBASM, iOS, Android,...) >> > >> >so it will end as is: >> > >> > >> >target >> > | >> > ------ assets (inside this folder all output like css, svg, png,...) >> > | >> > ------- swf (in this folder the .swf (s) app + modules, but for this >>all >> >should search for resources in "../assets" for all assets not @Embeded >>in >> >swf >> > | >> > ------- js (in this folder will go html and all js files that again >> >should look for resources in "../assets" >> > | >> > -------- webasm >> > | >> > -------- iOS >> > | >> > -------- Android >> > | >> > -------- whatever other output we want to implement >> > >> >if not I understand that each output should provide its own assets >>folder, >> >and this will end wasting resources for duplication (n times depending >>on >> >how many outputs we want to get) and wasting time and CPU process.. >> > >> >does this make sense? >> > >> > >> > >> > >> > >> > >> > >> > >> >2018-02-27 18:11 GMT+01:00 Alex Harui <[email protected]>: >> > >> >> Hi Jason, >> >> >> >> Actually, I didn't know that. I'm not a compiler guy. Someone else >> >>wrote >> >> the key pieces. I could see that way back, a compiler might have >> >>written >> >> out intermediate information for the next step, like having a >>separate >> >> linker that links the object files. But I don't think I've seen (or >> >>maybe >> >> I just haven't used) options to output extra information for >> >> post-processing after the final output. We could certainly output >>extra >> >> information, but then that information needs to be parsed again to be >> >>used >> >> by the publisher. >> >> >> >> If that's the way folks want to go, all we need is a volunteer to >>make >> >>it >> >> happen. Currently, the publisher does not need the AST so it might >>even >> >> be possible to write the publisher in ActionScript. But that might >>make >> >> it harder to integrate with Maven. >> >> >> >> What do others think? >> >> -Alex >> >> >> >> On 2/27/18, 8:54 AM, "Jason Guild" <[email protected]> wrote: >> >> >> >> >Alex: >> >> > >> >> >As you probably know, compilers in the old days were implemented in >>a >> >> >series of stages as separate processes due to memory size >>limitations. >> >> >The output from the previous stage was fed to the next stage as >> >> >compilation proceeded until object files were produced. >> >> > >> >> >Maybe it makes sense for the compiler to output everything the >> >>publisher >> >> >needs (final ASTs and/or other metadata, etc) when it exits. >> >> >Then a separate publisher process could optionally use that output >>to >> >>do >> >> >all the expected publish-type things without being intermingled with >> >>the >> >> >compiler itself. >> >> > >> >> >The publisher would probably be simpler to understand on its own and >> >> >maybe more people could be involved with it. >> >> > >> >> >Jason >> >> > >> >> >On 2/26/2018 8:49 PM, Alex Harui wrote: >> >> >> The only >> >> >> downside I've thought of is just that it is weird to have a >>publisher >> >> >> attached to the compiler. I don't think most compilers have a >> >> >>publisher. >> >> > >> >> >-- >> >> >Jason Guild >> >> >Analyst/Programmer V >> >> >State of Alaska - Department of Transportation & Public Facilities >> >> >Information Systems and Services Division >> >> >820 E. 15th Ave. >> >> >Anchorage, Alaska 99501 >> >> > >> >> >> >> >> > >> > >> >-- >> >Carlos Rovira >> >https://na01.safelinks.protection.outlook.com/?url= >> http%3A%2F%2Fabout.me%2 >> >Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com% >> 7C3da558b1a44a46dfc41b08d5 >> >7ec9fc08%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0% >> 7C636554328342487363&s >> >data=aduUVLnj5Q8FYqR9KJ6WZeEoLN1GqSVVbalBmhAwZSA%3D&reserved=0 >> >> > > >-- >Carlos Rovira >https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2 >Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C43a5a6f66b7b4869aa6c08d5 >7ef597aa%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636554515653880312&s >data=%2F90VveLbQkI3GLiIaKQbwXWjhrtKilTmxVkoAN0gaLI%3D&reserved=0
