Re: SDK bug fixing in IntelliJ
Thanks Nick. I didn't know. I have added flex-sdk to Intellij a bit different than you suggest. I have no plan to work with Java code so I did it as a Flash module (whole sdk). Thanks Maurice I will try this. :) Now I am going to run mustella tests. :) P.S. modules with modules in Intellij - This is one of those things witch I really like in this IDE. :) Piotr - Flex/Air developer open to new job offers and challenges. piotrzarzyck...@gmail.com -- View this message in context: http://apache-flex-development.247.n4.nabble.com/SDK-bug-fixing-in-IntelliJ-tp32653p32903.html Sent from the Apache Flex Development mailing list archive at Nabble.com.
Re: [DRAFT] Apache Flex December 2013 Report
On 12/2/13 11:46 PM, Erik de Bruin e...@ixsoftware.nl wrote: me to be a good place to state that. When putting the guidelines together consensus was that the chair should be for a year or reviewed every year. When I voted I took the guideline to mean: for at least a year and automatically extended by a year if the chair chose to stay on, unless the PMC took a vote to replace him/her. And that's why I mentioned that I think this wording needs fixing. It should do a better job of explaining the details. The way the words are currently written, I could just keep saying I want to renew every year forever. It should not just be up to me to decide whether to continue, the rest of the PMC should have a say. The Ant guidelines say: The PMC may consider the position of PMC chair annually and if supported by 2/3 Majority may recommend a new chair to the board but doesn't really say how they decide who to recommend (also 2/3 or consensus?). We don't say that either, but I think it should be consensus minus the candidates? Anyway, my work day is over. If others agree the words need fixing I'll propose some ideas in a new thread tomorrow. -Alex
Re: [DRAFT] Apache Flex December 2013 Report
should do a better job of explaining the details. The way the words are currently written, I could just keep saying I want to renew every year forever. It should not just be up to me to decide whether to continue, As keeps being pointed out to me: once you merit a position in the Apache hierarchy, you get that position until you resign or until the PMC/Board strips you of that position. If that goes for committers and PMC members, it should certainly go for the chair. The way the guideline is written (chair can stay unless ousted by the PMC) seem to me to be a reflection of the Apache Way. EdB -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl
FlexJS compiler support for FDT
Hi developers at flex.apache.org a few days ago Om Muppirala had added a new feature request to our Jira to support the FlexJS Compiler in FDT (http://bugs.powerflasher.com/jira/browse/FDT-3281). I already added a list of our typical requirements for external software to this ticket. Nevertheless I was curious about your progress and so I followed the steps at: https://cwiki.apache.org/confluence/display/FLEX/Using+FlexJS+with+Adobe+Flash+Builder At the point where Flash Builder should launch a special launch configuration to compile the example project with the FlexJS compiler I decided to try this step with the windows command line since this part should be done by FDT as a first step to support the FlexJS compiler. Unfortunately this attempt failed. Maybe you could give me a hint what I should change in the command line or what files are missing in my FlexJS SDK. The command line I used is this: D:\NewSdks\ApacheFlexJSjava -Xmx384m -Dfile.encoding=UTF8 -Dsun.io.useCanonCaches=false -Dflexcompiler=D:\NewSdks\ApacheFlexJS -Dflexlib=D:\NewSdks\ApacheFlexJS\frameworks -jar D:\NewSdks\ApacheFle xJS\js\lib\mxmlc.jar -compiler.mxml.children-as-data -compiler.binding-value-change-event-type=valueChange -js-output-type=FLEXJS -closure-lib=D:\NewSdks\closure-library-20130212 -sdk-js-lib=D:\NewSdks\ ApacheFlexJS\frameworks\js\FlexJS\src -target-player=11.9 -library-path+=D:\NewSdks\ApacheFlexJS/frameworks/as/libs/FlexJSUI.swc -source-path=D:\TesTArea\TestProjects\DataBindingTest/src -output=D:\TesT Area\TestProjects\DataBindingTest/bin -- D:\TesTArea\TestProjects\DataBindingTest/src/DataBindingTest.mxml The result shows some exceptions during compilation and one error: outputBindingInfoAsData Compiling file: D:\TesTArea\TestProjects\DataBindingTest\bin\js-debug\DataBindingTest.js Compiling file: D:\TesTArea\TestProjects\DataBindingTest\bin\js-debug\controllers\MyController.js Compiling file: D:\TesTArea\TestProjects\DataBindingTest\bin\js-debug\MyInitialView.js Compiling file: D:\TesTArea\TestProjects\DataBindingTest\bin\js-debug\models\MyModel.js Compiling file: D:\TesTArea\TestProjects\DataBindingTest\bin\js-debug\StockDataJSONItemConverter.js Could not find file for class: org.apache.flex.html.staticControls.supportClasses.Border java.io.FileNotFoundException: at java.io.FileInputStream.open(Native Method) at java.io.FileInputStream.init(Unknown Source) at java.io.FileInputStream.init(Unknown Source) at org.apache.flex.compiler.internal.graph.GoogDepsWriter.getDirectDependencies(GoogDepsWriter.java:252) at org.apache.flex.compiler.internal.graph.GoogDepsWriter.addDeps(GoogDepsWriter.java:122) at org.apache.flex.compiler.internal.graph.GoogDepsWriter.addDeps(GoogDepsWriter.java:137) at org.apache.flex.compiler.internal.graph.GoogDepsWriter.addDeps(GoogDepsWriter.java:137) at org.apache.flex.compiler.internal.graph.GoogDepsWriter.addDeps(GoogDepsWriter.java:137) at org.apache.flex.compiler.internal.graph.GoogDepsWriter.addDeps(GoogDepsWriter.java:137) at org.apache.flex.compiler.internal.graph.GoogDepsWriter.buildDB(GoogDepsWriter.java:78) at org.apache.flex.compiler.internal.graph.GoogDepsWriter.generateDeps(GoogDepsWriter.java:49) at org.apache.flex.compiler.internal.codegen.mxml.flexjs.MXMLFlexJSPublisher.publish(MXMLFlexJSPublisher.java:135) at org.apache.flex.compiler.clients.MXMLJSC.compile(MXMLJSC.java:421) at org.apache.flex.compiler.clients.MXMLJSC._mainNoExit(MXMLJSC.java:261) at org.apache.flex.compiler.clients.MXMLJSC.mainNoExit(MXMLJSC.java:219) at org.apache.flex.compiler.clients.MXMLJSC.main(MXMLJSC.java:181) Could not find file for class: org.apache.flex.html.staticControls.supportClasses.ScrollBar java.io.FileNotFoundException: (Das System kann die angegebene Datei nicht finden) at java.io.FileInputStream.open(Native Method) at java.io.FileInputStream.init(Unknown Source) at java.io.FileInputStream.init(Unknown Source) at org.apache.flex.compiler.internal.graph.GoogDepsWriter.getDirectDependencies(GoogDepsWriter.java:252) at org.apache.flex.compiler.internal.graph.GoogDepsWriter.addDeps(GoogDepsWriter.java:122) at org.apache.flex.compiler.internal.graph.GoogDepsWriter.addDeps(GoogDepsWriter.java:137) at org.apache.flex.compiler.internal.graph.GoogDepsWriter.addDeps(GoogDepsWriter.java:137) at org.apache.flex.compiler.internal.graph.GoogDepsWriter.addDeps(GoogDepsWriter.java:137) at org.apache.flex.compiler.internal.graph.GoogDepsWriter.addDeps(GoogDepsWriter.java:137) at org.apache.flex.compiler.internal.graph.GoogDepsWriter.buildDB(GoogDepsWriter.java:78) at org.apache.flex.compiler.internal.graph.GoogDepsWriter.generateDeps(GoogDepsWriter.java:49) at
Re: FlexJS compiler support for FDT
Hi, Good to hear you're working on this! Last week I greatly simplified the command line you need to successfully build a FlexJS project. We're working on getting the installer to create a 'one click FlexJS SDK' that will contain all dependencies except Java, but until that time it looks like you need to take only these 2 steps: 1) move your closure library from 'D:\NewSdks\closure-library-20130212' to 'D:\NewSdks\ApacheFlexJS\js\lib\google\closure-library' 2) use this command line: java -jar D:\NewSdks\ApacheFlexJS\js\lib\mxmlc.jar -load-config=D:\NewSdks\ApacheFlexJS\frameworks\flex-config.xml D:\TesTArea\TestProjects\DataBindingTest/src/DataBindingTest.mxml All other command line arguments are (should be...) either unneeded or will result in duplicate code warnings/errors. Thanks, EdB PS. the one warning after successful compilation (Data binding will not be able...) is expected and can be safely ignored. -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl
[FB] Enabling network monitor can overwrite include-libraries compiler settings
Beware of a strange Flash Builder behavior: when network monitor is activated in the IDE, Flash Builder will automatically add an include-libraries entry in the compiler configuration passed to MXMLC for netmon.swc (you can see it telling MXMLC to dump the configuration). I noticed that this may actually overwrite the include-libraries declared in the source App-config.xml file, creating problems at runtime if your project requires them. Just spent some hours trying to debug this issue, I hope to save this time to others and to my future self :)
Re: WANT TO OPEN SOURCE MY PROJECT
Yeah.. i will... - Shivang Gupta Director at webesperto.com Skype - sanghi.shivang GTalk - shivangsan...@gmail.com -- View this message in context: http://apache-flex-development.247.n4.nabble.com/WANT-TO-OPEN-SOURCE-MY-PROJECT-tp32225p32910.html Sent from the Apache Flex Development mailing list archive at Nabble.com.
RE: SharedLibrary not works with SDK 4.11
http://apps.facebook.com/houseoffun/?fb_source=bookmark_appsref=bookmarkscount=18fb_bmpos=3_18 the main file (for the upcoming version) is 566k, currently it is slightly over 600K, the assets are ~3 mb and i have implemented most popups as external modules, to ensure that they load from cdn only one time per session. The main application is a spark application. I use only simple objects, Group, List etc... nothing uber fancy. Most of the heavy lifting is done with AS3 for speed. We have a very large number of users. I can't statically link the libs because ppl expect the blinding fast load that I have achieved. 566K loads in the blink of an eye on even mediocre systems/connections. Personally I would prefer to statically link the framework because RSL's are yet another hit the browser has to make, but we need the users to get into the game and play as fast as possible. I have maintained the fastest load in our category on facebook for nearly a year now. :) I intend/need to keep it that way. so your short answer is a very big, yet very, very SMALL and optimized facebook app which is exactly why i have to use them :) Any way around this limitation would open the door for me to promote and fast-track the adoption of Apache Flex. I need small and I need fast. The rest is academic. Once I have the tools, I'll make it happen, and we will migrate to Apache Flex. Our target Flash Player version is 10.3 for maximum penetration. If there is any glimmer of hope to accomplish this... tell me, and let me know how I can help. From: aha...@adobe.com To: dev@flex.apache.org Date: Mon, 2 Dec 2013 11:22:26 -0800 Subject: Re: SharedLibrary not works with SDK 4.11 On 12/2/13 10:13 AM, David Coleman david_coleman_...@hotmail.com wrote: Having not tried this solution myself, this is pure speculation... but couldn't local storage store this? set domain to be * and retrieve it from the public svn repo. if not present the RSL manager can load it up and in this way we can sign it with our own Cert and validate that cert independent of Adobe? Would this be workable? I think you'd hit local storage limits. RSL's are the only reason that I hesitate to migrate our Facebook app to apache. it will kill our CDN. Just curious: Have you actually measured the difference without RSLs? How big a Facebook app is this? -Alex
AW: [DRAFT] Apache Flex December 2013 Report
Just to understand the current Position: - Alex is currently the chair and would volunteer to continue, but never has stated that he would aktually like to stay in that Position (It's more the others stating that they would want him to stay) - Justin actively would like to be the chair and would also be capable of doing so Currently it Looks as if Alex wouldn't mind passing on the Position to Justin and Justin would really like to do the Job? And if the chair Position has nothing to do with Alex' involvement with the Flex Project, wouldn't this give him even more time to do non-beaurocratic stuff? Then he could concentrate his time on delivering code and not for delivering reports? Just my thoughts to the discussion. Chris Von: Justin Mclean [jus...@classsoftware.com] Gesendet: Dienstag, 3. Dezember 2013 08:16 An: dev@flex.apache.org Betreff: Re: [DRAFT] Apache Flex December 2013 Report Hi, IMO he's not clearly stated that he will stand for another year and yes the choice is his. The board report seems to me to be a good place to state that. When putting the guidelines together consensus was that the chair should be for a year or reviewed every year. There may be other PMC members who would also like to have a turn at being the chair. There does seem some support for changing the chair (see the other discuss thread on that) but there's certainly not a consensus either way, up to Alex to consider and decide. Again I think everyone can agree he's done a good job and will continue to do so, but it may also be good to change and spread the experience about. Looking back to when Alex was voted in it was pointed out by the mentors that there should of been more discussion on who should be chair. [1] Now seems a good time to have that discussion. Thanks, Justin 1. http://markmail.org/message/3cljrqmwfipsq7zn
RE: Build failed in Jenkins: flex-sdk_mustella #579
Can't reproduce the failure. Tried the whole components/Alert/Properties/ mustella test -Message d'origine- De : flex.muste...@gmail.com [mailto:flex.muste...@gmail.com] Envoyé : mardi 3 décembre 2013 15:54 À : comm...@flex.apache.org; jmcl...@apache.org; Maurice Amsellem Objet : Build failed in Jenkins: flex-sdk_mustella #579 See http://localhost:8080/job/flex-sdk_mustella/579/changes Changes: [maurice.amsellem] UPDATE - FIX FLEX-33860 IOS7 Status bar height -- [...truncated 86191 lines...] [java] starting results server [java] starting baseline server [java] test script count: 7 [java] new test file: C:\jenkins_slave\workspace\flex-sdk_mustella\mustella\tests\components\Alert\SWFs\Alert_Spark.swf [java] starting the baseline server: Tue Dec 03 09:53:00 ACT 2013 [java] cmdArr before: [java] C:\ApacheFlex\dependencies\FlashPlayer_Debug\flashplayer12-0_debugsa_win_32.exe [java] C:\jenkins_slave\workspace\flex-sdk_mustella\mustella\tests\components\Alert\SWFs\Alert_Spark.swf [java] moreParameters before: [java] cmdArr after: [java] C:\ApacheFlex\dependencies\FlashPlayer_Debug\flashplayer12-0_debugsa_win_32.exe [java] C:\jenkins_slave\workspace\flex-sdk_mustella\mustella\tests\components\Alert\SWFs\Alert_Spark.swf [java] getting directory from the swf file [java] derived directory: C:\jenkins_slave\workspace\flex-sdk_mustella\mustella\tests\components\Alert\SWFs [java] Launching: [java] C:\ApacheFlex\dependencies\FlashPlayer_Debug\flashplayer12-0_debugsa_win_32.exe C:\jenkins_slave\workspace\flex-sdk_mustella\mustella\tests\components\Alert\SWFs\Alert_Spark.swf Launching: C:\ApacheFlex\dependencies\FlashPlayer_Debug\flashplayer12-0_debugsa_win_32.exe C:\jenkins_slave\workspace\flex-sdk_mustella\mustella\tests\components\Alert\SWFs\Alert_Spark.swf [java] USING directory: C:\jenkins_slave\workspace\flex-sdk_mustella\mustella\tests\components\Alert\SWFs [java] time: 09:53:00.636 [java] Wrote file: c:/jenkins_slave/workspace/flex-sdk_mustella/mustella/tests/components/Alert/SWFs/../Properties/baselines/Alert_layoutDirection_direction_rtl_with_alertIcon_spark.png.bad.png.xml length: 5167 [java] Wrote file: c:/jenkins_slave/workspace/flex-sdk_mustella/mustella/tests/components/Alert/SWFs/../Properties/baselines/Alert_layoutDirection_direction_rtl_with_alertIcon_spark.png.bad.png length: 7161 [java] FAIL: components/Alert/Properties/Alert_Properties_Spark Alert_layoutDirection_direction_rtl_with_alertIcon_spark [java] SCRIPTDONE! 09:53:03.935 [java] GET /ScriptComplete?0 HTTP/1.1 [java] Before Wait loop 09:53:03.935 waiting = 0 [java] After Wait loop 09:53:03.935 waiting = 0 [java] clobberProcess false [java] Total Results so far: 1 [java] Grab log, do parse = false [java] Grabbing the log from: C:\Users\ApacheFlex\AppData/Roaming\Macromedia/Flash Player/Logs/flashlog.txt to: C:\jenkins_slave\workspace\flex-sdk_mustella\mustella\tests\components\Alert\SWFs\Alert_Spark.log [java] new test file: C:\jenkins_slave\workspace\flex-sdk_mustella\mustella\tests\gumbo\components\Image\swfs\ImageMain.swf [java] cmdArr before: [java] C:\ApacheFlex\dependencies\FlashPlayer_Debug\flashplayer12-0_debugsa_win_32.exe [java] C:\jenkins_slave\workspace\flex-sdk_mustella\mustella\tests\gumbo\components\Image\swfs\ImageMain.swf [java] moreParameters before: [java] cmdArr after: [java] C:\ApacheFlex\dependencies\FlashPlayer_Debug\flashplayer12-0_debugsa_win_32.exe [java] C:\jenkins_slave\workspace\flex-sdk_mustella\mustella\tests\gumbo\components\Image\swfs\ImageMain.swf [java] getting directory from the swf file [java] derived directory: C:\jenkins_slave\workspace\flex-sdk_mustella\mustella\tests\gumbo\components\Image\swfs [java] Launching: [java] C:\ApacheFlex\dependencies\FlashPlayer_Debug\flashplayer12-0_debugsa_win_32.exe C:\jenkins_slave\workspace\flex-sdk_mustella\mustella\tests\gumbo\components\Image\swfs\ImageMain.swf Launching: C:\ApacheFlex\dependencies\FlashPlayer_Debug\flashplayer12-0_debugsa_win_32.exe C:\jenkins_slave\workspace\flex-sdk_mustella\mustella\tests\gumbo\components\Image\swfs\ImageMain.swf [java] USING directory: C:\jenkins_slave\workspace\flex-sdk_mustella\mustella\tests\gumbo\components\Image\swfs [java] time: 09:53:06.330 [java] waited 2100 [java] ClobberProcess, it was already null [java] SCRIPTDONE! 09:53:10.079 [java] GET /ScriptComplete?0 HTTP/1.1 [java] Before Wait loop 09:53:10.079 waiting = 0 [java] After Wait loop 09:53:10.079 waiting = 0 [java] clobberProcess false [java] Total Results so far: 2 [java] Grab log, do parse = false [java] Grabbing the log from:
Re: Build failed in Jenkins: flex-sdk_mustella #579
This is a new failure, isn't it? If so, give it one more run (likely 12 hrs) and if it's still there, it's real, if not you haven't wasted time looking for a solution. EdB On Tue, Dec 3, 2013 at 4:05 PM, Maurice Amsellem maurice.amsel...@systar.com wrote: Can't reproduce the failure. Tried the whole components/Alert/Properties/ mustella test -Message d'origine- De : flex.muste...@gmail.com [mailto:flex.muste...@gmail.com] Envoyé : mardi 3 décembre 2013 15:54 À : comm...@flex.apache.org; jmcl...@apache.org; Maurice Amsellem Objet : Build failed in Jenkins: flex-sdk_mustella #579 See http://localhost:8080/job/flex-sdk_mustella/579/changes Changes: [maurice.amsellem] UPDATE - FIX FLEX-33860 IOS7 Status bar height -- [...truncated 86191 lines...] [java] starting results server [java] starting baseline server [java] test script count: 7 [java] new test file: C:\jenkins_slave\workspace\flex-sdk_mustella\mustella\tests\components\Alert\SWFs\Alert_Spark.swf [java] starting the baseline server: Tue Dec 03 09:53:00 ACT 2013 [java] cmdArr before: [java] C:\ApacheFlex\dependencies\FlashPlayer_Debug\flashplayer12-0_debugsa_win_32.exe [java] C:\jenkins_slave\workspace\flex-sdk_mustella\mustella\tests\components\Alert\SWFs\Alert_Spark.swf [java] moreParameters before: [java] cmdArr after: [java] C:\ApacheFlex\dependencies\FlashPlayer_Debug\flashplayer12-0_debugsa_win_32.exe [java] C:\jenkins_slave\workspace\flex-sdk_mustella\mustella\tests\components\Alert\SWFs\Alert_Spark.swf [java] getting directory from the swf file [java] derived directory: C:\jenkins_slave\workspace\flex-sdk_mustella\mustella\tests\components\Alert\SWFs [java] Launching: [java] C:\ApacheFlex\dependencies\FlashPlayer_Debug\flashplayer12-0_debugsa_win_32.exe C:\jenkins_slave\workspace\flex-sdk_mustella\mustella\tests\components\Alert\SWFs\Alert_Spark.swf Launching: C:\ApacheFlex\dependencies\FlashPlayer_Debug\flashplayer12-0_debugsa_win_32.exe C:\jenkins_slave\workspace\flex-sdk_mustella\mustella\tests\components\Alert\SWFs\Alert_Spark.swf [java] USING directory: C:\jenkins_slave\workspace\flex-sdk_mustella\mustella\tests\components\Alert\SWFs [java] time: 09:53:00.636 [java] Wrote file: c:/jenkins_slave/workspace/flex-sdk_mustella/mustella/tests/components/Alert/SWFs/../Properties/baselines/Alert_layoutDirection_direction_rtl_with_alertIcon_spark.png.bad.png.xml length: 5167 [java] Wrote file: c:/jenkins_slave/workspace/flex-sdk_mustella/mustella/tests/components/Alert/SWFs/../Properties/baselines/Alert_layoutDirection_direction_rtl_with_alertIcon_spark.png.bad.png length: 7161 [java] FAIL: components/Alert/Properties/Alert_Properties_Spark Alert_layoutDirection_direction_rtl_with_alertIcon_spark [java] SCRIPTDONE! 09:53:03.935 [java] GET /ScriptComplete?0 HTTP/1.1 [java] Before Wait loop 09:53:03.935 waiting = 0 [java] After Wait loop 09:53:03.935 waiting = 0 [java] clobberProcess false [java] Total Results so far: 1 [java] Grab log, do parse = false [java] Grabbing the log from: C:\Users\ApacheFlex\AppData/Roaming\Macromedia/Flash Player/Logs/flashlog.txt to: C:\jenkins_slave\workspace\flex-sdk_mustella\mustella\tests\components\Alert\SWFs\Alert_Spark.log [java] new test file: C:\jenkins_slave\workspace\flex-sdk_mustella\mustella\tests\gumbo\components\Image\swfs\ImageMain.swf [java] cmdArr before: [java] C:\ApacheFlex\dependencies\FlashPlayer_Debug\flashplayer12-0_debugsa_win_32.exe [java] C:\jenkins_slave\workspace\flex-sdk_mustella\mustella\tests\gumbo\components\Image\swfs\ImageMain.swf [java] moreParameters before: [java] cmdArr after: [java] C:\ApacheFlex\dependencies\FlashPlayer_Debug\flashplayer12-0_debugsa_win_32.exe [java] C:\jenkins_slave\workspace\flex-sdk_mustella\mustella\tests\gumbo\components\Image\swfs\ImageMain.swf [java] getting directory from the swf file [java] derived directory: C:\jenkins_slave\workspace\flex-sdk_mustella\mustella\tests\gumbo\components\Image\swfs [java] Launching: [java] C:\ApacheFlex\dependencies\FlashPlayer_Debug\flashplayer12-0_debugsa_win_32.exe C:\jenkins_slave\workspace\flex-sdk_mustella\mustella\tests\gumbo\components\Image\swfs\ImageMain.swf Launching: C:\ApacheFlex\dependencies\FlashPlayer_Debug\flashplayer12-0_debugsa_win_32.exe C:\jenkins_slave\workspace\flex-sdk_mustella\mustella\tests\gumbo\components\Image\swfs\ImageMain.swf [java] USING directory: C:\jenkins_slave\workspace\flex-sdk_mustella\mustella\tests\gumbo\components\Image\swfs [java] time: 09:53:06.330 [java] waited 2100 [java] ClobberProcess,
Re: [FB] Enabling network monitor can overwrite include-libraries compiler settings
So I'm guessing that's why it wasn't sending cookies when you I was in the browser. I was logged into my site in the browser and sending and receiving messages (checked in Firebug). When I turned on network monitor the responses from the server were that I was no longer logged in and no network calls were showing up in Firebug. When I turned off the network monitor the calls went back through the browser and I was still logged in (Firefox). Also, even if you pause or stop it it will still log calls in some cases. On Tue, Dec 3, 2013 at 8:31 AM, Cosma Colanicchia cosma...@gmail.comwrote: On the same subject: the network monitor act as a proxy to the actual services, that in turn will use the Eclipse proxy settings to forward the invocations to the real destination. If the Eclipse proxy isn’t correctly set, it will appears as if your application cannot reach the back-end, only when network monitor is enabled for that application... 2013/12/3 piotr.zarzycki piotrzarzyck...@gmail.com Hi Cosma. One of my colleagues have noticed some strange behavior with this, when he switched off network monitor everything back to normal. :) But we didn't know what is in the background. Thanks for sharing this. :) Piotr - Flex/Air developer open to new job offers and challenges. piotrzarzyck...@gmail.com -- View this message in context: http://apache-flex-development.247.n4.nabble.com/FB-Enabling-network-monitor-can-overwrite-include-libraries-compiler-settings-tp32908p32909.html Sent from the Apache Flex Development mailing list archive at Nabble.com.
Re: [DRAFT] Apache Flex December 2013 Report
- Alex is currently the chair and would volunteer to continue, but never has stated that he would aktually like to stay in that Position (It's more the others stating that they would want him to stay) Actually, he has said he wanted to stay. A few times now. -Nick
Re: [DRAFT] Apache Flex December 2013 Report
On 12/3/13 12:34 AM, Erik de Bruin e...@ixsoftware.nl wrote: should do a better job of explaining the details. The way the words are currently written, I could just keep saying I want to renew every year forever. It should not just be up to me to decide whether to continue, As keeps being pointed out to me: once you merit a position in the Apache hierarchy, you get that position until you resign or until the PMC/Board strips you of that position. If that goes for committers and PMC members, it should certainly go for the chair. The way the guideline is written (chair can stay unless ousted by the PMC) seem to me to be a reflection of the Apache Way. OK, but how does the PMC oust the current chair? We can't require consensus in order to start a vote or else a power-hungry chair would just veto that attempt. I don't think a single PMC member should be able to start a vote either. We don't say what kind of vote is going to be used to select a new chair either. I'm thinking we should try to put some words about this in the guidelines. -Alex
Re: FlexJS compiler support for FDT
Actually, I just synced up to the repo and am getting the same error. I think something has gotten broken on our side. On 12/3/13 3:58 AM, Erik de Bruin e...@ixsoftware.nl wrote: Hi, Good to hear you're working on this! Last week I greatly simplified the command line you need to successfully build a FlexJS project. We're working on getting the installer to create a 'one click FlexJS SDK' that will contain all dependencies except Java, but until that time it looks like you need to take only these 2 steps: 1) move your closure library from 'D:\NewSdks\closure-library-20130212' to 'D:\NewSdks\ApacheFlexJS\js\lib\google\closure-library' 2) use this command line: java -jar D:\NewSdks\ApacheFlexJS\js\lib\mxmlc.jar -load-config=D:\NewSdks\ApacheFlexJS\frameworks\flex-config.xml D:\TesTArea\TestProjects\DataBindingTest/src/DataBindingTest.mxml All other command line arguments are (should be...) either unneeded or will result in duplicate code warnings/errors. Thanks, EdB PS. the one warning after successful compilation (Data binding will not be able...) is expected and can be safely ignored. -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl
RE: SharedLibrary not works with SDK 4.11
that's 566k of code... the code is mostly the networking layer, and facebook interface controllers. The 3 mb of assets load with the preloader and are broken into 2 modules so we can push art changes w/o pushing a whole new client. The preloader is 33% of the main loading screen - what happens is you don't see the transition between preloader and application because I designed it that way, so it looks like a single process. Basically I am already late loading the assets, but it is a requirement that the app be ready for interaction the moment the startup is done. unfortunately, most of the assets are required. for instance at least 1.5 to 2 mb is consumed by the game icons which the user must see instantly, and the game order is dynamic so we can't separate them into multiple pages to lower the load. Some minor optimizations can be made, and believe me, every few weeks I'm shaving a few K here or there. But not enough to add hundreds of K in statically linked libs. when i build (in debug) with static linking the size is 2,749,998 bytes vs 1,262,589 bytes in release there is a similar proportion: 1,225,769 bytes vs 609,402 bytes. (with Ant builds these numbers are slightly smaller, which is where i get the 566K for our upcoming release). basically the main file contains all the networking etc... this is because the game must be instant-on users often claim gifts and enter the game in a flow which leads them directly to a popup or a slot, which means that the moment load is done, the app must be in gear ready to go. is it possible to combine the framework rsls into a single file, and load it instead of the standard framework rsl's? So instead of loading 5 different rsls, I load a single optimized file that has only the classes needed for the app and its modules? The standard rsls come to 1.41MB and the difference in release is 0.58 MB... obviously I'm not using the majority of the flex code base... can I strip this down somehow? From: aha...@adobe.com To: dev@flex.apache.org Date: Tue, 3 Dec 2013 10:20:07 -0800 Subject: Re: SharedLibrary not works with SDK 4.11 Hi David, So you are saying that there is 566K in non-Flex code and assets to generate the first screen (after the preloader)? How much of that is assets and how much is code? And what Flex classes are used in that first screen? Usually, folks take a second after seeing the first screen before they act on it, and you can often do a bunch of downloading and initializing in that time. If you move everything not required for the first screen to a late-loaded module, you might find that the total framework load goes down and static linking becomes possible. That wouldn't be true for some app that has a DataGrid on the first screen, but I don't think I'm seeing heavyweight components on your first screen. -Alex On 12/3/13 6:41 AM, David Coleman david_coleman_...@hotmail.com wrote: http://apps.facebook.com/houseoffun/?fb_source=bookmark_appsref=bookmarks count=18fb_bmpos=3_18 the main file (for the upcoming version) is 566k, currently it is slightly over 600K, the assets are ~3 mb and i have implemented most popups as external modules, to ensure that they load from cdn only one time per session. The main application is a spark application. I use only simple objects, Group, List etc... nothing uber fancy. Most of the heavy lifting is done with AS3 for speed. We have a very large number of users. I can't statically link the libs because ppl expect the blinding fast load that I have achieved. 566K loads in the blink of an eye on even mediocre systems/connections. Personally I would prefer to statically link the framework because RSL's are yet another hit the browser has to make, but we need the users to get into the game and play as fast as possible. I have maintained the fastest load in our category on facebook for nearly a year now. :) I intend/need to keep it that way. so your short answer is a very big, yet very, very SMALL and optimized facebook app which is exactly why i have to use them :) Any way around this limitation would open the door for me to promote and fast-track the adoption of Apache Flex. I need small and I need fast. The rest is academic. Once I have the tools, I'll make it happen, and we will migrate to Apache Flex. Our target Flash Player version is 10.3 for maximum penetration. If there is any glimmer of hope to accomplish this... tell me, and let me know how I can help. From: aha...@adobe.com To: dev@flex.apache.org Date: Mon, 2 Dec 2013 11:22:26 -0800 Subject: Re: SharedLibrary not works with SDK 4.11 On 12/2/13 10:13 AM, David Coleman david_coleman_...@hotmail.com wrote: Having not tried this solution myself, this is pure speculation... but couldn't local storage store this? set domain to be * and retrieve it from the
RE: Test job - Build # 3 - Successful!
Did you receive build.zip attached with the email ? -Message d'origine- De : flex.muste...@gmail.com [mailto:flex.muste...@gmail.com] Envoyé : mardi 3 décembre 2013 21:04 À : comm...@flex.apache.org; jmcl...@apache.org Objet : Test job - Build # 3 - Successful! Test job - Build # 3 - Successful: Check console output at http://localhost:8080/job/Test%20job/3/ to view the results. (sent from ext-email)
Re: Test job - Build # 3 - Successful!
Yes, got it. There was a build.zip attachment with one file called log. Thanks, Om On Tue, Dec 3, 2013 at 12:05 PM, Maurice Amsellem maurice.amsel...@systar.com wrote: Did you receive build.zip attached with the email ? -Message d'origine- De : flex.muste...@gmail.com [mailto:flex.muste...@gmail.com] Envoyé : mardi 3 décembre 2013 21:04 À : comm...@flex.apache.org; jmcl...@apache.org Objet : Test job - Build # 3 - Successful! Test job - Build # 3 - Successful: Check console output at http://localhost:8080/job/Test%20job/3/ to view the results. (sent from ext-email)
Re: Test job - Build # 3 - Successful!
Adobe spam filters blocked it. It might be in the archives, but I haven't looked. On 12/3/13 12:05 PM, Maurice Amsellem maurice.amsel...@systar.com wrote: Did you receive build.zip attached with the email ? -Message d'origine- De : flex.muste...@gmail.com [mailto:flex.muste...@gmail.com] Envoyé : mardi 3 décembre 2013 21:04 À : comm...@flex.apache.org; jmcl...@apache.org Objet : Test job - Build # 3 - Successful! Test job - Build # 3 - Successful: Check console output at http://localhost:8080/job/Test%20job/3/ to view the results. (sent from ext-email)
RE: Test job - Build # 3 - Successful!
Too bad. -Message d'origine- De : Alex Harui [mailto:aha...@adobe.com] Envoyé : mardi 3 décembre 2013 21:08 À : dev@flex.apache.org; comm...@flex.apache.org; jmcl...@apache.org Objet : Re: Test job - Build # 3 - Successful! Adobe spam filters blocked it. It might be in the archives, but I haven't looked. On 12/3/13 12:05 PM, Maurice Amsellem maurice.amsel...@systar.com wrote: Did you receive build.zip attached with the email ? -Message d'origine- De : flex.muste...@gmail.com [mailto:flex.muste...@gmail.com] Envoyé : mardi 3 décembre 2013 21:04 À : comm...@flex.apache.org; jmcl...@apache.org Objet : Test job - Build # 3 - Successful! Test job - Build # 3 - Successful: Check console output at http://localhost:8080/job/Test%20job/3/ to view the results. (sent from ext-email)
Re: SharedLibrary not works with SDK 4.11
My educated guess on the size of such an app without using RSLs (depending on exactly which classes you're using) is about double your current size. That's still manageable. You can still use modules as you do today. Of course an issue is going to be all the modules. Every module gets bigger without using RSLs. Have you tried compiling without RSLs to see the actual difference in size? Harbs On Dec 3, 2013, at 4:41 PM, David Coleman wrote: http://apps.facebook.com/houseoffun/?fb_source=bookmark_appsref=bookmarkscount=18fb_bmpos=3_18 the main file (for the upcoming version) is 566k, currently it is slightly over 600K, the assets are ~3 mb and i have implemented most popups as external modules, to ensure that they load from cdn only one time per session. The main application is a spark application. I use only simple objects, Group, List etc... nothing uber fancy. Most of the heavy lifting is done with AS3 for speed. We have a very large number of users. I can't statically link the libs because ppl expect the blinding fast load that I have achieved. 566K loads in the blink of an eye on even mediocre systems/connections. Personally I would prefer to statically link the framework because RSL's are yet another hit the browser has to make, but we need the users to get into the game and play as fast as possible. I have maintained the fastest load in our category on facebook for nearly a year now. :) I intend/need to keep it that way. so your short answer is a very big, yet very, very SMALL and optimized facebook app which is exactly why i have to use them :) Any way around this limitation would open the door for me to promote and fast-track the adoption of Apache Flex. I need small and I need fast. The rest is academic. Once I have the tools, I'll make it happen, and we will migrate to Apache Flex. Our target Flash Player version is 10.3 for maximum penetration. If there is any glimmer of hope to accomplish this... tell me, and let me know how I can help. From: aha...@adobe.com To: dev@flex.apache.org Date: Mon, 2 Dec 2013 11:22:26 -0800 Subject: Re: SharedLibrary not works with SDK 4.11 On 12/2/13 10:13 AM, David Coleman david_coleman_...@hotmail.com wrote: Having not tried this solution myself, this is pure speculation... but couldn't local storage store this? set domain to be * and retrieve it from the public svn repo. if not present the RSL manager can load it up and in this way we can sign it with our own Cert and validate that cert independent of Adobe? Would this be workable? I think you'd hit local storage limits. RSL's are the only reason that I hesitate to migrate our Facebook app to apache. it will kill our CDN. Just curious: Have you actually measured the difference without RSLs? How big a Facebook app is this? -Alex
RE: Test job - Build # 3 - Successful!
Cool, Om. So now we will be able to analyze the full mustella build log without having to connect to the VM (in theory :-) That may be helpful. Maurice -Message d'origine- De : OmPrakash Muppirala [mailto:omup...@gmail.com] Envoyé : mardi 3 décembre 2013 21:07 À : dev@flex.apache.org Objet : Re: Test job - Build # 3 - Successful! Yes, got it. There was a build.zip attachment with one file called log. Thanks, Om On Tue, Dec 3, 2013 at 12:05 PM, Maurice Amsellem maurice.amsel...@systar.com wrote: Did you receive build.zip attached with the email ? -Message d'origine- De : flex.muste...@gmail.com [mailto:flex.muste...@gmail.com] Envoyé : mardi 3 décembre 2013 21:04 À : comm...@flex.apache.org; jmcl...@apache.org Objet : Test job - Build # 3 - Successful! Test job - Build # 3 - Successful: Check console output at http://localhost:8080/job/Test%20job/3/ to view the results. (sent from ext-email)
Re: Test job - Build # 3 - Successful!
Did you try to break the build and see if sends out an email with the log? That is the most important part :-) Thanks! Om On Tue, Dec 3, 2013 at 12:12 PM, Maurice Amsellem maurice.amsel...@systar.com wrote: Cool, Om. So now we will be able to analyze the full mustella build log without having to connect to the VM (in theory :-) That may be helpful. Maurice -Message d'origine- De : OmPrakash Muppirala [mailto:omup...@gmail.com] Envoyé : mardi 3 décembre 2013 21:07 À : dev@flex.apache.org Objet : Re: Test job - Build # 3 - Successful! Yes, got it. There was a build.zip attachment with one file called log. Thanks, Om On Tue, Dec 3, 2013 at 12:05 PM, Maurice Amsellem maurice.amsel...@systar.com wrote: Did you receive build.zip attached with the email ? -Message d'origine- De : flex.muste...@gmail.com [mailto:flex.muste...@gmail.com] Envoyé : mardi 3 décembre 2013 21:04 À : comm...@flex.apache.org; jmcl...@apache.org Objet : Test job - Build # 3 - Successful! Test job - Build # 3 - Successful: Check console output at http://localhost:8080/job/Test%20job/3/ to view the results. (sent from ext-email)
RE: Test job - Build # 3 - Successful!
The notifications rules are the following: Attach build log: ALWAYS ALWAYS SEND TO: Recipients - those listed in the recipients list at the project level (that is : comm...@flex.apache.org jmcl...@apache.org) Developers - those who made changes to the code Requestor - the person who initiated the build, if a person (not SCM polling or hook) Culprits - used in conjunction with Developers, gets the culprits from Jenkins itself rather than the changeset. flex-sdk-mustella tests is in failure, so we should know in 8hrs ... Maurice -Message d'origine- De : omup...@gmail.com [mailto:omup...@gmail.com] De la part de OmPrakash Muppirala Envoyé : mardi 3 décembre 2013 21:16 À : dev@flex.apache.org Objet : Re: Test job - Build # 3 - Successful! Did you try to break the build and see if sends out an email with the log? That is the most important part :-) Thanks! Om On Tue, Dec 3, 2013 at 12:12 PM, Maurice Amsellem maurice.amsel...@systar.com wrote: Cool, Om. So now we will be able to analyze the full mustella build log without having to connect to the VM (in theory :-) That may be helpful. Maurice -Message d'origine- De : OmPrakash Muppirala [mailto:omup...@gmail.com] Envoyé : mardi 3 décembre 2013 21:07 À : dev@flex.apache.org Objet : Re: Test job - Build # 3 - Successful! Yes, got it. There was a build.zip attachment with one file called log. Thanks, Om On Tue, Dec 3, 2013 at 12:05 PM, Maurice Amsellem maurice.amsel...@systar.com wrote: Did you receive build.zip attached with the email ? -Message d'origine- De : flex.muste...@gmail.com [mailto:flex.muste...@gmail.com] Envoyé : mardi 3 décembre 2013 21:04 À : comm...@flex.apache.org; jmcl...@apache.org Objet : Test job - Build # 3 - Successful! Test job - Build # 3 - Successful: Check console output at http://localhost:8080/job/Test%20job/3/ to view the results. (sent from ext-email)
Re: RE:SDK bug fixing in IntelliJ
Unfortunately increasing connection timeout didn't help. I tried atlasian plugin connector but got also 404. - Flex/Air developer open to new job offers and challenges. piotrzarzyck...@gmail.com -- View this message in context: http://apache-flex-development.247.n4.nabble.com/SDK-bug-fixing-in-IntelliJ-tp32653p32932.html Sent from the Apache Flex Development mailing list archive at Nabble.com.
RE: RE:SDK bug fixing in IntelliJ
I have set the connection timeout to 15000 ms. Lower than than it won't work -Message d'origine- De : piotr.zarzycki [mailto:piotrzarzyck...@gmail.com] Envoyé : mardi 3 décembre 2013 21:23 À : dev@flex.apache.org Objet : Re: RE:SDK bug fixing in IntelliJ Unfortunately increasing connection timeout didn't help. I tried atlasian plugin connector but got also 404. - Flex/Air developer open to new job offers and challenges. piotrzarzyck...@gmail.com -- View this message in context: http://apache-flex-development.247.n4.nabble.com/SDK-bug-fixing-in-IntelliJ-tp32653p32932.html Sent from the Apache Flex Development mailing list archive at Nabble.com.
RE: SharedLibrary not works with SDK 4.11
You are right. using static framework linkage balloons the modules beyond usefulness, easily double as you say, and sometimes more. Ideally, there would be a way for me to build a special optimized single file RSL, and use a third party software such as Kindi SecureSWF and sign it with my own certificate, and then include in that RSL all the core classes needed for everything, app, modules, etc... certainly the overhead for a 3rd party certificate would be minimal compared to the cost of linking the framework statically. And it would be nice to trim down the framework to the bare essentials. If i could hack the RSLs in this way then I could propose Apache Flex as being more secure and lower weight than a 4.5.1 sdk solution. Sure I would need to religiously maintain the contents of the FlexCore.swf RSL, but that's no big deal. perhaps i could even write some nifty tool that uses ant that scans all the unique classes used in the various link-report.xml's from the app and modules and then auto package this RSL at build time... I'm fully aware that this would be challenging... but I'm just trying to think of a way to be able to take our app into the future using Apache Flex. I don't want to be locked into 4.5.1 for the next 6 or more years of our application's projected life. That's the lazy way out. Subject: Re: SharedLibrary not works with SDK 4.11 From: harbs.li...@gmail.com Date: Tue, 3 Dec 2013 22:12:00 +0200 To: dev@flex.apache.org My educated guess on the size of such an app without using RSLs (depending on exactly which classes you're using) is about double your current size. That's still manageable. You can still use modules as you do today. Of course an issue is going to be all the modules. Every module gets bigger without using RSLs. Have you tried compiling without RSLs to see the actual difference in size? Harbs On Dec 3, 2013, at 4:41 PM, David Coleman wrote: http://apps.facebook.com/houseoffun/?fb_source=bookmark_appsref=bookmarkscount=18fb_bmpos=3_18 the main file (for the upcoming version) is 566k, currently it is slightly over 600K, the assets are ~3 mb and i have implemented most popups as external modules, to ensure that they load from cdn only one time per session. The main application is a spark application. I use only simple objects, Group, List etc... nothing uber fancy. Most of the heavy lifting is done with AS3 for speed. We have a very large number of users. I can't statically link the libs because ppl expect the blinding fast load that I have achieved. 566K loads in the blink of an eye on even mediocre systems/connections. Personally I would prefer to statically link the framework because RSL's are yet another hit the browser has to make, but we need the users to get into the game and play as fast as possible. I have maintained the fastest load in our category on facebook for nearly a year now. :) I intend/need to keep it that way. so your short answer is a very big, yet very, very SMALL and optimized facebook app which is exactly why i have to use them :) Any way around this limitation would open the door for me to promote and fast-track the adoption of Apache Flex. I need small and I need fast. The rest is academic. Once I have the tools, I'll make it happen, and we will migrate to Apache Flex. Our target Flash Player version is 10.3 for maximum penetration. If there is any glimmer of hope to accomplish this... tell me, and let me know how I can help. From: aha...@adobe.com To: dev@flex.apache.org Date: Mon, 2 Dec 2013 11:22:26 -0800 Subject: Re: SharedLibrary not works with SDK 4.11 On 12/2/13 10:13 AM, David Coleman david_coleman_...@hotmail.com wrote: Having not tried this solution myself, this is pure speculation... but couldn't local storage store this? set domain to be * and retrieve it from the public svn repo. if not present the RSL manager can load it up and in this way we can sign it with our own Cert and validate that cert independent of Adobe? Would this be workable? I think you'd hit local storage limits. RSL's are the only reason that I hesitate to migrate our Facebook app to apache. it will kill our CDN. Just curious: Have you actually measured the difference without RSLs? How big a Facebook app is this? -Alex
Re: SharedLibrary not works with SDK 4.11
Hi, Perhaps I missing the point but you can use framework RSLs with Apache Flex, however they will be cached by the users browser and may still be useful and give some advantages for an application that is used frequently, has high usage or with multiple application from the same domain. It's not going to be as good as the framework being cached by teh flash player but woudl still have some benefit. Can you do some A/B testing and see what the actual results would be for a small part of your users? There's not much point in signing RSLs as it was a Flash Player feature that signed the RSLs not a Flex SDK feature, the Flash Player would need to change in order to cache the Apache or user signed RSL and that's probably not possible. Thanks, Justin
RE: Updating Mustella jenkins VM
Hi, I am configuring the Mustella Jenkins VM notifications. Sorry for the burst of test notifications. I have launched manually mustella test and both flex-sdk-mustella-mobile / flex-sdk-mustella keep on failing with this error: Commencing build of Revision 905f8a551b58cf92b40ef194b0578412ed37f266 (origin/develop) Checking out Revision 905f8a551b58cf92b40ef194b0578412ed37f266 (origin/develop) FATAL: Could not checkout null with start point 905f8a551b58cf92b40ef194b0578412ed37f266 hudson.plugins.git.GitException: Could not checkout null with start point 905f8a551b58cf92b40ef194b0578412ed37f266 at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.checkoutBranch(CliGitAPIImpl.java:878) at hudson.plugins.git.GitSCM$4.invoke(GitSCM.java:1229) at hudson.plugins.git.GitSCM$4.invoke(GitSCM.java:1205) at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2387) at hudson.remoting.UserRequest.perform(UserRequest.java:118) at hudson.remoting.UserRequest.perform(UserRequest.java:48) at hudson.remoting.Request$2.run(Request.java:326) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:885) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907) at hudson.remoting.Engine$1$1.run(Engine.java:58) at java.lang.Thread.run(Thread.java:619) Caused by: hudson.plugins.git.GitException: Command C:\Program Files (x86)\Git\bin\git.exe checkout -f 905f8a551b58cf92b40ef194b0578412ed37f266 returned status code 1: stdout: stderr: error: unable to create file mustella/jenkins.sh (Permission denied) What's going on? Should wiping out the workspace clear the error or should I kill a pending process somewhere ? Maurice -Message d'origine- De : Erik de Bruin [mailto:e...@ixsoftware.nl] Envoyé : mardi 3 décembre 2013 07:55 À : dev@flex.apache.org Objet : Re: Updating Mustella jenkins VM Email account info is now on private@ EdB On Tue, Dec 3, 2013 at 12:28 AM, Maurice Amsellem maurice.amsel...@systar.com wrote: Hi, I would like to activate Email-ext plugin on Mustella Jenkins VM. This would allow us receiving more informed build reports notifications (such as build log in zip files). No objection ? PS: I will need the SMTP password to configure Email-ext. Regards Maurice Amsellem SYSTAR RD - BusinessBridgeFX -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl
Version 4.12 of Apache Flex
Hi, A new release of Apache Flex is a few months away what JIRA issues would you like to see fixed and what new features or improvments would you like to see? You can get an indication of progress by looking at the latest version of the release notes in GitHub. https://github.com/apache/flex-sdk/blob/develop/RELEASE_NOTES Thanks, Justin
Re: SharedLibrary not works with SDK 4.11
Apache Flex SDKs don't have signed RSLs that get separately cached by the Flash Player. Sure you can make your own RSLs and somehow hope it doesn't get booted from the browser cache, but I don't know why it would stay in the cache longer than a statically linked SWF. If you do turn on RSLs in Apache Flex SDKs, it should be smart about which RSLs get loaded and only load the ones you need and not all of them. Modules should not increase in size if statically linked unless they are using classes not used by the main app. And you can build shared code modules for your modules if needed. So, when considering Apache Flex, first realize that you must use the browser cache. My logic says, if you're going to use the browser cache, then RSLs won't help you (it would help if you are loading multiple applications from the same domain), so statically link your main SWF and then optimize it. If you were to use RSLs and the cache is missed then your total download would be much more than when statically linked, and if your one main SWF is in the cache, the fact that it is 600K bigger because it is statically linked shouldn't affect startup that much, if at all. Then, if you have one main SWF that is 500K of your own code, I'm still curious because that sounds like a lot to me. I haven't used FaceBook's libraries: how big is their Hello World app? And then, if a test of 500K+RSLs when all cached and a cached 1.1MB single SWF startup is the same, then you're back to optimizing startup. Of course, I could be missing something. -Alex On 12/3/13 12:52 PM, David Coleman david_coleman_...@hotmail.com wrote: You are right. using static framework linkage balloons the modules beyond usefulness, easily double as you say, and sometimes more. Ideally, there would be a way for me to build a special optimized single file RSL, and use a third party software such as Kindi SecureSWF and sign it with my own certificate, and then include in that RSL all the core classes needed for everything, app, modules, etc... certainly the overhead for a 3rd party certificate would be minimal compared to the cost of linking the framework statically. And it would be nice to trim down the framework to the bare essentials. If i could hack the RSLs in this way then I could propose Apache Flex as being more secure and lower weight than a 4.5.1 sdk solution. Sure I would need to religiously maintain the contents of the FlexCore.swf RSL, but that's no big deal. perhaps i could even write some nifty tool that uses ant that scans all the unique classes used in the various link-report.xml's from the app and modules and then auto package this RSL at build time... I'm fully aware that this would be challenging... but I'm just trying to think of a way to be able to take our app into the future using Apache Flex. I don't want to be locked into 4.5.1 for the next 6 or more years of our application's projected life. That's the lazy way out. Subject: Re: SharedLibrary not works with SDK 4.11 From: harbs.li...@gmail.com Date: Tue, 3 Dec 2013 22:12:00 +0200 To: dev@flex.apache.org My educated guess on the size of such an app without using RSLs (depending on exactly which classes you're using) is about double your current size. That's still manageable. You can still use modules as you do today. Of course an issue is going to be all the modules. Every module gets bigger without using RSLs. Have you tried compiling without RSLs to see the actual difference in size? Harbs On Dec 3, 2013, at 4:41 PM, David Coleman wrote: http://apps.facebook.com/houseoffun/?fb_source=bookmark_appsref=bookmark scount=18fb_bmpos=3_18 the main file (for the upcoming version) is 566k, currently it is slightly over 600K, the assets are ~3 mb and i have implemented most popups as external modules, to ensure that they load from cdn only one time per session. The main application is a spark application. I use only simple objects, Group, List etc... nothing uber fancy. Most of the heavy lifting is done with AS3 for speed. We have a very large number of users. I can't statically link the libs because ppl expect the blinding fast load that I have achieved. 566K loads in the blink of an eye on even mediocre systems/connections. Personally I would prefer to statically link the framework because RSL's are yet another hit the browser has to make, but we need the users to get into the game and play as fast as possible. I have maintained the fastest load in our category on facebook for nearly a year now. :) I intend/need to keep it that way. so your short answer is a very big, yet very, very SMALL and optimized facebook app which is exactly why i have to use them :) Any way around this limitation would open the door for me to promote and fast-track the adoption of Apache Flex. I need small and I need fast. The rest is
RE: SharedLibrary not works with SDK 4.11
The point is that WE have to host that extra file. Therefore I would want to eliminate the need for multiple RSL's and consolidate them into a single smaller optimized RSL with only the necessary classes needed for my app, with their dependencies. This would eliminate the need for every user generating 5n 301 hits against our CDN, where n==1+number of modules. When you are talking about an app with 1.5-2M MAU the cost of 5n 301's is considerable, and reducing that to n 301's is a significant benefit. Subject: Re: SharedLibrary not works with SDK 4.11 From: jus...@classsoftware.com Date: Wed, 4 Dec 2013 08:27:52 +1100 To: dev@flex.apache.org Hi, Perhaps I missing the point but you can use framework RSLs with Apache Flex, however they will be cached by the users browser and may still be useful and give some advantages for an application that is used frequently, has high usage or with multiple application from the same domain. It's not going to be as good as the framework being cached by teh flash player but woudl still have some benefit. Can you do some A/B testing and see what the actual results would be for a small part of your users? There's not much point in signing RSLs as it was a Flash Player feature that signed the RSLs not a Flex SDK feature, the Flash Player would need to change in order to cache the Apache or user signed RSL and that's probably not possible. Thanks, Justin
RE: SharedLibrary not works with SDK 4.11
Actually Alex, what is the biggest culprit in our file is Greensock, and after that, a whole mess of engine logic needed to handle the interface with the games. Also some of our legacy animations use Tweener, so for now I'm cursed with having to include BOTH libs in the main app. I also think that 500K is too much and like I said, each version I whittle it down a little more. I've often thought of loading the engine container as a module to remove another 100K or so from the main app. How would i create a custom RSL? Can I automate it via ant to generate it via the link-reports? I'd like to keep one RSL for ALL files, app, and modules to increase cache hits, and not hit a different file each time. I'm really curious to experiment with this. It's ok if the browser cache expires, that's beyond my control, but 99% of the time it will be a benefit - I'm ok with those numbers. From: aha...@adobe.com To: dev@flex.apache.org Date: Tue, 3 Dec 2013 14:27:56 -0800 Subject: Re: SharedLibrary not works with SDK 4.11 Apache Flex SDKs don't have signed RSLs that get separately cached by the Flash Player. Sure you can make your own RSLs and somehow hope it doesn't get booted from the browser cache, but I don't know why it would stay in the cache longer than a statically linked SWF. If you do turn on RSLs in Apache Flex SDKs, it should be smart about which RSLs get loaded and only load the ones you need and not all of them. Modules should not increase in size if statically linked unless they are using classes not used by the main app. And you can build shared code modules for your modules if needed. So, when considering Apache Flex, first realize that you must use the browser cache. My logic says, if you're going to use the browser cache, then RSLs won't help you (it would help if you are loading multiple applications from the same domain), so statically link your main SWF and then optimize it. If you were to use RSLs and the cache is missed then your total download would be much more than when statically linked, and if your one main SWF is in the cache, the fact that it is 600K bigger because it is statically linked shouldn't affect startup that much, if at all. Then, if you have one main SWF that is 500K of your own code, I'm still curious because that sounds like a lot to me. I haven't used FaceBook's libraries: how big is their Hello World app? And then, if a test of 500K+RSLs when all cached and a cached 1.1MB single SWF startup is the same, then you're back to optimizing startup. Of course, I could be missing something. -Alex On 12/3/13 12:52 PM, David Coleman david_coleman_...@hotmail.com wrote: You are right. using static framework linkage balloons the modules beyond usefulness, easily double as you say, and sometimes more. Ideally, there would be a way for me to build a special optimized single file RSL, and use a third party software such as Kindi SecureSWF and sign it with my own certificate, and then include in that RSL all the core classes needed for everything, app, modules, etc... certainly the overhead for a 3rd party certificate would be minimal compared to the cost of linking the framework statically. And it would be nice to trim down the framework to the bare essentials. If i could hack the RSLs in this way then I could propose Apache Flex as being more secure and lower weight than a 4.5.1 sdk solution. Sure I would need to religiously maintain the contents of the FlexCore.swf RSL, but that's no big deal. perhaps i could even write some nifty tool that uses ant that scans all the unique classes used in the various link-report.xml's from the app and modules and then auto package this RSL at build time... I'm fully aware that this would be challenging... but I'm just trying to think of a way to be able to take our app into the future using Apache Flex. I don't want to be locked into 4.5.1 for the next 6 or more years of our application's projected life. That's the lazy way out. Subject: Re: SharedLibrary not works with SDK 4.11 From: harbs.li...@gmail.com Date: Tue, 3 Dec 2013 22:12:00 +0200 To: dev@flex.apache.org My educated guess on the size of such an app without using RSLs (depending on exactly which classes you're using) is about double your current size. That's still manageable. You can still use modules as you do today. Of course an issue is going to be all the modules. Every module gets bigger without using RSLs. Have you tried compiling without RSLs to see the actual difference in size? Harbs On Dec 3, 2013, at 4:41 PM, David Coleman wrote: http://apps.facebook.com/houseoffun/?fb_source=bookmark_appsref=bookmark scount=18fb_bmpos=3_18 the main file (for the upcoming version) is 566k, currently it is slightly over 600K, the assets are ~3 mb and i have implemented most popups as external modules, to ensure that they load
Re: SharedLibrary not works with SDK 4.11
On 12/3/13 2:31 PM, David Coleman david_coleman_...@hotmail.com wrote: The point is that WE have to host that extra file. Therefore I would want to eliminate the need for multiple RSL's and consolidate them into a single smaller optimized RSL with only the necessary classes needed for my app, with their dependencies. OK, but my logic says that this custom RSL (because it won't be put in the special Flash Player cache) is just as likely to be missing from the browser cache as a single monolithic SWF. So maybe you should just build one monolithic SWF. Did you know you can package Flex Modules onto extra frames of a SWF? It makes your build process take longer, but then there isn't a hit per module. It might be one big SWF though. -Alex
Re: flex-sdk_mustella-air - Build # 388 - Successful!
Maurice, Can you please change the file name to log.txt instead of just log? Windows does not know how to open that file and I have to manually make it open in the text editor everytime. Thanks, Om On Tue, Dec 3, 2013 at 2:41 PM, flex.muste...@gmail.com wrote: flex-sdk_mustella-air - Build # 388 - Successful: Changes for Build #388 [...truncated 6011 lines...] [compc] Loading configuration file C:\jenkins_slave\workspace\flex-sdk_mustella-air\frameworks\projects\apache\bundle-config.xml [compc] C:\jenkins_slave\workspace\flex-sdk_mustella-air\frameworks\locale\de_DE\apache_rb.swc (2176 bytes) [echo] Compiling frameworks/locale/de_CH/apache_rb.swc [compc] Loading configuration file C:\jenkins_slave\workspace\flex-sdk_mustella-air\frameworks\projects\apache\bundle-config.xml [compc] C:\jenkins_slave\workspace\flex-sdk_mustella-air\frameworks\locale\de_CH\apache_rb.swc (2172 bytes) [echo] Compiling frameworks/locale/es_ES/apache_rb.swc [compc] Loading configuration file C:\jenkins_slave\workspace\flex-sdk_mustella-air\frameworks\projects\apache\bundle-config.xml [compc] C:\jenkins_slave\workspace\flex-sdk_mustella-air\frameworks\locale\es_ES\apache_rb.swc (2171 bytes) [echo] Compiling frameworks/locale/fi_FI/apache_rb.swc [compc] Loading configuration file C:\jenkins_slave\workspace\flex-sdk_mustella-air\frameworks\projects\apache\bundle-config.xml [compc] C:\jenkins_slave\workspace\flex-sdk_mustella-air\frameworks\locale\fi_FI\apache_rb.swc (2181 bytes) [echo] Compiling frameworks/locale/fr_CH/apache_rb.swc [compc] Loading configuration file C:\jenkins_slave\workspace\flex-sdk_mustella-air\frameworks\projects\apache\bundle-config.xml [compc] C:\jenkins_slave\workspace\flex-sdk_mustella-air\frameworks\locale\fr_CH\apache_rb.swc (2178 bytes) [echo] Compiling frameworks/locale/fr_FR/apache_rb.swc [compc] Loading configuration file C:\jenkins_slave\workspace\flex-sdk_mustella-air\frameworks\projects\apache\bundle-config.xml [compc] C:\jenkins_slave\workspace\flex-sdk_mustella-air\frameworks\locale\fr_FR\apache_rb.swc (2179 bytes) [echo] Compiling frameworks/locale/it_IT/apache_rb.swc [compc] Loading configuration file C:\jenkins_slave\workspace\flex-sdk_mustella-air\frameworks\projects\apache\bundle-config.xml [compc] C:\jenkins_slave\workspace\flex-sdk_mustella-air\frameworks\locale\it_IT\apache_rb.swc (2040 bytes) [echo] Compiling frameworks/locale/ja_JP/apache_rb.swc [compc] Loading configuration file C:\jenkins_slave\workspace\flex-sdk_mustella-air\frameworks\projects\apache\bundle-config.xml [compc] C:\jenkins_slave\workspace\flex-sdk_mustella-air\frameworks\locale\ja_JP\apache_rb.swc (2238 bytes) [echo] Compiling frameworks/locale/ko_KR/apache_rb.swc [compc] Loading configuration file C:\jenkins_slave\workspace\flex-sdk_mustella-air\frameworks\projects\apache\bundle-config.xml [compc] C:\jenkins_slave\workspace\flex-sdk_mustella-air\frameworks\locale\ko_KR\apache_rb.swc (2040 bytes) [echo] Compiling frameworks/locale/nb_NO/apache_rb.swc [compc] Loading configuration file C:\jenkins_slave\workspace\flex-sdk_mustella-air\frameworks\projects\apache\bundle-config.xml [compc] C:\jenkins_slave\workspace\flex-sdk_mustella-air\frameworks\locale\nb_NO\apache_rb.swc (2040 bytes) [echo] Compiling frameworks/locale/nl_NL/apache_rb.swc [compc] Loading configuration file C:\jenkins_slave\workspace\flex-sdk_mustella-air\frameworks\projects\apache\bundle-config.xml [compc] C:\jenkins_slave\workspace\flex-sdk_mustella-air\frameworks\locale\nl_NL\apache_rb.swc (2169 bytes) [echo] Compiling frameworks/locale/pt_BR/apache_rb.swc [compc] Loading configuration file C:\jenkins_slave\workspace\flex-sdk_mustella-air\frameworks\projects\apache\bundle-config.xml [compc] C:\jenkins_slave\workspace\flex-sdk_mustella-air\frameworks\locale\pt_BR\apache_rb.swc (2172 bytes) [echo] Compiling frameworks/locale/pt_PT/apache_rb.swc [compc] Loading configuration file C:\jenkins_slave\workspace\flex-sdk_mustella-air\frameworks\projects\apache\bundle-config.xml [compc] C:\jenkins_slave\workspace\flex-sdk_mustella-air\frameworks\locale\pt_PT\apache_rb.swc (2178 bytes) [echo] Compiling frameworks/locale/ru_RU/apache_rb.swc [compc] Loading configuration file C:\jenkins_slave\workspace\flex-sdk_mustella-air\frameworks\projects\apache\bundle-config.xml [compc] C:\jenkins_slave\workspace\flex-sdk_mustella-air\frameworks\locale\ru_RU\apache_rb.swc (2271 bytes) [echo] Compiling frameworks/locale/sv_SE/apache_rb.swc [compc] Loading configuration file C:\jenkins_slave\workspace\flex-sdk_mustella-air\frameworks\projects\apache\bundle-config.xml [compc] C:\jenkins_slave\workspace\flex-sdk_mustella-air\frameworks\locale\sv_SE\apache_rb.swc
Re: [DRAFT] Apache Flex December 2013 Report
On 12/3/13 2:38 PM, Justin Mclean jus...@classsoftware.com wrote: Hi, OK, but how does the PMC oust the current chair? The PMC would only have to oust the chair in extreme circumstances. I don't think the PMC actually can remove the chair as the chair is appointed by the board. In practise I would assume that the process would be that a PMC member (or more) would need to contact the board and ask for the chair to be replaced along with a very good reason. I'm wondering if the board really does appoint the char as much as approves the PMC recommendation. If we change chairs, we only provide notice and wait 72 hours. AFAIK, there is no action from the board required. This could just be another copy/paste problem of bad text like the term lazy majority. We can't require consensus in order to start a vote or else a power-hungry chair would just veto that attempt. A veto is not valid unless it's a good reason. Consensus is not required to start a vote but having an open discussion is certainly more beneficial and makes the vote more likely to succeed. I don't think a single PMC member should be able to start a vote either Why not and what's the alternative? Because there should be some discussion first. Ant is using 2/3 Majority in order to start a new vote. We don't say what kind of vote is going to be used to select a new chair either. The guidelines state it is Consensus Approval (ie 3+1 and no -1s) but that assumes only one candidate. Most other projects I've seen use single transferable vote voting ie number the candidates in the order you want. OK, I missed that earlier. So you think the language we have is clear enough? -Alex
RE: SharedLibrary not works with SDK 4.11
It saves us a great deal of time and resources when we have to release new art. We can break cache on the art asset module and not have to run a full QA regression on the main app. This gives us the flexibility as a company to deliver constantly changing content to our users w/o forcing them to download every file again, or dedicating our time and resources to QA of the application when we only want to change a single image in the game list. It is a logistical and political need as much as it is a technical decision to approach it this way. From: aha...@adobe.com To: dev@flex.apache.org Date: Tue, 3 Dec 2013 14:43:33 -0800 Subject: Re: SharedLibrary not works with SDK 4.11 On 12/3/13 2:38 PM, David Coleman david_coleman_...@hotmail.com wrote: Actually Alex, what is the biggest culprit in our file is Greensock, and after that, a whole mess of engine logic needed to handle the interface with the games. Also some of our legacy animations use Tweener, so for now I'm cursed with having to include BOTH libs in the main app. I also think that 500K is too much and like I said, each version I whittle it down a little more. I've often thought of loading the engine container as a module to remove another 100K or so from the main app. How would i create a custom RSL? Can I automate it via ant to generate it via the link-reports? I'd like to keep one RSL for ALL files, app, and modules to increase cache hits, and not hit a different file each time. I'm really curious to experiment with this. It's ok if the browser cache expires, that's beyond my control, but 99% of the time it will be a benefit - I'm ok with those numbers. I asked this in the other reply, but how will that save you over a single monolithic SWF? If you're not in the cache, then instead of loading two things, one of which may contain classes you don't need until later, you only load what you need when you need it. -Alex
Re: [DRAFT] Apache Flex December 2013 Report
On Tue, Dec 3, 2013 at 4:52 PM, Alex Harui aha...@adobe.com wrote: I'm wondering if the board really does appoint the char as much as approves the PMC recommendation. If we change chairs, we only provide notice and wait 72 hours. AFAIK, there is no action from the board required. This could just be another copy/paste problem of bad text like the term lazy majority. No the chair is appointed by resolution of the board. The original resolution that created the project named a chair and it requires another resolution to change the chair. The board normally does approve what the PMC recommends, but I have seen a case or two where the board intervened. Greg
RE: flex-sdk_mustella-air - Build # 388 - Successful!
I am sorry, Om, I am afraid I can't do that :-) The zip / log is built automatically by selecting an option Compress and Attach Build Log in ext- email. I have no control on the file attachment name, and I couldn't find any hidden option to change it. Maybe it should be possible to change the source of the plugin and recompile it, but I don't feel like I can do that... Maurice -Message d'origine- De : OmPrakash Muppirala [mailto:omup...@gmail.com] Envoyé : mardi 3 décembre 2013 23:48 À : dev@flex.apache.org Objet : Re: flex-sdk_mustella-air - Build # 388 - Successful! Maurice, Can you please change the file name to log.txt instead of just log? Windows does not know how to open that file and I have to manually make it open in the text editor everytime. Thanks, Om On Tue, Dec 3, 2013 at 2:41 PM, flex.muste...@gmail.com wrote: flex-sdk_mustella-air - Build # 388 - Successful: Changes for Build #388 [...truncated 6011 lines...] [compc] Loading configuration file C:\jenkins_slave\workspace\flex-sdk_mustella-air\frameworks\projects\apache\bundle-config.xml [compc] C:\jenkins_slave\workspace\flex-sdk_mustella-air\frameworks\locale\de_ DE\apache_rb.swc (2176 bytes) [echo] Compiling frameworks/locale/de_CH/apache_rb.swc [compc] Loading configuration file C:\jenkins_slave\workspace\flex-sdk_mustella-air\frameworks\projects\apache\bundle-config.xml [compc] C:\jenkins_slave\workspace\flex-sdk_mustella-air\frameworks\locale\de_ CH\apache_rb.swc (2172 bytes) [echo] Compiling frameworks/locale/es_ES/apache_rb.swc [compc] Loading configuration file C:\jenkins_slave\workspace\flex-sdk_mustella-air\frameworks\projects\apache\bundle-config.xml [compc] C:\jenkins_slave\workspace\flex-sdk_mustella-air\frameworks\locale\es_ ES\apache_rb.swc (2171 bytes) [echo] Compiling frameworks/locale/fi_FI/apache_rb.swc [compc] Loading configuration file C:\jenkins_slave\workspace\flex-sdk_mustella-air\frameworks\projects\apache\bundle-config.xml [compc] C:\jenkins_slave\workspace\flex-sdk_mustella-air\frameworks\locale\fi_ FI\apache_rb.swc (2181 bytes) [echo] Compiling frameworks/locale/fr_CH/apache_rb.swc [compc] Loading configuration file C:\jenkins_slave\workspace\flex-sdk_mustella-air\frameworks\projects\apache\bundle-config.xml [compc] C:\jenkins_slave\workspace\flex-sdk_mustella-air\frameworks\locale\fr_ CH\apache_rb.swc (2178 bytes) [echo] Compiling frameworks/locale/fr_FR/apache_rb.swc [compc] Loading configuration file C:\jenkins_slave\workspace\flex-sdk_mustella-air\frameworks\projects\apache\bundle-config.xml [compc] C:\jenkins_slave\workspace\flex-sdk_mustella-air\frameworks\locale\fr_ FR\apache_rb.swc (2179 bytes) [echo] Compiling frameworks/locale/it_IT/apache_rb.swc [compc] Loading configuration file C:\jenkins_slave\workspace\flex-sdk_mustella-air\frameworks\projects\apache\bundle-config.xml [compc] C:\jenkins_slave\workspace\flex-sdk_mustella-air\frameworks\locale\it_ IT\apache_rb.swc (2040 bytes) [echo] Compiling frameworks/locale/ja_JP/apache_rb.swc [compc] Loading configuration file C:\jenkins_slave\workspace\flex-sdk_mustella-air\frameworks\projects\apache\bundle-config.xml [compc] C:\jenkins_slave\workspace\flex-sdk_mustella-air\frameworks\locale\ja_ JP\apache_rb.swc (2238 bytes) [echo] Compiling frameworks/locale/ko_KR/apache_rb.swc [compc] Loading configuration file C:\jenkins_slave\workspace\flex-sdk_mustella-air\frameworks\projects\apache\bundle-config.xml [compc] C:\jenkins_slave\workspace\flex-sdk_mustella-air\frameworks\locale\ko_ KR\apache_rb.swc (2040 bytes) [echo] Compiling frameworks/locale/nb_NO/apache_rb.swc [compc] Loading configuration file C:\jenkins_slave\workspace\flex-sdk_mustella-air\frameworks\projects\apache\bundle-config.xml [compc] C:\jenkins_slave\workspace\flex-sdk_mustella-air\frameworks\locale\nb_ NO\apache_rb.swc (2040 bytes) [echo] Compiling frameworks/locale/nl_NL/apache_rb.swc [compc] Loading configuration file C:\jenkins_slave\workspace\flex-sdk_mustella-air\frameworks\projects\apache\bundle-config.xml [compc] C:\jenkins_slave\workspace\flex-sdk_mustella-air\frameworks\locale\nl_ NL\apache_rb.swc (2169 bytes) [echo] Compiling frameworks/locale/pt_BR/apache_rb.swc [compc] Loading configuration file C:\jenkins_slave\workspace\flex-sdk_mustella-air\frameworks\projects\apache\bundle-config.xml [compc] C:\jenkins_slave\workspace\flex-sdk_mustella-air\frameworks\locale\pt_ BR\apache_rb.swc (2172 bytes) [echo] Compiling frameworks/locale/pt_PT/apache_rb.swc [compc] Loading configuration file C:\jenkins_slave\workspace\flex-sdk_mustella-air\frameworks\projects\apache\bundle-config.xml [compc] C:\jenkins_slave\workspace\flex-sdk_mustella-air\frameworks\locale\pt_
RE: Updating Mustella jenkins VM
Alex, I understand the concern. I could change the config so that build logs are attached only upon failure, or maybe sent individually to change committers but not to commit list. The plugin is very flexible for that. On the other hand, the build logs compress very well ( 500 KB = 25 KB) because of all the redundancy. Maybe try with this configuration for a few days, and then I will change the notification rules if still requested. WDYT? Maurice -Message d'origine- De : Alex Harui [mailto:aha...@adobe.com] Envoyé : mardi 3 décembre 2013 23:57 À : dev@flex.apache.org Objet : Re: Updating Mustella jenkins VM I think having the logs will be very helpful, so thanks for doing that, but I'm wondering about our archives and all the folks who mirror our archives and whether these logs are worth archiving. Is there some other way? Stuffing the logs and/or zips into Git or SVN? Also, it turns out the whitelist doesn't affect the spam filter catching zip files. I will have to fish them out of the spam server if I need them. -Alex On 12/3/13 2:50 PM, Maurice Amsellem maurice.amsel...@systar.com wrote: It seems that the error below has disappeared (probably a ghost process that ended). Status: - flex-sdk_mustella-air - Build # 388 - Successful = sent notification with attached 26KB build log file (480KB unzipped) - flex-sdk_mustella-mobile #412 in progress - flex-sdk_mustella queued... If everything goes well, flex-sdk-mustella should fail and send a huge build log file with the email. Maurice -Message d'origine- De : Maurice Amsellem [mailto:maurice.amsel...@systar.com] Envoyé : mardi 3 décembre 2013 22:46 À : dev@flex.apache.org Objet : RE: Updating Mustella jenkins VM Hi, I am configuring the Mustella Jenkins VM notifications. Sorry for the burst of test notifications. I have launched manually mustella test and both flex-sdk-mustella-mobile / flex-sdk-mustella keep on failing with this error: Commencing build of Revision 905f8a551b58cf92b40ef194b0578412ed37f266 (origin/develop) Checking out Revision 905f8a551b58cf92b40ef194b0578412ed37f266 (origin/develop) FATAL: Could not checkout null with start point 905f8a551b58cf92b40ef194b0578412ed37f266 hudson.plugins.git.GitException: Could not checkout null with start point 905f8a551b58cf92b40ef194b0578412ed37f266 at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.checkoutBranch(CliGitAPII mpl .java:878) at hudson.plugins.git.GitSCM$4.invoke(GitSCM.java:1229) at hudson.plugins.git.GitSCM$4.invoke(GitSCM.java:1205) at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2387) at hudson.remoting.UserRequest.perform(UserRequest.java:118) at hudson.remoting.UserRequest.perform(UserRequest.java:48) at hudson.remoting.Request$2.run(Request.java:326) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutor Ser vice.java:72) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor. java:885) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.j ava :907) at hudson.remoting.Engine$1$1.run(Engine.java:58) at java.lang.Thread.run(Thread.java:619) Caused by: hudson.plugins.git.GitException: Command C:\Program Files (x86)\Git\bin\git.exe checkout -f 905f8a551b58cf92b40ef194b0578412ed37f266 returned status code 1: stdout: stderr: error: unable to create file mustella/jenkins.sh (Permission denied) What's going on? Should wiping out the workspace clear the error or should I kill a pending process somewhere ? Maurice -Message d'origine- De : Erik de Bruin [mailto:e...@ixsoftware.nl] Envoyé : mardi 3 décembre 2013 07:55 À : dev@flex.apache.org Objet : Re: Updating Mustella jenkins VM Email account info is now on private@ EdB On Tue, Dec 3, 2013 at 12:28 AM, Maurice Amsellem maurice.amsel...@systar.com wrote: Hi, I would like to activate Email-ext plugin on Mustella Jenkins VM. This would allow us receiving more informed build reports notifications (such as build log in zip files). No objection ? PS: I will need the SMTP password to configure Email-ext. Regards Maurice Amsellem SYSTAR RD - BusinessBridgeFX -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl
Re: SharedLibrary not works with SDK 4.11
OK, I didn't mean to include the asset module, but for all the code involved which you are currently pulling from the framework RSLs and then adding your own (plus Greensock and Tweener), how will making a single custom RSLs that may or may not be in the browser cache be better than a single SWF that contains all of the code? -Alex On 12/3/13 2:56 PM, David Coleman david_coleman_...@hotmail.com wrote: It saves us a great deal of time and resources when we have to release new art. We can break cache on the art asset module and not have to run a full QA regression on the main app. This gives us the flexibility as a company to deliver constantly changing content to our users w/o forcing them to download every file again, or dedicating our time and resources to QA of the application when we only want to change a single image in the game list. It is a logistical and political need as much as it is a technical decision to approach it this way. From: aha...@adobe.com To: dev@flex.apache.org Date: Tue, 3 Dec 2013 14:43:33 -0800 Subject: Re: SharedLibrary not works with SDK 4.11 On 12/3/13 2:38 PM, David Coleman david_coleman_...@hotmail.com wrote: Actually Alex, what is the biggest culprit in our file is Greensock, and after that, a whole mess of engine logic needed to handle the interface with the games. Also some of our legacy animations use Tweener, so for now I'm cursed with having to include BOTH libs in the main app. I also think that 500K is too much and like I said, each version I whittle it down a little more. I've often thought of loading the engine container as a module to remove another 100K or so from the main app. How would i create a custom RSL? Can I automate it via ant to generate it via the link-reports? I'd like to keep one RSL for ALL files, app, and modules to increase cache hits, and not hit a different file each time. I'm really curious to experiment with this. It's ok if the browser cache expires, that's beyond my control, but 99% of the time it will be a benefit - I'm ok with those numbers. I asked this in the other reply, but how will that save you over a single monolithic SWF? If you're not in the cache, then instead of loading two things, one of which may contain classes you don't need until later, you only load what you need when you need it. -Alex
RE: SharedLibrary not works with SDK 4.11
Upon re-reading this I realize that I didn't understand your question. What it will save us is that in the majority of instances, we will benefit from the cached RSL. And we will be able to still push smaller files so that NEW users do not see a jump in the time that it takes to open the app. Competition is high in this genre of games, and being the fastest to load is important. We won Best social Casino Product of 2013 this year. Maybe if we were not the fastest to load we might have still won. Maybe not. But we are. And I would hazard the guess that it played a role. Many ppl already HAVE the RSL's cached on their machines. I have to offset that benefit by minimizing as much as possible the hit that any Apache based solution would incur. As with any social game the first impression is the most important one. Especially with those who are disposed to spend real money. I know that TECHNICALLY there are many reasons to just link it statically and forget about it. But from a business perspective, every shred of speed that we can statistically extract from the app is worth it. I can't justify moving all the framework RSL's to our CDN and storing them in browser only cache instead of perpetual flash player storage. That's why I asked about local storage hacks. I CAN justify putting a SINGLE file on our CDN, if it means greater stability (ie: new SDK) and downloading a smaller amount of bytes than the 4.5.1 RSL's. a few bytes are big money when you are distributing them to a million ppl. Unfortunately, that's the reality of the business side of a social app. :( From: david_coleman_...@hotmail.com To: dev@flex.apache.org Subject: RE: SharedLibrary not works with SDK 4.11 Date: Tue, 3 Dec 2013 19:56:13 -0300 It saves us a great deal of time and resources when we have to release new art. We can break cache on the art asset module and not have to run a full QA regression on the main app. This gives us the flexibility as a company to deliver constantly changing content to our users w/o forcing them to download every file again, or dedicating our time and resources to QA of the application when we only want to change a single image in the game list. It is a logistical and political need as much as it is a technical decision to approach it this way. From: aha...@adobe.com To: dev@flex.apache.org Date: Tue, 3 Dec 2013 14:43:33 -0800 Subject: Re: SharedLibrary not works with SDK 4.11 On 12/3/13 2:38 PM, David Coleman david_coleman_...@hotmail.com wrote: Actually Alex, what is the biggest culprit in our file is Greensock, and after that, a whole mess of engine logic needed to handle the interface with the games. Also some of our legacy animations use Tweener, so for now I'm cursed with having to include BOTH libs in the main app. I also think that 500K is too much and like I said, each version I whittle it down a little more. I've often thought of loading the engine container as a module to remove another 100K or so from the main app. How would i create a custom RSL? Can I automate it via ant to generate it via the link-reports? I'd like to keep one RSL for ALL files, app, and modules to increase cache hits, and not hit a different file each time. I'm really curious to experiment with this. It's ok if the browser cache expires, that's beyond my control, but 99% of the time it will be a benefit - I'm ok with those numbers. I asked this in the other reply, but how will that save you over a single monolithic SWF? If you're not in the cache, then instead of loading two things, one of which may contain classes you don't need until later, you only load what you need when you need it. -Alex
RE: Updating Mustella jenkins VM
Also, it turns out the whitelist doesn't affect the spam filter catching zip files. I will have to fish them out of the spam server if I need them. Do you think it's filtered because it's a zip file, or because the file inside the zip log has no extension? Maurice -Message d'origine- De : Maurice Amsellem [mailto:maurice.amsel...@systar.com] Envoyé : mercredi 4 décembre 2013 00:05 À : dev@flex.apache.org Objet : RE: Updating Mustella jenkins VM Alex, I understand the concern. I could change the config so that build logs are attached only upon failure, or maybe sent individually to change committers but not to commit list. The plugin is very flexible for that. On the other hand, the build logs compress very well ( 500 KB = 25 KB) because of all the redundancy. Maybe try with this configuration for a few days, and then I will change the notification rules if still requested. WDYT? Maurice -Message d'origine- De : Alex Harui [mailto:aha...@adobe.com] Envoyé : mardi 3 décembre 2013 23:57 À : dev@flex.apache.org Objet : Re: Updating Mustella jenkins VM I think having the logs will be very helpful, so thanks for doing that, but I'm wondering about our archives and all the folks who mirror our archives and whether these logs are worth archiving. Is there some other way? Stuffing the logs and/or zips into Git or SVN? Also, it turns out the whitelist doesn't affect the spam filter catching zip files. I will have to fish them out of the spam server if I need them. -Alex On 12/3/13 2:50 PM, Maurice Amsellem maurice.amsel...@systar.com wrote: It seems that the error below has disappeared (probably a ghost process that ended). Status: - flex-sdk_mustella-air - Build # 388 - Successful = sent notification with attached 26KB build log file (480KB unzipped) - flex-sdk_mustella-mobile #412 in progress - flex-sdk_mustella queued... If everything goes well, flex-sdk-mustella should fail and send a huge build log file with the email. Maurice -Message d'origine- De : Maurice Amsellem [mailto:maurice.amsel...@systar.com] Envoyé : mardi 3 décembre 2013 22:46 À : dev@flex.apache.org Objet : RE: Updating Mustella jenkins VM Hi, I am configuring the Mustella Jenkins VM notifications. Sorry for the burst of test notifications. I have launched manually mustella test and both flex-sdk-mustella-mobile / flex-sdk-mustella keep on failing with this error: Commencing build of Revision 905f8a551b58cf92b40ef194b0578412ed37f266 (origin/develop) Checking out Revision 905f8a551b58cf92b40ef194b0578412ed37f266 (origin/develop) FATAL: Could not checkout null with start point 905f8a551b58cf92b40ef194b0578412ed37f266 hudson.plugins.git.GitException: Could not checkout null with start point 905f8a551b58cf92b40ef194b0578412ed37f266 at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.checkoutBranch(CliGitAPII mpl .java:878) at hudson.plugins.git.GitSCM$4.invoke(GitSCM.java:1229) at hudson.plugins.git.GitSCM$4.invoke(GitSCM.java:1205) at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2387) at hudson.remoting.UserRequest.perform(UserRequest.java:118) at hudson.remoting.UserRequest.perform(UserRequest.java:48) at hudson.remoting.Request$2.run(Request.java:326) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutor Ser vice.java:72) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor. java:885) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.j ava :907) at hudson.remoting.Engine$1$1.run(Engine.java:58) at java.lang.Thread.run(Thread.java:619) Caused by: hudson.plugins.git.GitException: Command C:\Program Files (x86)\Git\bin\git.exe checkout -f 905f8a551b58cf92b40ef194b0578412ed37f266 returned status code 1: stdout: stderr: error: unable to create file mustella/jenkins.sh (Permission denied) What's going on? Should wiping out the workspace clear the error or should I kill a pending process somewhere ? Maurice -Message d'origine- De : Erik de Bruin [mailto:e...@ixsoftware.nl] Envoyé : mardi 3 décembre 2013 07:55 À : dev@flex.apache.org Objet : Re: Updating Mustella jenkins VM Email account info is now on private@ EdB On Tue, Dec 3, 2013 at 12:28 AM, Maurice Amsellem maurice.amsel...@systar.com wrote: Hi, I would like to activate Email-ext plugin on Mustella Jenkins VM. This would allow us receiving more informed build reports notifications (such as build log in zip files). No objection ? PS: I will need the SMTP password to configure Email-ext. Regards Maurice Amsellem SYSTAR RD - BusinessBridgeFX -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl
RE: Updating Mustella jenkins VM
We already have a problem with folks wanting to unsubscribe. unsubscribe from the commits ML ? Maurice -Message d'origine- De : Alex Harui [mailto:aha...@adobe.com] Envoyé : mercredi 4 décembre 2013 00:16 À : dev@flex.apache.org Objet : Re: Updating Mustella jenkins VM Well, I know you put a lot of time into it, but I guess I'm suggesting that this is just going to create more noise for folks, even if you only attach on failure. If you see the kind of notices I get from the spam filter they aren't fun to look at. We already have a problem with folks wanting to unsubscribe. Couldn't the build script simply check in the log into one of our repos? Could we then include a link to the log file in SVN in the email? But sure, you can leave it as is until you get the energy to change it. -Alex On 12/3/13 3:04 PM, Maurice Amsellem maurice.amsel...@systar.com wrote: Alex, I understand the concern. I could change the config so that build logs are attached only upon failure, or maybe sent individually to change committers but not to commit list. The plugin is very flexible for that. On the other hand, the build logs compress very well ( 500 KB = 25 KB) because of all the redundancy. Maybe try with this configuration for a few days, and then I will change the notification rules if still requested. WDYT? Maurice -Message d'origine- De : Alex Harui [mailto:aha...@adobe.com] Envoyé : mardi 3 décembre 2013 23:57 À : dev@flex.apache.org Objet : Re: Updating Mustella jenkins VM I think having the logs will be very helpful, so thanks for doing that, but I'm wondering about our archives and all the folks who mirror our archives and whether these logs are worth archiving. Is there some other way? Stuffing the logs and/or zips into Git or SVN? Also, it turns out the whitelist doesn't affect the spam filter catching zip files. I will have to fish them out of the spam server if I need them. -Alex On 12/3/13 2:50 PM, Maurice Amsellem maurice.amsel...@systar.com wrote: It seems that the error below has disappeared (probably a ghost process that ended). Status: - flex-sdk_mustella-air - Build # 388 - Successful = sent notification with attached 26KB build log file (480KB unzipped) - flex-sdk_mustella-mobile #412 in progress - flex-sdk_mustella queued... If everything goes well, flex-sdk-mustella should fail and send a huge build log file with the email. Maurice -Message d'origine- De : Maurice Amsellem [mailto:maurice.amsel...@systar.com] Envoyé : mardi 3 décembre 2013 22:46 À : dev@flex.apache.org Objet : RE: Updating Mustella jenkins VM Hi, I am configuring the Mustella Jenkins VM notifications. Sorry for the burst of test notifications. I have launched manually mustella test and both flex-sdk-mustella-mobile / flex-sdk-mustella keep on failing with this error: Commencing build of Revision 905f8a551b58cf92b40ef194b0578412ed37f266 (origin/develop) Checking out Revision 905f8a551b58cf92b40ef194b0578412ed37f266 (origin/develop) FATAL: Could not checkout null with start point 905f8a551b58cf92b40ef194b0578412ed37f266 hudson.plugins.git.GitException: Could not checkout null with start point 905f8a551b58cf92b40ef194b0578412ed37f266 at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.checkoutBranch(CliGitAPI I mpl .java:878) at hudson.plugins.git.GitSCM$4.invoke(GitSCM.java:1229) at hudson.plugins.git.GitSCM$4.invoke(GitSCM.java:1205) at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2387) at hudson.remoting.UserRequest.perform(UserRequest.java:118) at hudson.remoting.UserRequest.perform(UserRequest.java:48) at hudson.remoting.Request$2.run(Request.java:326) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecuto r Ser vice.java:72) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecu tor . java:885) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor. j ava :907) at hudson.remoting.Engine$1$1.run(Engine.java:58) at java.lang.Thread.run(Thread.java:619) Caused by: hudson.plugins.git.GitException: Command C:\Program Files (x86)\Git\bin\git.exe checkout -f 905f8a551b58cf92b40ef194b0578412ed37f266 returned status code 1: stdout: stderr: error: unable to create file mustella/jenkins.sh (Permission denied) What's going on? Should wiping out the workspace clear the error or should I kill a pending process somewhere ? Maurice -Message d'origine- De : Erik de Bruin [mailto:e...@ixsoftware.nl] Envoyé : mardi 3 décembre 2013 07:55 À : dev@flex.apache.org Objet : Re: Updating Mustella jenkins VM Email account info is now on private@ EdB On Tue, Dec 3, 2013 at 12:28 AM, Maurice Amsellem maurice.amsel...@systar.com wrote: Hi, I would like to activate Email-ext plugin on
Re: Updating Mustella jenkins VM
On Tue, Dec 3, 2013 at 3:15 PM, Alex Harui aha...@adobe.com wrote: Well, I know you put a lot of time into it, but I guess I'm suggesting that this is just going to create more noise for folks, even if you only attach on failure. If you see the kind of notices I get from the spam filter they aren't fun to look at. We already have a problem with folks wanting to unsubscribe. Couldn't the build script simply check in the log into one of our repos? Could we then include a link to the log file in SVN in the email? But sure, you can leave it as is until you get the energy to change it. -Alex Some options we have in order of increasing desirability: 1. Send log file with every email notification 2. Send log file only with failure notifications 3. Check log file into git/svn and include link in the email 4. Expose the Jenkins instance on the Mustella VM to public (like builds.apache.org) I think option 4 is most desirable and shouldn't take a long time to implement. But option 1 or 2 should be good for now. Thanks, Om On 12/3/13 3:04 PM, Maurice Amsellem maurice.amsel...@systar.com wrote: Alex, I understand the concern. I could change the config so that build logs are attached only upon failure, or maybe sent individually to change committers but not to commit list. The plugin is very flexible for that. On the other hand, the build logs compress very well ( 500 KB = 25 KB) because of all the redundancy. Maybe try with this configuration for a few days, and then I will change the notification rules if still requested. WDYT? Maurice -Message d'origine- De : Alex Harui [mailto:aha...@adobe.com] Envoyé : mardi 3 décembre 2013 23:57 À : dev@flex.apache.org Objet : Re: Updating Mustella jenkins VM I think having the logs will be very helpful, so thanks for doing that, but I'm wondering about our archives and all the folks who mirror our archives and whether these logs are worth archiving. Is there some other way? Stuffing the logs and/or zips into Git or SVN? Also, it turns out the whitelist doesn't affect the spam filter catching zip files. I will have to fish them out of the spam server if I need them. -Alex On 12/3/13 2:50 PM, Maurice Amsellem maurice.amsel...@systar.com wrote: It seems that the error below has disappeared (probably a ghost process that ended). Status: - flex-sdk_mustella-air - Build # 388 - Successful = sent notification with attached 26KB build log file (480KB unzipped) - flex-sdk_mustella-mobile #412 in progress - flex-sdk_mustella queued... If everything goes well, flex-sdk-mustella should fail and send a huge build log file with the email. Maurice -Message d'origine- De : Maurice Amsellem [mailto:maurice.amsel...@systar.com] Envoyé : mardi 3 décembre 2013 22:46 À : dev@flex.apache.org Objet : RE: Updating Mustella jenkins VM Hi, I am configuring the Mustella Jenkins VM notifications. Sorry for the burst of test notifications. I have launched manually mustella test and both flex-sdk-mustella-mobile / flex-sdk-mustella keep on failing with this error: Commencing build of Revision 905f8a551b58cf92b40ef194b0578412ed37f266 (origin/develop) Checking out Revision 905f8a551b58cf92b40ef194b0578412ed37f266 (origin/develop) FATAL: Could not checkout null with start point 905f8a551b58cf92b40ef194b0578412ed37f266 hudson.plugins.git.GitException: Could not checkout null with start point 905f8a551b58cf92b40ef194b0578412ed37f266 at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.checkoutBranch(CliGitAPII mpl .java:878) at hudson.plugins.git.GitSCM$4.invoke(GitSCM.java:1229) at hudson.plugins.git.GitSCM$4.invoke(GitSCM.java:1205) at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2387) at hudson.remoting.UserRequest.perform(UserRequest.java:118) at hudson.remoting.UserRequest.perform(UserRequest.java:48) at hudson.remoting.Request$2.run(Request.java:326) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutor Ser vice.java:72) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor . java:885) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.j ava :907) at hudson.remoting.Engine$1$1.run(Engine.java:58) at java.lang.Thread.run(Thread.java:619) Caused by: hudson.plugins.git.GitException: Command C:\Program Files (x86)\Git\bin\git.exe checkout -f 905f8a551b58cf92b40ef194b0578412ed37f266 returned status code 1: stdout: stderr: error: unable to create file mustella/jenkins.sh (Permission denied) What's going on? Should wiping out the workspace clear the error or should I kill a pending process somewhere ? Maurice -Message d'origine- De : Erik
Re: Updating Mustella jenkins VM
I could be wrong, but I believe the first notification goes to commits@ but if we reply to that to discuss it, it goes to dev@ as well. -Alex On 12/3/13 3:21 PM, Maurice Amsellem maurice.amsel...@systar.com wrote: We already have a problem with folks wanting to unsubscribe. unsubscribe from the commits ML ? Maurice -Message d'origine- De : Alex Harui [mailto:aha...@adobe.com] Envoyé : mercredi 4 décembre 2013 00:16 À : dev@flex.apache.org Objet : Re: Updating Mustella jenkins VM Well, I know you put a lot of time into it, but I guess I'm suggesting that this is just going to create more noise for folks, even if you only attach on failure. If you see the kind of notices I get from the spam filter they aren't fun to look at. We already have a problem with folks wanting to unsubscribe. Couldn't the build script simply check in the log into one of our repos? Could we then include a link to the log file in SVN in the email? But sure, you can leave it as is until you get the energy to change it. -Alex On 12/3/13 3:04 PM, Maurice Amsellem maurice.amsel...@systar.com wrote: Alex, I understand the concern. I could change the config so that build logs are attached only upon failure, or maybe sent individually to change committers but not to commit list. The plugin is very flexible for that. On the other hand, the build logs compress very well ( 500 KB = 25 KB) because of all the redundancy. Maybe try with this configuration for a few days, and then I will change the notification rules if still requested. WDYT? Maurice -Message d'origine- De : Alex Harui [mailto:aha...@adobe.com] Envoyé : mardi 3 décembre 2013 23:57 À : dev@flex.apache.org Objet : Re: Updating Mustella jenkins VM I think having the logs will be very helpful, so thanks for doing that, but I'm wondering about our archives and all the folks who mirror our archives and whether these logs are worth archiving. Is there some other way? Stuffing the logs and/or zips into Git or SVN? Also, it turns out the whitelist doesn't affect the spam filter catching zip files. I will have to fish them out of the spam server if I need them. -Alex On 12/3/13 2:50 PM, Maurice Amsellem maurice.amsel...@systar.com wrote: It seems that the error below has disappeared (probably a ghost process that ended). Status: - flex-sdk_mustella-air - Build # 388 - Successful = sent notification with attached 26KB build log file (480KB unzipped) - flex-sdk_mustella-mobile #412 in progress - flex-sdk_mustella queued... If everything goes well, flex-sdk-mustella should fail and send a huge build log file with the email. Maurice -Message d'origine- De : Maurice Amsellem [mailto:maurice.amsel...@systar.com] Envoyé : mardi 3 décembre 2013 22:46 À : dev@flex.apache.org Objet : RE: Updating Mustella jenkins VM Hi, I am configuring the Mustella Jenkins VM notifications. Sorry for the burst of test notifications. I have launched manually mustella test and both flex-sdk-mustella-mobile / flex-sdk-mustella keep on failing with this error: Commencing build of Revision 905f8a551b58cf92b40ef194b0578412ed37f266 (origin/develop) Checking out Revision 905f8a551b58cf92b40ef194b0578412ed37f266 (origin/develop) FATAL: Could not checkout null with start point 905f8a551b58cf92b40ef194b0578412ed37f266 hudson.plugins.git.GitException: Could not checkout null with start point 905f8a551b58cf92b40ef194b0578412ed37f266 at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.checkoutBranch(CliGitAPI I mpl .java:878) at hudson.plugins.git.GitSCM$4.invoke(GitSCM.java:1229) at hudson.plugins.git.GitSCM$4.invoke(GitSCM.java:1205) at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2387) at hudson.remoting.UserRequest.perform(UserRequest.java:118) at hudson.remoting.UserRequest.perform(UserRequest.java:48) at hudson.remoting.Request$2.run(Request.java:326) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecuto r Ser vice.java:72) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecu tor . java:885) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor. j ava :907) at hudson.remoting.Engine$1$1.run(Engine.java:58) at java.lang.Thread.run(Thread.java:619) Caused by: hudson.plugins.git.GitException: Command C:\Program Files (x86)\Git\bin\git.exe checkout -f 905f8a551b58cf92b40ef194b0578412ed37f266 returned status code 1: stdout: stderr: error: unable to create file mustella/jenkins.sh (Permission denied) What's going on? Should wiping out the workspace clear the error or should I kill a pending process somewhere ? Maurice -Message d'origine- De : Erik de Bruin [mailto:e...@ixsoftware.nl] Envoyé : mardi 3 décembre 2013 07:55 À : dev@flex.apache.org Objet : Re: Updating Mustella jenkins VM Email
Re: FlexJS compiler support for FDT
OK, I think things are fixed again. The next nightly build should work better. -Alex On 12/3/13 10:34 AM, Alex Harui aha...@adobe.com wrote: Actually, I just synced up to the repo and am getting the same error. I think something has gotten broken on our side. On 12/3/13 3:58 AM, Erik de Bruin e...@ixsoftware.nl wrote: Hi, Good to hear you're working on this! Last week I greatly simplified the command line you need to successfully build a FlexJS project. We're working on getting the installer to create a 'one click FlexJS SDK' that will contain all dependencies except Java, but until that time it looks like you need to take only these 2 steps: 1) move your closure library from 'D:\NewSdks\closure-library-20130212' to 'D:\NewSdks\ApacheFlexJS\js\lib\google\closure-library' 2) use this command line: java -jar D:\NewSdks\ApacheFlexJS\js\lib\mxmlc.jar -load-config=D:\NewSdks\ApacheFlexJS\frameworks\flex-config.xml D:\TesTArea\TestProjects\DataBindingTest/src/DataBindingTest.mxml All other command line arguments are (should be...) either unneeded or will result in duplicate code warnings/errors. Thanks, EdB PS. the one warning after successful compilation (Data binding will not be able...) is expected and can be safely ignored. -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl
RE: Updating Mustella jenkins VM
Ok, I will turn off the log zip attachment. But really, I would have appreciated that you said this BEFORE I did it :-( :-( :-( Maurice -Message d'origine- De : omup...@gmail.com [mailto:omup...@gmail.com] De la part de OmPrakash Muppirala Envoyé : mercredi 4 décembre 2013 00:23 À : dev@flex.apache.org Objet : Re: Updating Mustella jenkins VM On Tue, Dec 3, 2013 at 3:15 PM, Alex Harui aha...@adobe.com wrote: Well, I know you put a lot of time into it, but I guess I'm suggesting that this is just going to create more noise for folks, even if you only attach on failure. If you see the kind of notices I get from the spam filter they aren't fun to look at. We already have a problem with folks wanting to unsubscribe. Couldn't the build script simply check in the log into one of our repos? Could we then include a link to the log file in SVN in the email? But sure, you can leave it as is until you get the energy to change it. -Alex Some options we have in order of increasing desirability: 1. Send log file with every email notification 2. Send log file only with failure notifications 3. Check log file into git/svn and include link in the email 4. Expose the Jenkins instance on the Mustella VM to public (like builds.apache.org) I think option 4 is most desirable and shouldn't take a long time to implement. But option 1 or 2 should be good for now. Thanks, Om On 12/3/13 3:04 PM, Maurice Amsellem maurice.amsel...@systar.com wrote: Alex, I understand the concern. I could change the config so that build logs are attached only upon failure, or maybe sent individually to change committers but not to commit list. The plugin is very flexible for that. On the other hand, the build logs compress very well ( 500 KB = 25 KB) because of all the redundancy. Maybe try with this configuration for a few days, and then I will change the notification rules if still requested. WDYT? Maurice -Message d'origine- De : Alex Harui [mailto:aha...@adobe.com] Envoyé : mardi 3 décembre 2013 23:57 À : dev@flex.apache.org Objet : Re: Updating Mustella jenkins VM I think having the logs will be very helpful, so thanks for doing that, but I'm wondering about our archives and all the folks who mirror our archives and whether these logs are worth archiving. Is there some other way? Stuffing the logs and/or zips into Git or SVN? Also, it turns out the whitelist doesn't affect the spam filter catching zip files. I will have to fish them out of the spam server if I need them. -Alex On 12/3/13 2:50 PM, Maurice Amsellem maurice.amsel...@systar.com wrote: It seems that the error below has disappeared (probably a ghost process that ended). Status: - flex-sdk_mustella-air - Build # 388 - Successful = sent notification with attached 26KB build log file (480KB unzipped) - flex-sdk_mustella-mobile #412 in progress - flex-sdk_mustella queued... If everything goes well, flex-sdk-mustella should fail and send a huge build log file with the email. Maurice -Message d'origine- De : Maurice Amsellem [mailto:maurice.amsel...@systar.com] Envoyé : mardi 3 décembre 2013 22:46 À : dev@flex.apache.org Objet : RE: Updating Mustella jenkins VM Hi, I am configuring the Mustella Jenkins VM notifications. Sorry for the burst of test notifications. I have launched manually mustella test and both flex-sdk-mustella-mobile / flex-sdk-mustella keep on failing with this error: Commencing build of Revision 905f8a551b58cf92b40ef194b0578412ed37f266 (origin/develop) Checking out Revision 905f8a551b58cf92b40ef194b0578412ed37f266 (origin/develop) FATAL: Could not checkout null with start point 905f8a551b58cf92b40ef194b0578412ed37f266 hudson.plugins.git.GitException: Could not checkout null with start point 905f8a551b58cf92b40ef194b0578412ed37f266 at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.checkoutBranch(CliGitA PII mpl .java:878) at hudson.plugins.git.GitSCM$4.invoke(GitSCM.java:1229) at hudson.plugins.git.GitSCM$4.invoke(GitSCM.java:1205) at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2387) at hudson.remoting.UserRequest.perform(UserRequest.java:118) at hudson.remoting.UserRequest.perform(UserRequest.java:48) at hudson.remoting.Request$2.run(Request.java:326) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecu tor Ser vice.java:72) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExe cutor . java:885) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecuto r.j ava :907) at hudson.remoting.Engine$1$1.run(Engine.java:58) at java.lang.Thread.run(Thread.java:619) Caused by:
Re: Updating Mustella jenkins VM
It didn't occur to me until just before I wrote it. But see my other reply. There's probably fewer folks on commits@ so I'll just live with it for a while and see if anyone else complains. -Alex On 12/3/13 3:32 PM, Maurice Amsellem maurice.amsel...@systar.com wrote: Ok, I will turn off the log zip attachment. But really, I would have appreciated that you said this BEFORE I did it :-( :-( :-( Maurice -Message d'origine- De : omup...@gmail.com [mailto:omup...@gmail.com] De la part de OmPrakash Muppirala Envoyé : mercredi 4 décembre 2013 00:23 À : dev@flex.apache.org Objet : Re: Updating Mustella jenkins VM On Tue, Dec 3, 2013 at 3:15 PM, Alex Harui aha...@adobe.com wrote: Well, I know you put a lot of time into it, but I guess I'm suggesting that this is just going to create more noise for folks, even if you only attach on failure. If you see the kind of notices I get from the spam filter they aren't fun to look at. We already have a problem with folks wanting to unsubscribe. Couldn't the build script simply check in the log into one of our repos? Could we then include a link to the log file in SVN in the email? But sure, you can leave it as is until you get the energy to change it. -Alex Some options we have in order of increasing desirability: 1. Send log file with every email notification 2. Send log file only with failure notifications 3. Check log file into git/svn and include link in the email 4. Expose the Jenkins instance on the Mustella VM to public (like builds.apache.org) I think option 4 is most desirable and shouldn't take a long time to implement. But option 1 or 2 should be good for now. Thanks, Om On 12/3/13 3:04 PM, Maurice Amsellem maurice.amsel...@systar.com wrote: Alex, I understand the concern. I could change the config so that build logs are attached only upon failure, or maybe sent individually to change committers but not to commit list. The plugin is very flexible for that. On the other hand, the build logs compress very well ( 500 KB = 25 KB) because of all the redundancy. Maybe try with this configuration for a few days, and then I will change the notification rules if still requested. WDYT? Maurice -Message d'origine- De : Alex Harui [mailto:aha...@adobe.com] Envoyé : mardi 3 décembre 2013 23:57 À : dev@flex.apache.org Objet : Re: Updating Mustella jenkins VM I think having the logs will be very helpful, so thanks for doing that, but I'm wondering about our archives and all the folks who mirror our archives and whether these logs are worth archiving. Is there some other way? Stuffing the logs and/or zips into Git or SVN? Also, it turns out the whitelist doesn't affect the spam filter catching zip files. I will have to fish them out of the spam server if I need them. -Alex On 12/3/13 2:50 PM, Maurice Amsellem maurice.amsel...@systar.com wrote: It seems that the error below has disappeared (probably a ghost process that ended). Status: - flex-sdk_mustella-air - Build # 388 - Successful = sent notification with attached 26KB build log file (480KB unzipped) - flex-sdk_mustella-mobile #412 in progress - flex-sdk_mustella queued... If everything goes well, flex-sdk-mustella should fail and send a huge build log file with the email. Maurice -Message d'origine- De : Maurice Amsellem [mailto:maurice.amsel...@systar.com] Envoyé : mardi 3 décembre 2013 22:46 À : dev@flex.apache.org Objet : RE: Updating Mustella jenkins VM Hi, I am configuring the Mustella Jenkins VM notifications. Sorry for the burst of test notifications. I have launched manually mustella test and both flex-sdk-mustella-mobile / flex-sdk-mustella keep on failing with this error: Commencing build of Revision 905f8a551b58cf92b40ef194b0578412ed37f266 (origin/develop) Checking out Revision 905f8a551b58cf92b40ef194b0578412ed37f266 (origin/develop) FATAL: Could not checkout null with start point 905f8a551b58cf92b40ef194b0578412ed37f266 hudson.plugins.git.GitException: Could not checkout null with start point 905f8a551b58cf92b40ef194b0578412ed37f266 at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.checkoutBranch(CliGitA PII mpl .java:878) at hudson.plugins.git.GitSCM$4.invoke(GitSCM.java:1229) at hudson.plugins.git.GitSCM$4.invoke(GitSCM.java:1205) at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2387) at hudson.remoting.UserRequest.perform(UserRequest.java:118) at hudson.remoting.UserRequest.perform(UserRequest.java:48) at hudson.remoting.Request$2.run(Request.java:326) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecu tor Ser vice.java:72) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExe cutor .
Re: Version 4.12 of Apache Flex
Thanks for the heads-up Justin. I'm hoping someone can please, please, please try to fix this issue, https://issues.apache.org/jira/browse/FLEX-33846 that I'm running into with spark datagrid. I think it should effect anyone using spark datagrids with mx:DividedBox. - Original Message - From: Justin Mclean jus...@classsoftware.com To: dev@flex.apache.org, us...@flex.apache.org Sent: Tuesday, December 3, 2013 2:12:08 PM Subject: Version 4.12 of Apache Flex Hi, A new release of Apache Flex is a few months away what JIRA issues would you like to see fixed and what new features or improvments would you like to see? You can get an indication of progress by looking at the latest version of the release notes in GitHub. https://github.com/apache/flex-sdk/blob/develop/RELEASE_NOTES Thanks, Justin
Re: Updating Mustella jenkins VM
Doh! Nevermind, the replies won't have the attachments. Ok, I think we'll be ok for a while, but I will find the spam server notices to very annoying. Thanks for doing it, -Alex On 12/3/13 3:24 PM, Alex Harui aha...@adobe.com wrote: I could be wrong, but I believe the first notification goes to commits@ but if we reply to that to discuss it, it goes to dev@ as well. -Alex On 12/3/13 3:21 PM, Maurice Amsellem maurice.amsel...@systar.com wrote: We already have a problem with folks wanting to unsubscribe. unsubscribe from the commits ML ? Maurice -Message d'origine- De : Alex Harui [mailto:aha...@adobe.com] Envoyé : mercredi 4 décembre 2013 00:16 À : dev@flex.apache.org Objet : Re: Updating Mustella jenkins VM Well, I know you put a lot of time into it, but I guess I'm suggesting that this is just going to create more noise for folks, even if you only attach on failure. If you see the kind of notices I get from the spam filter they aren't fun to look at. We already have a problem with folks wanting to unsubscribe. Couldn't the build script simply check in the log into one of our repos? Could we then include a link to the log file in SVN in the email? But sure, you can leave it as is until you get the energy to change it. -Alex On 12/3/13 3:04 PM, Maurice Amsellem maurice.amsel...@systar.com wrote: Alex, I understand the concern. I could change the config so that build logs are attached only upon failure, or maybe sent individually to change committers but not to commit list. The plugin is very flexible for that. On the other hand, the build logs compress very well ( 500 KB = 25 KB) because of all the redundancy. Maybe try with this configuration for a few days, and then I will change the notification rules if still requested. WDYT? Maurice -Message d'origine- De : Alex Harui [mailto:aha...@adobe.com] Envoyé : mardi 3 décembre 2013 23:57 À : dev@flex.apache.org Objet : Re: Updating Mustella jenkins VM I think having the logs will be very helpful, so thanks for doing that, but I'm wondering about our archives and all the folks who mirror our archives and whether these logs are worth archiving. Is there some other way? Stuffing the logs and/or zips into Git or SVN? Also, it turns out the whitelist doesn't affect the spam filter catching zip files. I will have to fish them out of the spam server if I need them. -Alex On 12/3/13 2:50 PM, Maurice Amsellem maurice.amsel...@systar.com wrote: It seems that the error below has disappeared (probably a ghost process that ended). Status: - flex-sdk_mustella-air - Build # 388 - Successful = sent notification with attached 26KB build log file (480KB unzipped) - flex-sdk_mustella-mobile #412 in progress - flex-sdk_mustella queued... If everything goes well, flex-sdk-mustella should fail and send a huge build log file with the email. Maurice -Message d'origine- De : Maurice Amsellem [mailto:maurice.amsel...@systar.com] Envoyé : mardi 3 décembre 2013 22:46 À : dev@flex.apache.org Objet : RE: Updating Mustella jenkins VM Hi, I am configuring the Mustella Jenkins VM notifications. Sorry for the burst of test notifications. I have launched manually mustella test and both flex-sdk-mustella-mobile / flex-sdk-mustella keep on failing with this error: Commencing build of Revision 905f8a551b58cf92b40ef194b0578412ed37f266 (origin/develop) Checking out Revision 905f8a551b58cf92b40ef194b0578412ed37f266 (origin/develop) FATAL: Could not checkout null with start point 905f8a551b58cf92b40ef194b0578412ed37f266 hudson.plugins.git.GitException: Could not checkout null with start point 905f8a551b58cf92b40ef194b0578412ed37f266 at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.checkoutBranch(CliGitAPI I mpl .java:878) at hudson.plugins.git.GitSCM$4.invoke(GitSCM.java:1229) at hudson.plugins.git.GitSCM$4.invoke(GitSCM.java:1205) at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2387) at hudson.remoting.UserRequest.perform(UserRequest.java:118) at hudson.remoting.UserRequest.perform(UserRequest.java:48) at hudson.remoting.Request$2.run(Request.java:326) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecuto r Ser vice.java:72) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecu tor . java:885) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor. j ava :907) at hudson.remoting.Engine$1$1.run(Engine.java:58) at java.lang.Thread.run(Thread.java:619) Caused by: hudson.plugins.git.GitException: Command C:\Program Files (x86)\Git\bin\git.exe checkout -f 905f8a551b58cf92b40ef194b0578412ed37f266 returned status code 1: stdout: stderr: error: unable to create file mustella/jenkins.sh (Permission denied) What's going on? Should wiping out the workspace clear the error or should I kill a
RE: Updating Mustella jenkins VM
Sorry. I already turned off the attachements. Anybody can turn them on back , if they wish: it's in the job configuration... Maurice -Message d'origine- De : Alex Harui [mailto:aha...@adobe.com] Envoyé : mercredi 4 décembre 2013 00:35 À : dev@flex.apache.org Objet : Re: Updating Mustella jenkins VM It didn't occur to me until just before I wrote it. But see my other reply. There's probably fewer folks on commits@ so I'll just live with it for a while and see if anyone else complains. -Alex On 12/3/13 3:32 PM, Maurice Amsellem maurice.amsel...@systar.com wrote: Ok, I will turn off the log zip attachment. But really, I would have appreciated that you said this BEFORE I did it :-( :-( :-( Maurice -Message d'origine- De : omup...@gmail.com [mailto:omup...@gmail.com] De la part de OmPrakash Muppirala Envoyé : mercredi 4 décembre 2013 00:23 À : dev@flex.apache.org Objet : Re: Updating Mustella jenkins VM On Tue, Dec 3, 2013 at 3:15 PM, Alex Harui aha...@adobe.com wrote: Well, I know you put a lot of time into it, but I guess I'm suggesting that this is just going to create more noise for folks, even if you only attach on failure. If you see the kind of notices I get from the spam filter they aren't fun to look at. We already have a problem with folks wanting to unsubscribe. Couldn't the build script simply check in the log into one of our repos? Could we then include a link to the log file in SVN in the email? But sure, you can leave it as is until you get the energy to change it. -Alex Some options we have in order of increasing desirability: 1. Send log file with every email notification 2. Send log file only with failure notifications 3. Check log file into git/svn and include link in the email 4. Expose the Jenkins instance on the Mustella VM to public (like builds.apache.org) I think option 4 is most desirable and shouldn't take a long time to implement. But option 1 or 2 should be good for now. Thanks, Om On 12/3/13 3:04 PM, Maurice Amsellem maurice.amsel...@systar.com wrote: Alex, I understand the concern. I could change the config so that build logs are attached only upon failure, or maybe sent individually to change committers but not to commit list. The plugin is very flexible for that. On the other hand, the build logs compress very well ( 500 KB = 25 KB) because of all the redundancy. Maybe try with this configuration for a few days, and then I will change the notification rules if still requested. WDYT? Maurice -Message d'origine- De : Alex Harui [mailto:aha...@adobe.com] Envoyé : mardi 3 décembre 2013 23:57 À : dev@flex.apache.org Objet : Re: Updating Mustella jenkins VM I think having the logs will be very helpful, so thanks for doing that, but I'm wondering about our archives and all the folks who mirror our archives and whether these logs are worth archiving. Is there some other way? Stuffing the logs and/or zips into Git or SVN? Also, it turns out the whitelist doesn't affect the spam filter catching zip files. I will have to fish them out of the spam server if I need them. -Alex On 12/3/13 2:50 PM, Maurice Amsellem maurice.amsel...@systar.com wrote: It seems that the error below has disappeared (probably a ghost process that ended). Status: - flex-sdk_mustella-air - Build # 388 - Successful = sent notification with attached 26KB build log file (480KB unzipped) - flex-sdk_mustella-mobile #412 in progress - flex-sdk_mustella queued... If everything goes well, flex-sdk-mustella should fail and send a huge build log file with the email. Maurice -Message d'origine- De : Maurice Amsellem [mailto:maurice.amsel...@systar.com] Envoyé : mardi 3 décembre 2013 22:46 À : dev@flex.apache.org Objet : RE: Updating Mustella jenkins VM Hi, I am configuring the Mustella Jenkins VM notifications. Sorry for the burst of test notifications. I have launched manually mustella test and both flex-sdk-mustella-mobile / flex-sdk-mustella keep on failing with this error: Commencing build of Revision 905f8a551b58cf92b40ef194b0578412ed37f266 (origin/develop) Checking out Revision 905f8a551b58cf92b40ef194b0578412ed37f266 (origin/develop) FATAL: Could not checkout null with start point 905f8a551b58cf92b40ef194b0578412ed37f266 hudson.plugins.git.GitException: Could not checkout null with start point 905f8a551b58cf92b40ef194b0578412ed37f266 at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.checkoutBranch(CliGit A PII mpl .java:878) at hudson.plugins.git.GitSCM$4.invoke(GitSCM.java:1229) at hudson.plugins.git.GitSCM$4.invoke(GitSCM.java:1205) at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2387) at hudson.remoting.UserRequest.perform(UserRequest.java:118) at hudson.remoting.UserRequest.perform(UserRequest.java:48) at
Re: Updating Mustella jenkins VM
Let us keep the log files attachments coming in until we make the Mustella VM publicly accessible. Alex, would that work for you? Thanks, Om On Tue, Dec 3, 2013 at 3:37 PM, Maurice Amsellem maurice.amsel...@systar.com wrote: Sorry. I already turned off the attachements. Anybody can turn them on back , if they wish: it's in the job configuration... Maurice -Message d'origine- De : Alex Harui [mailto:aha...@adobe.com] Envoyé : mercredi 4 décembre 2013 00:35 À : dev@flex.apache.org Objet : Re: Updating Mustella jenkins VM It didn't occur to me until just before I wrote it. But see my other reply. There's probably fewer folks on commits@ so I'll just live with it for a while and see if anyone else complains. -Alex On 12/3/13 3:32 PM, Maurice Amsellem maurice.amsel...@systar.com wrote: Ok, I will turn off the log zip attachment. But really, I would have appreciated that you said this BEFORE I did it :-( :-( :-( Maurice -Message d'origine- De : omup...@gmail.com [mailto:omup...@gmail.com] De la part de OmPrakash Muppirala Envoyé : mercredi 4 décembre 2013 00:23 À : dev@flex.apache.org Objet : Re: Updating Mustella jenkins VM On Tue, Dec 3, 2013 at 3:15 PM, Alex Harui aha...@adobe.com wrote: Well, I know you put a lot of time into it, but I guess I'm suggesting that this is just going to create more noise for folks, even if you only attach on failure. If you see the kind of notices I get from the spam filter they aren't fun to look at. We already have a problem with folks wanting to unsubscribe. Couldn't the build script simply check in the log into one of our repos? Could we then include a link to the log file in SVN in the email? But sure, you can leave it as is until you get the energy to change it. -Alex Some options we have in order of increasing desirability: 1. Send log file with every email notification 2. Send log file only with failure notifications 3. Check log file into git/svn and include link in the email 4. Expose the Jenkins instance on the Mustella VM to public (like builds.apache.org) I think option 4 is most desirable and shouldn't take a long time to implement. But option 1 or 2 should be good for now. Thanks, Om On 12/3/13 3:04 PM, Maurice Amsellem maurice.amsel...@systar.com wrote: Alex, I understand the concern. I could change the config so that build logs are attached only upon failure, or maybe sent individually to change committers but not to commit list. The plugin is very flexible for that. On the other hand, the build logs compress very well ( 500 KB = 25 KB) because of all the redundancy. Maybe try with this configuration for a few days, and then I will change the notification rules if still requested. WDYT? Maurice -Message d'origine- De : Alex Harui [mailto:aha...@adobe.com] Envoyé : mardi 3 décembre 2013 23:57 À : dev@flex.apache.org Objet : Re: Updating Mustella jenkins VM I think having the logs will be very helpful, so thanks for doing that, but I'm wondering about our archives and all the folks who mirror our archives and whether these logs are worth archiving. Is there some other way? Stuffing the logs and/or zips into Git or SVN? Also, it turns out the whitelist doesn't affect the spam filter catching zip files. I will have to fish them out of the spam server if I need them. -Alex On 12/3/13 2:50 PM, Maurice Amsellem maurice.amsel...@systar.com wrote: It seems that the error below has disappeared (probably a ghost process that ended). Status: - flex-sdk_mustella-air - Build # 388 - Successful = sent notification with attached 26KB build log file (480KB unzipped) - flex-sdk_mustella-mobile #412 in progress - flex-sdk_mustella queued... If everything goes well, flex-sdk-mustella should fail and send a huge build log file with the email. Maurice -Message d'origine- De : Maurice Amsellem [mailto:maurice.amsel...@systar.com] Envoyé : mardi 3 décembre 2013 22:46 À : dev@flex.apache.org Objet : RE: Updating Mustella jenkins VM Hi, I am configuring the Mustella Jenkins VM notifications. Sorry for the burst of test notifications. I have launched manually mustella test and both flex-sdk-mustella-mobile / flex-sdk-mustella keep on failing with this error: Commencing build of Revision 905f8a551b58cf92b40ef194b0578412ed37f266 (origin/develop) Checking out Revision 905f8a551b58cf92b40ef194b0578412ed37f266 (origin/develop) FATAL: Could not checkout null with start point 905f8a551b58cf92b40ef194b0578412ed37f266 hudson.plugins.git.GitException: Could not checkout null with start point 905f8a551b58cf92b40ef194b0578412ed37f266 at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.checkoutBranch(CliGit A PII mpl .java:878) at
Re: SharedLibrary not works with SDK 4.11
OK, so let me make sure I understand: For first time users, they have to download 3MB of Assets and the 600K SWF and hopefully not the 1.4MB's of framework RSLs. For returning users, 3MB Assets and 600K SWF is hopefully in the browser cache. If you switch to Apache Flex: First-time users will have to download either 1) 3MB of Assets, 600K of SWF and 1.4MB of RSLs from your CDN. 2) 3MB of Assets and 1.2MB of SWF if you statically link. So, Apache Flex statically linked is another 600K and represents an additional 12% in download time. I don't know what the RSL penetration is of Flex 4.5.1, but every day folks are buying new computers and there are fewer and fewer Flex 4.5.1 apps out there in the world so the probability your first-time customers will have those RSLs is diminishing. Over time, more and more of your customers will be downloading the 1.4MB of framework RSLs as well, and the statically linked solution will be the smaller download. Have you used ItDepends or a similar link-report analyzer to see how much of that 600K is Greensock, Tweener and other stuff? -Alex On 12/3/13 3:11 PM, David Coleman david_coleman_...@hotmail.com wrote: Upon re-reading this I realize that I didn't understand your question. What it will save us is that in the majority of instances, we will benefit from the cached RSL. And we will be able to still push smaller files so that NEW users do not see a jump in the time that it takes to open the app. Competition is high in this genre of games, and being the fastest to load is important. We won Best social Casino Product of 2013 this year. Maybe if we were not the fastest to load we might have still won. Maybe not. But we are. And I would hazard the guess that it played a role. Many ppl already HAVE the RSL's cached on their machines. I have to offset that benefit by minimizing as much as possible the hit that any Apache based solution would incur. As with any social game the first impression is the most important one. Especially with those who are disposed to spend real money. I know that TECHNICALLY there are many reasons to just link it statically and forget about it. But from a business perspective, every shred of speed that we can statistically extract from the app is worth it. I can't justify moving all the framework RSL's to our CDN and storing them in browser only cache instead of perpetual flash player storage. That's why I asked about local storage hacks. I CAN justify putting a SINGLE file on our CDN, if it means greater stability (ie: new SDK) and downloading a smaller amount of bytes than the 4.5.1 RSL's. a few bytes are big money when you are distributing them to a million ppl. Unfortunately, that's the reality of the business side of a social app. :( From: david_coleman_...@hotmail.com To: dev@flex.apache.org Subject: RE: SharedLibrary not works with SDK 4.11 Date: Tue, 3 Dec 2013 19:56:13 -0300 It saves us a great deal of time and resources when we have to release new art. We can break cache on the art asset module and not have to run a full QA regression on the main app. This gives us the flexibility as a company to deliver constantly changing content to our users w/o forcing them to download every file again, or dedicating our time and resources to QA of the application when we only want to change a single image in the game list. It is a logistical and political need as much as it is a technical decision to approach it this way. From: aha...@adobe.com To: dev@flex.apache.org Date: Tue, 3 Dec 2013 14:43:33 -0800 Subject: Re: SharedLibrary not works with SDK 4.11 On 12/3/13 2:38 PM, David Coleman david_coleman_...@hotmail.com wrote: Actually Alex, what is the biggest culprit in our file is Greensock, and after that, a whole mess of engine logic needed to handle the interface with the games. Also some of our legacy animations use Tweener, so for now I'm cursed with having to include BOTH libs in the main app. I also think that 500K is too much and like I said, each version I whittle it down a little more. I've often thought of loading the engine container as a module to remove another 100K or so from the main app. How would i create a custom RSL? Can I automate it via ant to generate it via the link-reports? I'd like to keep one RSL for ALL files, app, and modules to increase cache hits, and not hit a different file each time. I'm really curious to experiment with this. It's ok if the browser cache expires, that's beyond my control, but 99% of the time it will be a benefit - I'm ok with those numbers. I asked this in the other reply, but how will that save you over a single monolithic SWF? If you're not in the cache, then instead of loading two things, one of which may contain classes you don't need until later, you only load what you need when you need it. -Alex
Re: Updating Mustella jenkins VM
It will be annoying, but I can live with it. -Alex On 12/3/13 3:41 PM, OmPrakash Muppirala bigosma...@gmail.com wrote: Let us keep the log files attachments coming in until we make the Mustella VM publicly accessible. Alex, would that work for you? Thanks, Om On Tue, Dec 3, 2013 at 3:37 PM, Maurice Amsellem maurice.amsel...@systar.com wrote: Sorry. I already turned off the attachements. Anybody can turn them on back , if they wish: it's in the job configuration... Maurice -Message d'origine- De : Alex Harui [mailto:aha...@adobe.com] Envoyé : mercredi 4 décembre 2013 00:35 À : dev@flex.apache.org Objet : Re: Updating Mustella jenkins VM It didn't occur to me until just before I wrote it. But see my other reply. There's probably fewer folks on commits@ so I'll just live with it for a while and see if anyone else complains. -Alex On 12/3/13 3:32 PM, Maurice Amsellem maurice.amsel...@systar.com wrote: Ok, I will turn off the log zip attachment. But really, I would have appreciated that you said this BEFORE I did it :-( :-( :-( Maurice -Message d'origine- De : omup...@gmail.com [mailto:omup...@gmail.com] De la part de OmPrakash Muppirala Envoyé : mercredi 4 décembre 2013 00:23 À : dev@flex.apache.org Objet : Re: Updating Mustella jenkins VM On Tue, Dec 3, 2013 at 3:15 PM, Alex Harui aha...@adobe.com wrote: Well, I know you put a lot of time into it, but I guess I'm suggesting that this is just going to create more noise for folks, even if you only attach on failure. If you see the kind of notices I get from the spam filter they aren't fun to look at. We already have a problem with folks wanting to unsubscribe. Couldn't the build script simply check in the log into one of our repos? Could we then include a link to the log file in SVN in the email? But sure, you can leave it as is until you get the energy to change it. -Alex Some options we have in order of increasing desirability: 1. Send log file with every email notification 2. Send log file only with failure notifications 3. Check log file into git/svn and include link in the email 4. Expose the Jenkins instance on the Mustella VM to public (like builds.apache.org) I think option 4 is most desirable and shouldn't take a long time to implement. But option 1 or 2 should be good for now. Thanks, Om On 12/3/13 3:04 PM, Maurice Amsellem maurice.amsel...@systar.com wrote: Alex, I understand the concern. I could change the config so that build logs are attached only upon failure, or maybe sent individually to change committers but not to commit list. The plugin is very flexible for that. On the other hand, the build logs compress very well ( 500 KB = 25 KB) because of all the redundancy. Maybe try with this configuration for a few days, and then I will change the notification rules if still requested. WDYT? Maurice -Message d'origine- De : Alex Harui [mailto:aha...@adobe.com] Envoyé : mardi 3 décembre 2013 23:57 À : dev@flex.apache.org Objet : Re: Updating Mustella jenkins VM I think having the logs will be very helpful, so thanks for doing that, but I'm wondering about our archives and all the folks who mirror our archives and whether these logs are worth archiving. Is there some other way? Stuffing the logs and/or zips into Git or SVN? Also, it turns out the whitelist doesn't affect the spam filter catching zip files. I will have to fish them out of the spam server if I need them. -Alex On 12/3/13 2:50 PM, Maurice Amsellem maurice.amsel...@systar.com wrote: It seems that the error below has disappeared (probably a ghost process that ended). Status: - flex-sdk_mustella-air - Build # 388 - Successful = sent notification with attached 26KB build log file (480KB unzipped) - flex-sdk_mustella-mobile #412 in progress - flex-sdk_mustella queued... If everything goes well, flex-sdk-mustella should fail and send a huge build log file with the email. Maurice -Message d'origine- De : Maurice Amsellem [mailto:maurice.amsel...@systar.com] Envoyé : mardi 3 décembre 2013 22:46 À : dev@flex.apache.org Objet : RE: Updating Mustella jenkins VM Hi, I am configuring the Mustella Jenkins VM notifications. Sorry for the burst of test notifications. I have launched manually mustella test and both flex-sdk-mustella-mobile / flex-sdk-mustella keep on failing with this error: Commencing build of Revision 905f8a551b58cf92b40ef194b0578412ed37f266 (origin/develop) Checking out Revision 905f8a551b58cf92b40ef194b0578412ed37f266 (origin/develop) FATAL: Could not checkout null with start point 905f8a551b58cf92b40ef194b0578412ed37f266 hudson.plugins.git.GitException: Could not checkout null with start point 905f8a551b58cf92b40ef194b0578412ed37f266 at
Re: [DRAFT] Apache Flex December 2013 Report
Just to stir the pot a little more. Should we add to the guidelines a sort of calendar and every year we are required to review our by laws again. During that time we also have to acknowledge chair at least as far as keep / change? -Mark
Re: Updating Mustella jenkins VM
Thank you :-) Maurice, please go ahead and turn it on for now. If not, I can do it. Thanks for getting this working so far. I will try to find some time to work on making the VM publicly available soon. Regards, Om On Tue, Dec 3, 2013 at 3:52 PM, Alex Harui aha...@adobe.com wrote: It will be annoying, but I can live with it. -Alex On 12/3/13 3:41 PM, OmPrakash Muppirala bigosma...@gmail.com wrote: Let us keep the log files attachments coming in until we make the Mustella VM publicly accessible. Alex, would that work for you? Thanks, Om On Tue, Dec 3, 2013 at 3:37 PM, Maurice Amsellem maurice.amsel...@systar.com wrote: Sorry. I already turned off the attachements. Anybody can turn them on back , if they wish: it's in the job configuration... Maurice -Message d'origine- De : Alex Harui [mailto:aha...@adobe.com] Envoyé : mercredi 4 décembre 2013 00:35 À : dev@flex.apache.org Objet : Re: Updating Mustella jenkins VM It didn't occur to me until just before I wrote it. But see my other reply. There's probably fewer folks on commits@ so I'll just live with it for a while and see if anyone else complains. -Alex On 12/3/13 3:32 PM, Maurice Amsellem maurice.amsel...@systar.com wrote: Ok, I will turn off the log zip attachment. But really, I would have appreciated that you said this BEFORE I did it :-( :-( :-( Maurice -Message d'origine- De : omup...@gmail.com [mailto:omup...@gmail.com] De la part de OmPrakash Muppirala Envoyé : mercredi 4 décembre 2013 00:23 À : dev@flex.apache.org Objet : Re: Updating Mustella jenkins VM On Tue, Dec 3, 2013 at 3:15 PM, Alex Harui aha...@adobe.com wrote: Well, I know you put a lot of time into it, but I guess I'm suggesting that this is just going to create more noise for folks, even if you only attach on failure. If you see the kind of notices I get from the spam filter they aren't fun to look at. We already have a problem with folks wanting to unsubscribe. Couldn't the build script simply check in the log into one of our repos? Could we then include a link to the log file in SVN in the email? But sure, you can leave it as is until you get the energy to change it. -Alex Some options we have in order of increasing desirability: 1. Send log file with every email notification 2. Send log file only with failure notifications 3. Check log file into git/svn and include link in the email 4. Expose the Jenkins instance on the Mustella VM to public (like builds.apache.org) I think option 4 is most desirable and shouldn't take a long time to implement. But option 1 or 2 should be good for now. Thanks, Om On 12/3/13 3:04 PM, Maurice Amsellem maurice.amsel...@systar.com wrote: Alex, I understand the concern. I could change the config so that build logs are attached only upon failure, or maybe sent individually to change committers but not to commit list. The plugin is very flexible for that. On the other hand, the build logs compress very well ( 500 KB = 25 KB) because of all the redundancy. Maybe try with this configuration for a few days, and then I will change the notification rules if still requested. WDYT? Maurice -Message d'origine- De : Alex Harui [mailto:aha...@adobe.com] Envoyé : mardi 3 décembre 2013 23:57 À : dev@flex.apache.org Objet : Re: Updating Mustella jenkins VM I think having the logs will be very helpful, so thanks for doing that, but I'm wondering about our archives and all the folks who mirror our archives and whether these logs are worth archiving. Is there some other way? Stuffing the logs and/or zips into Git or SVN? Also, it turns out the whitelist doesn't affect the spam filter catching zip files. I will have to fish them out of the spam server if I need them. -Alex On 12/3/13 2:50 PM, Maurice Amsellem maurice.amsel...@systar.com wrote: It seems that the error below has disappeared (probably a ghost process that ended). Status: - flex-sdk_mustella-air - Build # 388 - Successful = sent notification with attached 26KB build log file (480KB unzipped) - flex-sdk_mustella-mobile #412 in progress - flex-sdk_mustella queued... If everything goes well, flex-sdk-mustella should fail and send a huge build log file with the email. Maurice -Message d'origine- De : Maurice Amsellem [mailto:maurice.amsel...@systar.com] Envoyé : mardi 3 décembre 2013 22:46 À : dev@flex.apache.org Objet : RE: Updating Mustella jenkins VM Hi, I am configuring the Mustella Jenkins VM notifications. Sorry for the burst of test notifications. I have launched manually mustella test and both flex-sdk-mustella-mobile / flex-sdk-mustella keep on
RE: Updating Mustella jenkins VM
Ok, I will turn it on. -Message d'origine- De : omup...@gmail.com [mailto:omup...@gmail.com] De la part de OmPrakash Muppirala Envoyé : mercredi 4 décembre 2013 00:56 À : dev@flex.apache.org Objet : Re: Updating Mustella jenkins VM Thank you :-) Maurice, please go ahead and turn it on for now. If not, I can do it. Thanks for getting this working so far. I will try to find some time to work on making the VM publicly available soon. Regards, Om On Tue, Dec 3, 2013 at 3:52 PM, Alex Harui aha...@adobe.com wrote: It will be annoying, but I can live with it. -Alex On 12/3/13 3:41 PM, OmPrakash Muppirala bigosma...@gmail.com wrote: Let us keep the log files attachments coming in until we make the Mustella VM publicly accessible. Alex, would that work for you? Thanks, Om On Tue, Dec 3, 2013 at 3:37 PM, Maurice Amsellem maurice.amsel...@systar.com wrote: Sorry. I already turned off the attachements. Anybody can turn them on back , if they wish: it's in the job configuration... Maurice -Message d'origine- De : Alex Harui [mailto:aha...@adobe.com] Envoyé : mercredi 4 décembre 2013 00:35 À : dev@flex.apache.org Objet : Re: Updating Mustella jenkins VM It didn't occur to me until just before I wrote it. But see my other reply. There's probably fewer folks on commits@ so I'll just live with it for a while and see if anyone else complains. -Alex On 12/3/13 3:32 PM, Maurice Amsellem maurice.amsel...@systar.com wrote: Ok, I will turn off the log zip attachment. But really, I would have appreciated that you said this BEFORE I did it :-( :-( :-( Maurice -Message d'origine- De : omup...@gmail.com [mailto:omup...@gmail.com] De la part de OmPrakash Muppirala Envoyé : mercredi 4 décembre 2013 00:23 À : dev@flex.apache.org Objet : Re: Updating Mustella jenkins VM On Tue, Dec 3, 2013 at 3:15 PM, Alex Harui aha...@adobe.com wrote: Well, I know you put a lot of time into it, but I guess I'm suggesting that this is just going to create more noise for folks, even if you only attach on failure. If you see the kind of notices I get from the spam filter they aren't fun to look at. We already have a problem with folks wanting to unsubscribe. Couldn't the build script simply check in the log into one of our repos? Could we then include a link to the log file in SVN in the email? But sure, you can leave it as is until you get the energy to change it. -Alex Some options we have in order of increasing desirability: 1. Send log file with every email notification 2. Send log file only with failure notifications 3. Check log file into git/svn and include link in the email 4. Expose the Jenkins instance on the Mustella VM to public (like builds.apache.org) I think option 4 is most desirable and shouldn't take a long time to implement. But option 1 or 2 should be good for now. Thanks, Om On 12/3/13 3:04 PM, Maurice Amsellem maurice.amsel...@systar.com wrote: Alex, I understand the concern. I could change the config so that build logs are attached only upon failure, or maybe sent individually to change committers but not to commit list. The plugin is very flexible for that. On the other hand, the build logs compress very well ( 500 KB = 25 KB) because of all the redundancy. Maybe try with this configuration for a few days, and then I will change the notification rules if still requested. WDYT? Maurice -Message d'origine- De : Alex Harui [mailto:aha...@adobe.com] Envoyé : mardi 3 décembre 2013 23:57 À : dev@flex.apache.org Objet : Re: Updating Mustella jenkins VM I think having the logs will be very helpful, so thanks for doing that, but I'm wondering about our archives and all the folks who mirror our archives and whether these logs are worth archiving. Is there some other way? Stuffing the logs and/or zips into Git or SVN? Also, it turns out the whitelist doesn't affect the spam filter catching zip files. I will have to fish them out of the spam server if I need them. -Alex On 12/3/13 2:50 PM, Maurice Amsellem maurice.amsel...@systar.com wrote: It seems that the error below has disappeared (probably a ghost process that ended). Status: - flex-sdk_mustella-air - Build # 388 - Successful = sent notification with attached 26KB build log file (480KB unzipped) - flex-sdk_mustella-mobile #412 in progress - flex-sdk_mustella queued... If everything goes well, flex-sdk-mustella should fail and send a huge build log file with the email. Maurice -Message d'origine- De : Maurice Amsellem [mailto:maurice.amsel...@systar.com] Envoyé : mardi 3 décembre
RE: SharedLibrary not works with SDK 4.11
I do agree with your numbers, (how could I not - they are spot on). The primary issue is that WE host the rsl or the static link difference. and the static link difference affects the size of our modules too. So it's 100% more for modules, and since we have 7.8 MB of modules (18 different popups each with animations/hd graphics etc), then we are talking about static linking costing a lot more. If i can customize an RSL to service all 18 modules and the main app and only have to distribute one file, that is even better for a new user than the Adobe RSL's... ok we have to pay for the CDN costs... but it's less than an extra 7.8 MB of static links for all our modules. Harbs pointed out the exact reason RSL is so critical to our use case. Modules are doubled. Now, if the modules could only statically link what is lacking in the static links of the main application, with out optimizing them and pushing all the embedded assets to the main application... kinda like a half-optimized module, then static link could really work for us. but as long as an optimized module will push all the assets into the main app, i can't optimize them to share the static links. so they need their own static links... Maybe this is something that can work! how can i optimize a module to share the static links of the main app without pushing all the embedded assets in the module to the main app? does mxmlc include a metatag to exclude a class (embedded asset) from module optimization? so it would stay in the module while i optimize it for the main app, and then only have to statically link the few bits and pieces that are lacking in each. From: aha...@adobe.com To: dev@flex.apache.org Date: Tue, 3 Dec 2013 15:51:44 -0800 Subject: Re: SharedLibrary not works with SDK 4.11 OK, so let me make sure I understand: For first time users, they have to download 3MB of Assets and the 600K SWF and hopefully not the 1.4MB's of framework RSLs. For returning users, 3MB Assets and 600K SWF is hopefully in the browser cache. If you switch to Apache Flex: First-time users will have to download either 1) 3MB of Assets, 600K of SWF and 1.4MB of RSLs from your CDN. 2) 3MB of Assets and 1.2MB of SWF if you statically link. So, Apache Flex statically linked is another 600K and represents an additional 12% in download time. I don't know what the RSL penetration is of Flex 4.5.1, but every day folks are buying new computers and there are fewer and fewer Flex 4.5.1 apps out there in the world so the probability your first-time customers will have those RSLs is diminishing. Over time, more and more of your customers will be downloading the 1.4MB of framework RSLs as well, and the statically linked solution will be the smaller download. Have you used ItDepends or a similar link-report analyzer to see how much of that 600K is Greensock, Tweener and other stuff? -Alex On 12/3/13 3:11 PM, David Coleman david_coleman_...@hotmail.com wrote: Upon re-reading this I realize that I didn't understand your question. What it will save us is that in the majority of instances, we will benefit from the cached RSL. And we will be able to still push smaller files so that NEW users do not see a jump in the time that it takes to open the app. Competition is high in this genre of games, and being the fastest to load is important. We won Best social Casino Product of 2013 this year. Maybe if we were not the fastest to load we might have still won. Maybe not. But we are. And I would hazard the guess that it played a role. Many ppl already HAVE the RSL's cached on their machines. I have to offset that benefit by minimizing as much as possible the hit that any Apache based solution would incur. As with any social game the first impression is the most important one. Especially with those who are disposed to spend real money. I know that TECHNICALLY there are many reasons to just link it statically and forget about it. But from a business perspective, every shred of speed that we can statistically extract from the app is worth it. I can't justify moving all the framework RSL's to our CDN and storing them in browser only cache instead of perpetual flash player storage. That's why I asked about local storage hacks. I CAN justify putting a SINGLE file on our CDN, if it means greater stability (ie: new SDK) and downloading a smaller amount of bytes than the 4.5.1 RSL's. a few bytes are big money when you are distributing them to a million ppl. Unfortunately, that's the reality of the business side of a social app. :( From: david_coleman_...@hotmail.com To: dev@flex.apache.org Subject: RE: SharedLibrary not works with SDK 4.11 Date: Tue, 3 Dec 2013 19:56:13 -0300 It saves us a great deal of time and resources when we have to release new art. We can break cache on the art asset module and not have to run a full QA regression on the main app. This
RE: Updating Mustella jenkins VM
What I could do, if you agree, is to have both the standard and the ext notifcations turned on: Standard notification: sends build summary, with no attachement, to commit ML Ext notification: send build summary + log attachement to change committers, excluding Alex. I will wait for your GO this time before proceeding. Alex, what email address (addresses) should I exclude ? Maurice -Message d'origine- De : Maurice Amsellem [mailto:maurice.amsel...@systar.com] Envoyé : mercredi 4 décembre 2013 01:05 À : dev@flex.apache.org Objet : RE: Updating Mustella jenkins VM Ok, I will turn it on. -Message d'origine- De : omup...@gmail.com [mailto:omup...@gmail.com] De la part de OmPrakash Muppirala Envoyé : mercredi 4 décembre 2013 00:56 À : dev@flex.apache.org Objet : Re: Updating Mustella jenkins VM Thank you :-) Maurice, please go ahead and turn it on for now. If not, I can do it. Thanks for getting this working so far. I will try to find some time to work on making the VM publicly available soon. Regards, Om On Tue, Dec 3, 2013 at 3:52 PM, Alex Harui aha...@adobe.com wrote: It will be annoying, but I can live with it. -Alex On 12/3/13 3:41 PM, OmPrakash Muppirala bigosma...@gmail.com wrote: Let us keep the log files attachments coming in until we make the Mustella VM publicly accessible. Alex, would that work for you? Thanks, Om On Tue, Dec 3, 2013 at 3:37 PM, Maurice Amsellem maurice.amsel...@systar.com wrote: Sorry. I already turned off the attachements. Anybody can turn them on back , if they wish: it's in the job configuration... Maurice -Message d'origine- De : Alex Harui [mailto:aha...@adobe.com] Envoyé : mercredi 4 décembre 2013 00:35 À : dev@flex.apache.org Objet : Re: Updating Mustella jenkins VM It didn't occur to me until just before I wrote it. But see my other reply. There's probably fewer folks on commits@ so I'll just live with it for a while and see if anyone else complains. -Alex On 12/3/13 3:32 PM, Maurice Amsellem maurice.amsel...@systar.com wrote: Ok, I will turn off the log zip attachment. But really, I would have appreciated that you said this BEFORE I did it :-( :-( :-( Maurice -Message d'origine- De : omup...@gmail.com [mailto:omup...@gmail.com] De la part de OmPrakash Muppirala Envoyé : mercredi 4 décembre 2013 00:23 À : dev@flex.apache.org Objet : Re: Updating Mustella jenkins VM On Tue, Dec 3, 2013 at 3:15 PM, Alex Harui aha...@adobe.com wrote: Well, I know you put a lot of time into it, but I guess I'm suggesting that this is just going to create more noise for folks, even if you only attach on failure. If you see the kind of notices I get from the spam filter they aren't fun to look at. We already have a problem with folks wanting to unsubscribe. Couldn't the build script simply check in the log into one of our repos? Could we then include a link to the log file in SVN in the email? But sure, you can leave it as is until you get the energy to change it. -Alex Some options we have in order of increasing desirability: 1. Send log file with every email notification 2. Send log file only with failure notifications 3. Check log file into git/svn and include link in the email 4. Expose the Jenkins instance on the Mustella VM to public (like builds.apache.org) I think option 4 is most desirable and shouldn't take a long time to implement. But option 1 or 2 should be good for now. Thanks, Om On 12/3/13 3:04 PM, Maurice Amsellem maurice.amsel...@systar.com wrote: Alex, I understand the concern. I could change the config so that build logs are attached only upon failure, or maybe sent individually to change committers but not to commit list. The plugin is very flexible for that. On the other hand, the build logs compress very well ( 500 KB = 25 KB) because of all the redundancy. Maybe try with this configuration for a few days, and then I will change the notification rules if still requested. WDYT? Maurice -Message d'origine- De : Alex Harui [mailto:aha...@adobe.com] Envoyé : mardi 3 décembre 2013 23:57 À : dev@flex.apache.org Objet : Re: Updating Mustella jenkins VM I think having the logs will be very helpful, so thanks for doing that, but I'm wondering about our archives and all the folks who mirror our archives and whether these logs are worth archiving. Is there some other way? Stuffing the logs and/or zips into Git or SVN? Also, it turns out the whitelist doesn't affect the spam filter catching zip files. I will have to fish them out of the spam server if I need them. -Alex On 12/3/13 2:50 PM, Maurice Amsellem maurice.amsel...@systar.com
Re: [DRAFT] Apache Flex December 2013 Report
Hi, Just to stir the pot a little more. Should we add to the guidelines a sort of calendar and every year we are required to review our by laws again. No need IMO they can be changed at any time and then voted in. Thanks, Justin
Re: Updating Mustella jenkins VM
Just send them. Someday I'll need to look at them. -Alex On 12/3/13 4:08 PM, Maurice Amsellem maurice.amsel...@systar.com wrote: What I could do, if you agree, is to have both the standard and the ext notifcations turned on: Standard notification: sends build summary, with no attachement, to commit ML Ext notification: send build summary + log attachement to change committers, excluding Alex. I will wait for your GO this time before proceeding. Alex, what email address (addresses) should I exclude ? Maurice -Message d'origine- De : Maurice Amsellem [mailto:maurice.amsel...@systar.com] Envoyé : mercredi 4 décembre 2013 01:05 À : dev@flex.apache.org Objet : RE: Updating Mustella jenkins VM Ok, I will turn it on. -Message d'origine- De : omup...@gmail.com [mailto:omup...@gmail.com] De la part de OmPrakash Muppirala Envoyé : mercredi 4 décembre 2013 00:56 À : dev@flex.apache.org Objet : Re: Updating Mustella jenkins VM Thank you :-) Maurice, please go ahead and turn it on for now. If not, I can do it. Thanks for getting this working so far. I will try to find some time to work on making the VM publicly available soon. Regards, Om On Tue, Dec 3, 2013 at 3:52 PM, Alex Harui aha...@adobe.com wrote: It will be annoying, but I can live with it. -Alex On 12/3/13 3:41 PM, OmPrakash Muppirala bigosma...@gmail.com wrote: Let us keep the log files attachments coming in until we make the Mustella VM publicly accessible. Alex, would that work for you? Thanks, Om On Tue, Dec 3, 2013 at 3:37 PM, Maurice Amsellem maurice.amsel...@systar.com wrote: Sorry. I already turned off the attachements. Anybody can turn them on back , if they wish: it's in the job configuration... Maurice -Message d'origine- De : Alex Harui [mailto:aha...@adobe.com] Envoyé : mercredi 4 décembre 2013 00:35 À : dev@flex.apache.org Objet : Re: Updating Mustella jenkins VM It didn't occur to me until just before I wrote it. But see my other reply. There's probably fewer folks on commits@ so I'll just live with it for a while and see if anyone else complains. -Alex On 12/3/13 3:32 PM, Maurice Amsellem maurice.amsel...@systar.com wrote: Ok, I will turn off the log zip attachment. But really, I would have appreciated that you said this BEFORE I did it :-( :-( :-( Maurice -Message d'origine- De : omup...@gmail.com [mailto:omup...@gmail.com] De la part de OmPrakash Muppirala Envoyé : mercredi 4 décembre 2013 00:23 À : dev@flex.apache.org Objet : Re: Updating Mustella jenkins VM On Tue, Dec 3, 2013 at 3:15 PM, Alex Harui aha...@adobe.com wrote: Well, I know you put a lot of time into it, but I guess I'm suggesting that this is just going to create more noise for folks, even if you only attach on failure. If you see the kind of notices I get from the spam filter they aren't fun to look at. We already have a problem with folks wanting to unsubscribe. Couldn't the build script simply check in the log into one of our repos? Could we then include a link to the log file in SVN in the email? But sure, you can leave it as is until you get the energy to change it. -Alex Some options we have in order of increasing desirability: 1. Send log file with every email notification 2. Send log file only with failure notifications 3. Check log file into git/svn and include link in the email 4. Expose the Jenkins instance on the Mustella VM to public (like builds.apache.org) I think option 4 is most desirable and shouldn't take a long time to implement. But option 1 or 2 should be good for now. Thanks, Om On 12/3/13 3:04 PM, Maurice Amsellem maurice.amsel...@systar.com wrote: Alex, I understand the concern. I could change the config so that build logs are attached only upon failure, or maybe sent individually to change committers but not to commit list. The plugin is very flexible for that. On the other hand, the build logs compress very well ( 500 KB = 25 KB) because of all the redundancy. Maybe try with this configuration for a few days, and then I will change the notification rules if still requested. WDYT? Maurice -Message d'origine- De : Alex Harui [mailto:aha...@adobe.com] Envoyé : mardi 3 décembre 2013 23:57 À : dev@flex.apache.org Objet : Re: Updating Mustella jenkins VM I think having the logs will be very helpful, so thanks for doing that, but I'm wondering about our archives and all the folks who mirror our archives and whether these logs are worth archiving. Is there some other way? Stuffing the logs and/or zips into Git or SVN? Also, it turns out the whitelist doesn't affect the spam filter catching zip files. I will have to fish them out of the spam server if I need them.
Re: SharedLibrary not works with SDK 4.11
I don't understand the part about embedded assets. Can you provide more details? The -externs option should let you keep any class out of any SWF. You can create a shared code module or pack other classes needed by modules onto extra frames of the main SWF. -Alex On 12/3/13 4:05 PM, David Coleman david_coleman_...@hotmail.com wrote: I do agree with your numbers, (how could I not - they are spot on). The primary issue is that WE host the rsl or the static link difference. and the static link difference affects the size of our modules too. So it's 100% more for modules, and since we have 7.8 MB of modules (18 different popups each with animations/hd graphics etc), then we are talking about static linking costing a lot more. If i can customize an RSL to service all 18 modules and the main app and only have to distribute one file, that is even better for a new user than the Adobe RSL's... ok we have to pay for the CDN costs... but it's less than an extra 7.8 MB of static links for all our modules. Harbs pointed out the exact reason RSL is so critical to our use case. Modules are doubled. Now, if the modules could only statically link what is lacking in the static links of the main application, with out optimizing them and pushing all the embedded assets to the main application... kinda like a half-optimized module, then static link could really work for us. but as long as an optimized module will push all the assets into the main app, i can't optimize them to share the static links. so they need their own static links... Maybe this is something that can work! how can i optimize a module to share the static links of the main app without pushing all the embedded assets in the module to the main app? does mxmlc include a metatag to exclude a class (embedded asset) from module optimization? so it would stay in the module while i optimize it for the main app, and then only have to statically link the few bits and pieces that are lacking in each. From: aha...@adobe.com To: dev@flex.apache.org Date: Tue, 3 Dec 2013 15:51:44 -0800 Subject: Re: SharedLibrary not works with SDK 4.11 OK, so let me make sure I understand: For first time users, they have to download 3MB of Assets and the 600K SWF and hopefully not the 1.4MB's of framework RSLs. For returning users, 3MB Assets and 600K SWF is hopefully in the browser cache. If you switch to Apache Flex: First-time users will have to download either 1) 3MB of Assets, 600K of SWF and 1.4MB of RSLs from your CDN. 2) 3MB of Assets and 1.2MB of SWF if you statically link. So, Apache Flex statically linked is another 600K and represents an additional 12% in download time. I don't know what the RSL penetration is of Flex 4.5.1, but every day folks are buying new computers and there are fewer and fewer Flex 4.5.1 apps out there in the world so the probability your first-time customers will have those RSLs is diminishing. Over time, more and more of your customers will be downloading the 1.4MB of framework RSLs as well, and the statically linked solution will be the smaller download. Have you used ItDepends or a similar link-report analyzer to see how much of that 600K is Greensock, Tweener and other stuff? -Alex On 12/3/13 3:11 PM, David Coleman david_coleman_...@hotmail.com wrote: Upon re-reading this I realize that I didn't understand your question. What it will save us is that in the majority of instances, we will benefit from the cached RSL. And we will be able to still push smaller files so that NEW users do not see a jump in the time that it takes to open the app. Competition is high in this genre of games, and being the fastest to load is important. We won Best social Casino Product of 2013 this year. Maybe if we were not the fastest to load we might have still won. Maybe not. But we are. And I would hazard the guess that it played a role. Many ppl already HAVE the RSL's cached on their machines. I have to offset that benefit by minimizing as much as possible the hit that any Apache based solution would incur. As with any social game the first impression is the most important one. Especially with those who are disposed to spend real money. I know that TECHNICALLY there are many reasons to just link it statically and forget about it. But from a business perspective, every shred of speed that we can statistically extract from the app is worth it. I can't justify moving all the framework RSL's to our CDN and storing them in browser only cache instead of perpetual flash player storage. That's why I asked about local storage hacks. I CAN justify putting a SINGLE file on our CDN, if it means greater stability (ie: new SDK) and downloading a smaller amount of bytes than the 4.5.1 RSL's. a few bytes are big money when you are distributing them to a million ppl. Unfortunately, that's the reality of the business side of a social app. :( From: david_coleman_...@hotmail.com
RE: SharedLibrary not works with SDK 4.11
For instance i have an app in flash builder with a boat load of modules I set one of these modules to be optimized for MyApp.mxml the embedded images in MyOptimizedModule end up in MyApp.mxml. The good thing is that MyApp and MyOptimizedModule can now be statically linked w/o doubling its size. the bad thing is that now I have defeated the purpose of putting my assets in the module. can I optimize a module for MyApp without all of its embedded assets ending up in the optimization target? It is my understanding that optimizing a module for a specific application ends up removing all embedded assets from the module and storing them in the application. If you want i can reproduce this in a few example projects and post it up on my git. From: aha...@adobe.com To: dev@flex.apache.org Date: Tue, 3 Dec 2013 17:19:06 -0800 Subject: Re: SharedLibrary not works with SDK 4.11 I don't understand the part about embedded assets. Can you provide more details? The -externs option should let you keep any class out of any SWF. You can create a shared code module or pack other classes needed by modules onto extra frames of the main SWF. -Alex On 12/3/13 4:05 PM, David Coleman david_coleman_...@hotmail.com wrote: I do agree with your numbers, (how could I not - they are spot on). The primary issue is that WE host the rsl or the static link difference. and the static link difference affects the size of our modules too. So it's 100% more for modules, and since we have 7.8 MB of modules (18 different popups each with animations/hd graphics etc), then we are talking about static linking costing a lot more. If i can customize an RSL to service all 18 modules and the main app and only have to distribute one file, that is even better for a new user than the Adobe RSL's... ok we have to pay for the CDN costs... but it's less than an extra 7.8 MB of static links for all our modules. Harbs pointed out the exact reason RSL is so critical to our use case. Modules are doubled. Now, if the modules could only statically link what is lacking in the static links of the main application, with out optimizing them and pushing all the embedded assets to the main application... kinda like a half-optimized module, then static link could really work for us. but as long as an optimized module will push all the assets into the main app, i can't optimize them to share the static links. so they need their own static links... Maybe this is something that can work! how can i optimize a module to share the static links of the main app without pushing all the embedded assets in the module to the main app? does mxmlc include a metatag to exclude a class (embedded asset) from module optimization? so it would stay in the module while i optimize it for the main app, and then only have to statically link the few bits and pieces that are lacking in each. From: aha...@adobe.com To: dev@flex.apache.org Date: Tue, 3 Dec 2013 15:51:44 -0800 Subject: Re: SharedLibrary not works with SDK 4.11 OK, so let me make sure I understand: For first time users, they have to download 3MB of Assets and the 600K SWF and hopefully not the 1.4MB's of framework RSLs. For returning users, 3MB Assets and 600K SWF is hopefully in the browser cache. If you switch to Apache Flex: First-time users will have to download either 1) 3MB of Assets, 600K of SWF and 1.4MB of RSLs from your CDN. 2) 3MB of Assets and 1.2MB of SWF if you statically link. So, Apache Flex statically linked is another 600K and represents an additional 12% in download time. I don't know what the RSL penetration is of Flex 4.5.1, but every day folks are buying new computers and there are fewer and fewer Flex 4.5.1 apps out there in the world so the probability your first-time customers will have those RSLs is diminishing. Over time, more and more of your customers will be downloading the 1.4MB of framework RSLs as well, and the statically linked solution will be the smaller download. Have you used ItDepends or a similar link-report analyzer to see how much of that 600K is Greensock, Tweener and other stuff? -Alex On 12/3/13 3:11 PM, David Coleman david_coleman_...@hotmail.com wrote: Upon re-reading this I realize that I didn't understand your question. What it will save us is that in the majority of instances, we will benefit from the cached RSL. And we will be able to still push smaller files so that NEW users do not see a jump in the time that it takes to open the app. Competition is high in this genre of games, and being the fastest to load is important. We won Best social Casino Product of 2013 this year. Maybe if we were not the fastest to load we might have still won. Maybe not. But we are. And I would hazard the guess that it played a role. Many ppl already HAVE the RSL's cached on their machines. I have to offset
Search in ADG
Hi, I have a Flex App where on several tabs (TabNavigator) I have MX AdvanceDataGrid's (wrapped in Spark Scroller's), which are dynamically populated (so I don't know in advance about 1/2 of Columns). Since the number of columns can be 200+, I am trying to implement a Search within Column Headers and data, one by one kind, so that when match is found, it highlights that cell or at least highlights that row and displays that column, brings it in user view. So far it shows that row, but I never was able to scroll to that column, so user can see it. I tried to use ADG's horizontalScrollPosition, verticalScrollPosition, validateNow with scrollToIndex,... When I try to set selectionMode=singleCell, that sometimes seem to freeze the app. Any advice or code snippet how to scroll to that matching Column? How to highlight the header and/or cell ? Can the problem be in that Scroller? Any help is very appreciated. -- Thank you in advance, Oleg.
Re: SharedLibrary not works with SDK 4.11
Wow. I don't think it is supposed to do that. Please create a simple test case and create a JIRA issue. -Alex On 12/3/13 5:53 PM, David Coleman david_coleman_...@hotmail.com wrote: For instance i have an app in flash builder with a boat load of modules I set one of these modules to be optimized for MyApp.mxml the embedded images in MyOptimizedModule end up in MyApp.mxml. The good thing is that MyApp and MyOptimizedModule can now be statically linked w/o doubling its size. the bad thing is that now I have defeated the purpose of putting my assets in the module. can I optimize a module for MyApp without all of its embedded assets ending up in the optimization target? It is my understanding that optimizing a module for a specific application ends up removing all embedded assets from the module and storing them in the application. If you want i can reproduce this in a few example projects and post it up on my git. From: aha...@adobe.com To: dev@flex.apache.org Date: Tue, 3 Dec 2013 17:19:06 -0800 Subject: Re: SharedLibrary not works with SDK 4.11 I don't understand the part about embedded assets. Can you provide more details? The -externs option should let you keep any class out of any SWF. You can create a shared code module or pack other classes needed by modules onto extra frames of the main SWF. -Alex On 12/3/13 4:05 PM, David Coleman david_coleman_...@hotmail.com wrote: I do agree with your numbers, (how could I not - they are spot on). The primary issue is that WE host the rsl or the static link difference. and the static link difference affects the size of our modules too. So it's 100% more for modules, and since we have 7.8 MB of modules (18 different popups each with animations/hd graphics etc), then we are talking about static linking costing a lot more. If i can customize an RSL to service all 18 modules and the main app and only have to distribute one file, that is even better for a new user than the Adobe RSL's... ok we have to pay for the CDN costs... but it's less than an extra 7.8 MB of static links for all our modules. Harbs pointed out the exact reason RSL is so critical to our use case. Modules are doubled. Now, if the modules could only statically link what is lacking in the static links of the main application, with out optimizing them and pushing all the embedded assets to the main application... kinda like a half-optimized module, then static link could really work for us. but as long as an optimized module will push all the assets into the main app, i can't optimize them to share the static links. so they need their own static links... Maybe this is something that can work! how can i optimize a module to share the static links of the main app without pushing all the embedded assets in the module to the main app? does mxmlc include a metatag to exclude a class (embedded asset) from module optimization? so it would stay in the module while i optimize it for the main app, and then only have to statically link the few bits and pieces that are lacking in each. From: aha...@adobe.com To: dev@flex.apache.org Date: Tue, 3 Dec 2013 15:51:44 -0800 Subject: Re: SharedLibrary not works with SDK 4.11 OK, so let me make sure I understand: For first time users, they have to download 3MB of Assets and the 600K SWF and hopefully not the 1.4MB's of framework RSLs. For returning users, 3MB Assets and 600K SWF is hopefully in the browser cache. If you switch to Apache Flex: First-time users will have to download either 1) 3MB of Assets, 600K of SWF and 1.4MB of RSLs from your CDN. 2) 3MB of Assets and 1.2MB of SWF if you statically link. So, Apache Flex statically linked is another 600K and represents an additional 12% in download time. I don't know what the RSL penetration is of Flex 4.5.1, but every day folks are buying new computers and there are fewer and fewer Flex 4.5.1 apps out there in the world so the probability your first-time customers will have those RSLs is diminishing. Over time, more and more of your customers will be downloading the 1.4MB of framework RSLs as well, and the statically linked solution will be the smaller download. Have you used ItDepends or a similar link-report analyzer to see how much of that 600K is Greensock, Tweener and other stuff? -Alex On 12/3/13 3:11 PM, David Coleman david_coleman_...@hotmail.com wrote: Upon re-reading this I realize that I didn't understand your question. What it will save us is that in the majority of instances, we will benefit from the cached RSL. And we will be able to still push smaller files so that NEW users do not see a jump in the time that it takes to open the app. Competition is high in this genre of games, and being the fastest to load is important. We won Best social Casino Product of 2013 this year. Maybe if we were not the fastest to load we might
Re: Search in ADG
After you scrollToIndex, if you set horizontalScrollPosition, does anything happen? And then if you read back horizontalScrollPosition, is it non-zero? -Alex On 12/3/13 6:40 PM, Oleg Konovalov oleg...@gmail.com wrote: Hi, I have a Flex App where on several tabs (TabNavigator) I have MX AdvanceDataGrid's (wrapped in Spark Scroller's), which are dynamically populated (so I don't know in advance about 1/2 of Columns). Since the number of columns can be 200+, I am trying to implement a Search within Column Headers and data, one by one kind, so that when match is found, it highlights that cell or at least highlights that row and displays that column, brings it in user view. So far it shows that row, but I never was able to scroll to that column, so user can see it. I tried to use ADG's horizontalScrollPosition, verticalScrollPosition, validateNow with scrollToIndex,... When I try to set selectionMode=singleCell, that sometimes seem to freeze the app. Any advice or code snippet how to scroll to that matching Column? How to highlight the header and/or cell ? Can the problem be in that Scroller? Any help is very appreciated. -- Thank you in advance, Oleg.
[DRAFT 2] Apache Flex December 2013 Report
OK, here is draft 2. I added a section about donations. Nick, I'm not sure what you saw that was wrong with the URLs in trademarks, but I copy/pasted them again to be sure. I'll file this Wednesday late morning. -Alex - Apache Flex is an application framework for easily building Flash-based applications for mobile devices, the browser and desktop. RELEASES Apache Flex SDK 4.11.0 was released on 10/28/13. Apache Flex Installer 2.7.0 was also released on 10/28/13. ACTIVITY Activity in Apache Flex continues to be in two main areas: improvements To the existing Adobe Flash Platform-dependent code base, including the releases listed above, and prototyping ways to create a version of Flex that is independent from the Adobe Flash Platform. There is another group working on Maven-related tools for the existing code base. In the past three months we've seen: - Continued JIRA activity (more bugs raised than resolved however) - More folks contributing and eventually becoming committers. Other highlights: -Over 60 bugs were fixed in 4.11.0. -We adopted a set of guidelines/by-laws. They are on our wiki at: https://cwiki.apache.org/confluence/display/FLEX/Guidelines Code Donation Update -FlexUnit was donated but has yet to be formulated into a release. -Swiz donation is still pending. The donator has not filed the paperwork. -BlazeDS donation paperwork was submitted but the code is not yet in the repo because it was discovered that some pieces were missing. We hope to get the missing pieces before the next report, maybe even by end of year. COMMUNITY -Stephan Plath added as committer on 11/17/13. -Cosma Colanicchia added as committer on 10/17/13. -Tom Chiverton added as a committer on 9/30/13. -Maurice Amsellem added as a committer on 9/28/13. -Darrell Loverin added as a committer on 9/13/13. -Maurice Amsellem promoted from committer to PMC on 11/9/13. -Latest analytics include over 3000 hits per day on the website during the work week (less on weekends). -There were more than 3000 installs of 4.11.0 in the month since its release. AREAS OF CONCERN (FROM LAST REPORT) -RELEASE EFFORT: In the last report we reported that getting a release out seems more difficult than it should be because folks don't start serious testing on the first RCs so important bugs are found just before the VOTE ends and another RC has to be made. For the 4.11 release, we adopted carry-over voting based on a suggestion from a board member. If there were minor changes to the release artifacts, you could carry over your vote from the prior release candidate. That, and I think just having more experience in cutting releases made the 4.11 release go much more smoothly. -NUMBER OF ACTIVE COMMITTERS: In the last report we reported that even though 200 bugs were fixed in 4.10.0, the majority were done by one committer. Over the past 3 months, six new people made contributions and were voted in as committers. TRADEMARKS -It was discovered that an external entity was using http://apacheflex.com to redirect to their web site. They were notified and have changed the redirect to the Apache Flex website. They have offered to have Apache take over the domain http://apacheflex.com. We need to figure out how to do this. -It looks like the new version of Flex is going to be called FlexJS. We need to find out if we need to trademark that name. We will be contacting trademarks@ shortly. INFRASTRUCTURE * I'm still hoping to find time to resolve INFRA-4380 (attachments in old Flex bugs).
RE: Updating Mustella jenkins VM
Done (log attached again) -Message d'origine- De : Alex Harui [mailto:aha...@adobe.com] Envoyé : mercredi 4 décembre 2013 02:14 À : dev@flex.apache.org Objet : Re: Updating Mustella jenkins VM Just send them. Someday I'll need to look at them. -Alex On 12/3/13 4:08 PM, Maurice Amsellem maurice.amsel...@systar.com wrote: What I could do, if you agree, is to have both the standard and the ext notifcations turned on: Standard notification: sends build summary, with no attachement, to commit ML Ext notification: send build summary + log attachement to change committers, excluding Alex. I will wait for your GO this time before proceeding. Alex, what email address (addresses) should I exclude ? Maurice -Message d'origine- De : Maurice Amsellem [mailto:maurice.amsel...@systar.com] Envoyé : mercredi 4 décembre 2013 01:05 À : dev@flex.apache.org Objet : RE: Updating Mustella jenkins VM Ok, I will turn it on. -Message d'origine- De : omup...@gmail.com [mailto:omup...@gmail.com] De la part de OmPrakash Muppirala Envoyé : mercredi 4 décembre 2013 00:56 À : dev@flex.apache.org Objet : Re: Updating Mustella jenkins VM Thank you :-) Maurice, please go ahead and turn it on for now. If not, I can do it. Thanks for getting this working so far. I will try to find some time to work on making the VM publicly available soon. Regards, Om On Tue, Dec 3, 2013 at 3:52 PM, Alex Harui aha...@adobe.com wrote: It will be annoying, but I can live with it. -Alex On 12/3/13 3:41 PM, OmPrakash Muppirala bigosma...@gmail.com wrote: Let us keep the log files attachments coming in until we make the Mustella VM publicly accessible. Alex, would that work for you? Thanks, Om On Tue, Dec 3, 2013 at 3:37 PM, Maurice Amsellem maurice.amsel...@systar.com wrote: Sorry. I already turned off the attachements. Anybody can turn them on back , if they wish: it's in the job configuration... Maurice -Message d'origine- De : Alex Harui [mailto:aha...@adobe.com] Envoyé : mercredi 4 décembre 2013 00:35 À : dev@flex.apache.org Objet : Re: Updating Mustella jenkins VM It didn't occur to me until just before I wrote it. But see my other reply. There's probably fewer folks on commits@ so I'll just live with it for a while and see if anyone else complains. -Alex On 12/3/13 3:32 PM, Maurice Amsellem maurice.amsel...@systar.com wrote: Ok, I will turn off the log zip attachment. But really, I would have appreciated that you said this BEFORE I did it :-( :-( :-( Maurice -Message d'origine- De : omup...@gmail.com [mailto:omup...@gmail.com] De la part de OmPrakash Muppirala Envoyé : mercredi 4 décembre 2013 00:23 À : dev@flex.apache.org Objet : Re: Updating Mustella jenkins VM On Tue, Dec 3, 2013 at 3:15 PM, Alex Harui aha...@adobe.com wrote: Well, I know you put a lot of time into it, but I guess I'm suggesting that this is just going to create more noise for folks, even if you only attach on failure. If you see the kind of notices I get from the spam filter they aren't fun to look at. We already have a problem with folks wanting to unsubscribe. Couldn't the build script simply check in the log into one of our repos? Could we then include a link to the log file in SVN in the email? But sure, you can leave it as is until you get the energy to change it. -Alex Some options we have in order of increasing desirability: 1. Send log file with every email notification 2. Send log file only with failure notifications 3. Check log file into git/svn and include link in the email 4. Expose the Jenkins instance on the Mustella VM to public (like builds.apache.org) I think option 4 is most desirable and shouldn't take a long time to implement. But option 1 or 2 should be good for now. Thanks, Om On 12/3/13 3:04 PM, Maurice Amsellem maurice.amsel...@systar.com wrote: Alex, I understand the concern. I could change the config so that build logs are attached only upon failure, or maybe sent individually to change committers but not to commit list. The plugin is very flexible for that. On the other hand, the build logs compress very well ( 500 KB = 25 KB) because of all the redundancy. Maybe try with this configuration for a few days, and then I will change the notification rules if still requested. WDYT? Maurice -Message d'origine- De : Alex Harui [mailto:aha...@adobe.com] Envoyé : mardi 3 décembre 2013 23:57 À : dev@flex.apache.org Objet : Re: Updating Mustella jenkins VM I think having the logs will be very helpful, so thanks for doing that, but I'm wondering about our archives and all the folks who mirror our archives and whether these logs are worth archiving. Is there
RE: Search in ADG
Also, set ADG.scrollHorizontalPolicy to on, then simply calling ADG. horizontalScrollPosition = column Index will do the trick. -Message d'origine- De : Maurice Amsellem Envoyé : mercredi 4 décembre 2013 08:36 À : 'dev@flex.apache.org'; flex-...@incubator.apache.org; flex-users-subscr...@incubator.apache.org Objet : RE: Search in ADG MX components manage scrolling internally, Spark Scroller is used for spark skins only. So yes, you should remove it -Message d'origine- De : Oleg Konovalov [mailto:oleg...@gmail.com] Envoyé : mercredi 4 décembre 2013 03:40 À : flex-...@incubator.apache.org; flex-users-subscr...@incubator.apache.org Objet : Search in ADG Hi, I have a Flex App where on several tabs (TabNavigator) I have MX AdvanceDataGrid's (wrapped in Spark Scroller's), which are dynamically populated (so I don't know in advance about 1/2 of Columns). Since the number of columns can be 200+, I am trying to implement a Search within Column Headers and data, one by one kind, so that when match is found, it highlights that cell or at least highlights that row and displays that column, brings it in user view. So far it shows that row, but I never was able to scroll to that column, so user can see it. I tried to use ADG's horizontalScrollPosition, verticalScrollPosition, validateNow with scrollToIndex,... When I try to set selectionMode=singleCell, that sometimes seem to freeze the app. Any advice or code snippet how to scroll to that matching Column? How to highlight the header and/or cell ? Can the problem be in that Scroller? Any help is very appreciated. -- Thank you in advance, Oleg.
Re: Updating Mustella jenkins VM
Can I have the VM now? I'd like to check some things and take a look at the new configuration... EdB On Wed, Dec 4, 2013 at 8:33 AM, Maurice Amsellem maurice.amsel...@systar.com wrote: Done (log attached again) -Message d'origine- De : Alex Harui [mailto:aha...@adobe.com] Envoyé : mercredi 4 décembre 2013 02:14 À : dev@flex.apache.org Objet : Re: Updating Mustella jenkins VM Just send them. Someday I'll need to look at them. -Alex On 12/3/13 4:08 PM, Maurice Amsellem maurice.amsel...@systar.com wrote: What I could do, if you agree, is to have both the standard and the ext notifcations turned on: Standard notification: sends build summary, with no attachement, to commit ML Ext notification: send build summary + log attachement to change committers, excluding Alex. I will wait for your GO this time before proceeding. Alex, what email address (addresses) should I exclude ? Maurice -Message d'origine- De : Maurice Amsellem [mailto:maurice.amsel...@systar.com] Envoyé : mercredi 4 décembre 2013 01:05 À : dev@flex.apache.org Objet : RE: Updating Mustella jenkins VM Ok, I will turn it on. -Message d'origine- De : omup...@gmail.com [mailto:omup...@gmail.com] De la part de OmPrakash Muppirala Envoyé : mercredi 4 décembre 2013 00:56 À : dev@flex.apache.org Objet : Re: Updating Mustella jenkins VM Thank you :-) Maurice, please go ahead and turn it on for now. If not, I can do it. Thanks for getting this working so far. I will try to find some time to work on making the VM publicly available soon. Regards, Om On Tue, Dec 3, 2013 at 3:52 PM, Alex Harui aha...@adobe.com wrote: It will be annoying, but I can live with it. -Alex On 12/3/13 3:41 PM, OmPrakash Muppirala bigosma...@gmail.com wrote: Let us keep the log files attachments coming in until we make the Mustella VM publicly accessible. Alex, would that work for you? Thanks, Om On Tue, Dec 3, 2013 at 3:37 PM, Maurice Amsellem maurice.amsel...@systar.com wrote: Sorry. I already turned off the attachements. Anybody can turn them on back , if they wish: it's in the job configuration... Maurice -Message d'origine- De : Alex Harui [mailto:aha...@adobe.com] Envoyé : mercredi 4 décembre 2013 00:35 À : dev@flex.apache.org Objet : Re: Updating Mustella jenkins VM It didn't occur to me until just before I wrote it. But see my other reply. There's probably fewer folks on commits@ so I'll just live with it for a while and see if anyone else complains. -Alex On 12/3/13 3:32 PM, Maurice Amsellem maurice.amsel...@systar.com wrote: Ok, I will turn off the log zip attachment. But really, I would have appreciated that you said this BEFORE I did it :-( :-( :-( Maurice -Message d'origine- De : omup...@gmail.com [mailto:omup...@gmail.com] De la part de OmPrakash Muppirala Envoyé : mercredi 4 décembre 2013 00:23 À : dev@flex.apache.org Objet : Re: Updating Mustella jenkins VM On Tue, Dec 3, 2013 at 3:15 PM, Alex Harui aha...@adobe.com wrote: Well, I know you put a lot of time into it, but I guess I'm suggesting that this is just going to create more noise for folks, even if you only attach on failure. If you see the kind of notices I get from the spam filter they aren't fun to look at. We already have a problem with folks wanting to unsubscribe. Couldn't the build script simply check in the log into one of our repos? Could we then include a link to the log file in SVN in the email? But sure, you can leave it as is until you get the energy to change it. -Alex Some options we have in order of increasing desirability: 1. Send log file with every email notification 2. Send log file only with failure notifications 3. Check log file into git/svn and include link in the email 4. Expose the Jenkins instance on the Mustella VM to public (like builds.apache.org) I think option 4 is most desirable and shouldn't take a long time to implement. But option 1 or 2 should be good for now. Thanks, Om On 12/3/13 3:04 PM, Maurice Amsellem maurice.amsel...@systar.com wrote: Alex, I understand the concern. I could change the config so that build logs are attached only upon failure, or maybe sent individually to change committers but not to commit list. The plugin is very flexible for that. On the other hand, the build logs compress very well ( 500 KB = 25 KB) because of all the redundancy. Maybe try with this configuration for a few days, and then I will change the notification rules if still requested. WDYT? Maurice -Message d'origine- De : Alex Harui [mailto:aha...@adobe.com] Envoyé : mardi 3 décembre 2013 23:57 À : dev@flex.apache.org Objet : Re: Updating Mustella jenkins VM I think having the logs will be very helpful, so
