I think we'll be downloading FP and AIR SDKs for quite some time. -Alex
On 11/29/13 10:31 AM, "OmPrakash Muppirala" <bigosma...@gmail.com> wrote: >What about FlashPlayer swc? Even though it is optional for production >use, >they see required during development i.e. compilation time right? > >Also, what if the user wants to target the AIR runtime? Could that be an >optional download? > >Thanks, >Om >On Nov 29, 2013 8:13 AM, "Erik de Bruin" <e...@ixsoftware.nl> wrote: > >> I would very much prefer to download the latest version... but I think >> it's more realistic to download a specific version. >> >> I do hate that decisions like this (however logical at the moment) >> always come back to bite you. Some of the libraries (the closure >> compiler chief among them) will become so outdated that updating to >> the latest version (as we needed to do recently) will no longer be >> trivial. >> >> But for now, a fixed version will mean one less thing to worry about. >> Our best bets going forward are: >> >> Closure compiler: >> https://closure-compiler.googlecode.com/files/compiler-20131014.zip >> >> Closure Library: >> >> >>https://closure-library.googlecode.com/files/closure-library-20130212-95c >>19e7f0f5f.zip >> >> For the compiler, it is the release before the update to Java 7; for >> the library, it is the 'latest' packaged release (you're actually >> supposed to get the latest and greatest from their git repo). >> >> EdB >> >> >> >> On Fri, Nov 29, 2013 at 4:28 PM, Alex Harui <aha...@adobe.com> wrote: >> > Excellent. Sounds right to me. >> > >> > And yes, AUIC, the Installer will have to download the closure >>library. >> > We cannot bundle it in the binary artifacts even though it has an >>Apache >> > License. That's because an official Apache release must only contain >> > source and the convenience binary package must only contained compiled >> > results of that source. It isn't clear whether the binary package can >> > contain jars, etc downloaded in order to compile that source, but the >> > closure library isn't needed to compile our source (unless you count >> > tests). >> > >> > One thing to decide: Should the installer grab the latest closure >> library >> > and compiler or should we hit a particular known version? I assume >>we'll >> > do the latter? At least by default? >> > >> > -Alex >> > >> > On 11/29/13 5:48 AM, "Erik de Bruin" <e...@ixsoftware.nl> wrote: >> > >> >>Ok, that is given the assumption that there is a Closure Library in >> >>the SDK (copied there by the Installer - soon?), in the location >> >>'[FlexJSSDKRoot]/js/lib/google/closure-library'. >> >> >> >>EdB >> >> >> >> >> >>On Fri, Nov 29, 2013 at 2:44 PM, Erik de Bruin <e...@ixsoftware.nl> >> wrote: >> >>> And finally: I committed a change that resolves relative paths >> >>> correctly when the compiler is called from outside the root of the >> >>> SDK. A 'Hello World' app will now compile successfully with only >>this >> >>> command line call: >> >>> >> >>> java -jar "[PathToFlexJSSDK]/js/lib/mxmlc.jar" >> >>> -load-config="[PathToFlexJSSDK]/frameworks/flex-config.xml" >> >>> "[PathToMainProjectFile]" >> >>> >> >>> Couldn't be much easier, now can it? >> >>> >> >>> EdB >> >>> >> >>> >> >>> >> >>> On Fri, Nov 29, 2013 at 1:48 PM, Erik de Bruin <e...@ixsoftware.nl> >> >>>wrote: >> >>>> To continue this monologue: I've committed a change to the config >> >>>> class that adds default relative paths (to FlexJS SDK) for the >>above >> >>>> mentioned remaining command line arguments. >> >>>> >> >>>> EdB >> >>>> >> >>>> >> >>>> >> >>>> On Fri, Nov 29, 2013 at 1:11 PM, Erik de Bruin <e...@ixsoftware.nl> >> >>>>wrote: >> >>>>> Never mind, a liberal application of quotes solved the error. This >> >>>>> seems to be the current minimum command line: >> >>>>> >> >>>>> cd "/Applications/Adobe Flash Builder 4.7/sdks/4.11.0_overlay" >> >>>>> >> >>>>> java -jar "./js/lib/mxmlc.jar" >> >>>>> -load-config="./frameworks/flex-config.xml" >> >>>>> >> >> >>>>>>>-closure-lib="/Users/erik/Documents/ApacheFlex/dependencies/GoogleCl >>>>>>>osu >> >>>>>re/library" >> >>>>> -sdk-js-lib="./frameworks/js/FlexJS/src" "$LOC_PROJECT_ROOT_INPUT" >> >>>>> >> >>>>> So, if we give '-sdk-js-lib' and '-closure-lib' default values of >> >>>>> './frameworks/js/FlexJS/src' and './js/lib/google/closure-library' >> >>>>> respectively - and have the installer download the Closure >>Library to >> >>>>> that location - we should be pretty close to the FDT people's >>ideal >> >>>>> situation. We would be able to compile a 'Hello World' into a >> >>>>> JavaScript application with: >> >>>>> >> >>>>> cd "/Applications/Adobe Flash Builder 4.7/sdks/4.11.0_overlay" >> >>>>> >> >>>>> java -jar "./js/lib/mxmlc.jar" >> >>>>> -load-config="./frameworks/flex-config.xml" >> >>>>> "/Users/user/Documents/hWorld/HelloWorld.as" >> >>>>> >> >>>>> Close enough? >> >>>>> >> >>>>> EdB >> >>>>> >> >>>>> >> >>>>> On Fri, Nov 29, 2013 at 12:50 PM, Erik de Bruin >><e...@ixsoftware.nl> >> >>>>>wrote: >> >>>>>> Trying to cut the launch commands down to bare metal I came up >>with >> >>>>>>this: >> >>>>>> >> >>>>>> SCRIPT_HOME="/Applications/Adobe Flash Builder >> >>>>>>4.7/sdks/4.11.0_overlay" >> >>>>>> >> >>>>>> java -Xmx384m -Dfile.encoding=UTF8 -Dsun.io.useCanonCaches=false >> >>>>>> -Dflexcompiler=${SCRIPT_HOME} -Dflexlib=${SCRIPT_HOME}/frameworks >> >>>>>>-jar >> >>>>>> ${SCRIPT_HOME}/js/lib/mxmlc.jar >> >>>>>> -load-config=${SCRIPT_HOME}/frameworks/flex-config.xml >> >>>>>> >> >> >>>>>>>>-closure-lib="/Users/erik/Documents/ApacheFlex/dependencies/GoogleC >>>>>>>>los >> >>>>>>ure/library" >> >>>>>> -sdk-js-lib=${SCRIPT_HOME}/frameworks/js/FlexJS/src >> >>>>>> ${LOC_PROJECT_ROOT_INPUT} >> >>>>>> >> >>>>>> Which "seems" to be what both 'mxmlc' and the FB launch files >>need. >> >>>>>> However, when I run above from the command line, I get: >> >>>>>> >> >>>>>> Error: Could not find or load main class Flash >> >>>>>> >> >>>>>> What is missing/am I doing wrong? >> >>>>>> >> >>>>>> EdB >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> On Fri, Nov 29, 2013 at 12:07 PM, Erik de Bruin >><e...@ixsoftware.nl >> > >> >>>>>>wrote: >> >>>>>>> Ok, the FDT people raised some interesting targets; I'd like to >> >>>>>>> discuss them one by one, to get a better understanding where we >>are >> >>>>>>> and what we're aiming for. >> >>>>>>> >> >>>>>>> 1. The user can get the FULLY functional Flex JS SDK by >>unzipping a >> >>>>>>> downloaded file(best soultion) or a downloaded installer if it >>is >> >>>>>>> executed does every step to create fully functional Flex JS SDK. >> >>>>>>> >> >>>>>>> This is what the Installer will do once the 'ant' stuff is >>checked >> >>>>>>>in? >> >>>>>>> >> >>>>>>> 2. Java should be the only extern dependency of the Flex JS SDK. >> >>>>>>> Everything else should be contained in the SDK. Also the >>compiler >> >>>>>>> should not refer to the SDK by using environment variables. >> >>>>>>> >> >>>>>>> If we include the Closure Library download in the Installer, >>this >> >>>>>>>is true? >> >>>>>>> >> >>>>>>> 3. The compiler can be started by calling a java class in some >>jar >> >>>>>>>file. >> >>>>>>> >> >>>>>>> Looking at 'mxmlc', this is already the case (java -jar >> >>>>>>>"../lib/mxmlc.jar")? >> >>>>>>> >> >>>>>>> 4. The settings needed to compile a Action Script project with >>the >> >>>>>>> Flex JS Compiler should be the reference to the main class, to >>the >> >>>>>>> source folders, to the swcs, to the used Flex JS SDK and the >>output >> >>>>>>> folder. The rest like references to Google Closure library >>should >> >>>>>>>have >> >>>>>>> default values refering into the Flex JS SDK via relative paths. >> All >> >>>>>>> other settings should have usefull default values which do not >> block >> >>>>>>> compilation. >> >>>>>>> >> >>>>>>> Besides what's already discussed in 2., I think all we need to >>do >> is >> >>>>>>> give '-closure-lib' a proper (relative) default? >> >>>>>>> >> >>>>>>> 5. The compiler output should be a directory or file containing >> >>>>>>> everything necessary to start the project. >> >>>>>>> >> >>>>>>> Already the case. >> >>>>>>> >> >>>>>>> 6. The compiler output should be launchable by sending some file >> >>>>>>>like >> >>>>>>> index.html to the browser. >> >>>>>>> >> >>>>>>> Already the case. >> >>>>>>> >> >>>>>>> 7. The hello world example should only need the reference to one >> >>>>>>>main >> >>>>>>> class, one source folder, a few swcs, the sdk, and an output >>folder >> >>>>>>> and should be successfully compiled with no other settings >>given to >> >>>>>>> the compiler. >> >>>>>>> >> >>>>>>> Given 4., this is the case? >> >>>>>>> >> >>>>>>> 8. The compiler interface should be stable over time. We are not >> >>>>>>> willing to adjust the transfered settings each new version. >> >>>>>>> >> >>>>>>> Seems logical to have a stable API... Nothing here, moving >>along. >> >>>>>>> >> >>>>>>> 9. The necessary jars of the compiler should be placed all in >>one >> >>>>>>> folder of the sdk. >> >>>>>>> >> >>>>>>> Already the case? >> >>>>>>> >> >>>>>>> 10. The compiler jars should have the ability to be unloaded >>from >> >>>>>>>the >> >>>>>>> jvm if the classloader of these jars is dropped. >> >>>>>>> >> >>>>>>> I have no idea what that means... >> >>>>>>> >> >>>>>>> 11. The compiler interface should be simple like: Instantiaton >>of a >> >>>>>>> class. Then using some setters to set main class, source files, >>swc >> >>>>>>> files, sdk location, output location, and a progress listener >>with >> >>>>>>>the >> >>>>>>> possibility to interrupt the compilation if the user wish that. >>The >> >>>>>>> main build method should return the result as a list of >> >>>>>>> errors/warnings or simply success. >> >>>>>>> >> >>>>>>> Not sure about the first part (interrupting compilation), but >>I'm >> >>>>>>> pretty sure we've got the basics for the return values. >> >>>>>>> >> >>>>>>> Thoughts, ideas? >> >>>>>>> >> >>>>>>> EdB >> >>>>>>> >> >>>>>>> >> >>>>>>> >> >>>>>>> -- >> >>>>>>> Ix Multimedia Software >> >>>>>>> >> >>>>>>> Jan Luykenstraat 27 >> >>>>>>> 3521 VB Utrecht >> >>>>>>> >> >>>>>>> T. 06-51952295 >> >>>>>>> I. www.ixsoftware.nl >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> -- >> >>>>>> Ix Multimedia Software >> >>>>>> >> >>>>>> Jan Luykenstraat 27 >> >>>>>> 3521 VB Utrecht >> >>>>>> >> >>>>>> T. 06-51952295 >> >>>>>> I. www.ixsoftware.nl >> >>>>> >> >>>>> >> >>>>> >> >>>>> -- >> >>>>> Ix Multimedia Software >> >>>>> >> >>>>> Jan Luykenstraat 27 >> >>>>> 3521 VB Utrecht >> >>>>> >> >>>>> T. 06-51952295 >> >>>>> I. www.ixsoftware.nl >> >>>> >> >>>> >> >>>> >> >>>> -- >> >>>> Ix Multimedia Software >> >>>> >> >>>> Jan Luykenstraat 27 >> >>>> 3521 VB Utrecht >> >>>> >> >>>> T. 06-51952295 >> >>>> I. www.ixsoftware.nl >> >>> >> >>> >> >>> >> >>> -- >> >>> Ix Multimedia Software >> >>> >> >>> Jan Luykenstraat 27 >> >>> 3521 VB Utrecht >> >>> >> >>> T. 06-51952295 >> >>> I. www.ixsoftware.nl >> >> >> >> >> >> >> >>-- >> >>Ix Multimedia Software >> >> >> >>Jan Luykenstraat 27 >> >>3521 VB Utrecht >> >> >> >>T. 06-51952295 >> >>I. www.ixsoftware.nl >> > >> >> >> >> -- >> Ix Multimedia Software >> >> Jan Luykenstraat 27 >> 3521 VB Utrecht >> >> T. 06-51952295 >> I. www.ixsoftware.nl >>