Mustella does try to kill the process after some amount of time with no output coming to the log but it isn’t always successful. If FlexMojos has a superior way of killing the player, I suppose we can’t borrow its code, but if there is some principle missing from Mustella’s process killer, maybe you can upgrade it.
On 11/23/14, 2:01 AM, "Christofer Dutz" <christofer.d...@c-ware.de> wrote: >I think the main problem is that Mustella doesn't seem to be able to >handle problems with the Flash or Air runtime. As far as I understood >whenever the build hangs, usually a flashplayer instance is locked and a >user has to click on a popup. In flexmojos we have this timeout mechanism >and it kills the process if it doesn't return in time. Perhaps we should >invest some time in making things more robust. If it hangs --> kill it ;-) > >I know you said that this would not be possible as the tests run quite >long, but I doubt we coudln't implement some sort of Whatchdog >functionality. > >Chris > >________________________________________ >Von: Alex Harui <aha...@adobe.com> >Gesendet: Sonntag, 23. November 2014 05:44 >An: dev@flex.apache.org >Betreff: Re: AW: AW: [Maven - Squiggly] release (was: RE: [jira] >[Created] (FLEX-34640) Squiggly: Generate / Package RSLs and deploy with >Maven) > >As Justin suggested, what would we ask Infra for that would “solve >everything”? At one point they offered us an Azure VM. Could such a VM >be “inside the security perimeter” enough that we could store credentials >on it and thus deploy to Maven repos? > >Another idea that popped into my head is about the topic of “repeatable >builds”. Flex has been asked in the past to compile a SWF from the same >sources at different times and on different machines and produce the exact >same bits. (Right now, MXMLC returns a different SWF every time you >compile it because of time stamps in the SWF, plus a few other things). >Falcon made the some changes to try to help towards that effort. If we >could do that, or get close to it, then the Maven build could better >compare its binaries against binaries produced by the Ant builds that >passed GUI tests. Then we would feel better that the results are correct. > >-Alex > >On 11/22/14, 8:37 AM, "Frédéric THOMAS" <webdoubl...@hotmail.com> wrote: > >>That seems a good idea, effectively, we've got what need for the sdk >>because the mavenizer does the job to prepare it for maven with the >>require directory structure, what about the others, flexunit, squiggly, >>blazeds, etc... ? >> >>Also, for flexunit for example, I noticed the listener for AIR isn't >>built, at least I can't see it from >>http://apacheflexbuild.cloudapp.net:8080/job/flex-flexunit/ someone knows >>why ? >> >>Frédéric THOMAS >> >>> From: christofer.d...@c-ware.de >>> To: dev@flex.apache.org >>> Subject: AW: AW: [Maven - Squiggly] release (was: RE: [jira] [Created] >>>(FLEX-34640) Squiggly: Generate / Package RSLs and deploy with Maven) >>> Date: Sat, 22 Nov 2014 16:09:45 +0000 >>> >>> Actually I think we could already have all we need. The Mavenizer has >>>this auto-downloader which I only enabled for Air and Flash (Didn't want >>>to under run the installer). So I could simply create a "mavenizer" >>>maven plugin, which does nothing else than download our binary >>>distribution, download an Air version, download Playerglobal and deploy >>>that stuff automatically. >>> >>> Enabling the download of the Flex SDK binary and creating the maven >>>plugin shouldn't be too much work. >>> >>> Then all we would have to do is have one job run that on b.a.o once >>>every night and it could auto-deploy the latest FDK once a night. What >>>do you think about that? >>> >>> Chris >>> >>> ________________________________________ >>> Von: Frédéric THOMAS <webdoubl...@hotmail.com> >>> Gesendet: Samstag, 22. November 2014 16:22 >>> An: dev@flex.apache.org >>> Betreff: RE: AW: [Maven - Squiggly] release (was: RE: [jira] [Created] >>>(FLEX-34640) Squiggly: Generate / Package RSLs and deploy with Maven) >>> >>> Hi, >>> >>> To continue on the idea of generating from our own VMs the needed >>>artifacts / poms and having a job running on build.a.o taking it and >>>deploy it, I found this Maven plugin [1] which I guess could help for a >>>bulk deploy, now, the only remaining problem is in how to pass the built >>>artifacts from the VM to build.a.o. >>> >>> A possibility could maybe having a Private Maven Repo on the VM, only >>>accessible from the job on build.a.o with credentials, still from the >>>VM, having a job that create an assembly from the artifacts we want to >>>deploy, basically all snapshots, then from build.a.o extract the >>>assembly an use the maven-bulk-deploy. >>> >>> Thoughts ? >>> >>> Frédéric THOMAS >>> >>> [1] >>>http://bsorrentino.github.io/maven-bulk-deploy/deploy-folder-mojo.html >>> >>> > From: christofer.d...@c-ware.de >>> > To: dev@flex.apache.org >>> > Subject: AW: [Maven - Squiggly] release (was: RE: [jira] [Created] >>>(FLEX-34640) Squiggly: Generate / Package RSLs and deploy with Maven) >>> > Date: Sat, 22 Nov 2014 11:41:06 +0000 >>> > >>> > Well the projects currently built with Maven are, as you stated, >>>almost all Java. I encountered one project actually built with flexmojos >>>but we can't have this built on b.a.o as this would require a mavenized >>>release version of Flex and this is missing. As soon as we have all our >>>stuff out officially with maven I think a lot of things will be becoming >>>more and more easy. >>> > >>> > I could try to work with infra and check out the options for having >>>our stuff working on their systems. Mabe they would be willing to copy a >>>mavenized version of flex to the build agent's local maven repo, but I >>>doubt this would work. >>> > >>> > And ... just to add another thing to my "I love maven" list ... these >>>path settings, environment variables, binary requirements and so on are >>>only needed because there is no structure. Not a single Maven built >>>module has need for any of these settings (Ok ... flexmojos built ones >>>do have the requirement to have the flashplayer and adl on the path, but >>>that's all). But I know ... a maven built SDK won't be coming ... but if >>>you stop dreaming, you've already lost ;-) >>> > >>> > Chris >>> > >>> > ________________________________________ >>> > Von: Alex Harui <aha...@adobe.com> >>> > Gesendet: Freitag, 21. November 2014 18:51 >>> > An: dev@flex.apache.org >>> > Betreff: Re: [Maven - Squiggly] release (was: RE: [jira] [Created] >>>(FLEX-34640) Squiggly: Generate / Package RSLs and deploy with Maven) >>> > >>> > On 11/21/14, 3:22 AM, "Justin Mclean" <justinmcl...@me.com> wrote: >>> > >>> > >Hi, >>> > > >>> > >> If you're feeling brave, go ahead. Past experience with INFRA >>>makes me >>> > >>wary >>> > >> to go down that rabbit hole again. >>> > > >>> > >They gave a few talks at ApacheCon, they now see themselves as a >>>service >>> > >provider and are here to help and are in the process of >>> > >consolidating/fixing their offerings. We should take advantage of >>>Infra >>> > >were we can as it should mean less work for us, better security, >>>faster >>> > >boxes etc, etc >>> > >>> > That’s great, it is fine for folks to try again, but fundamentally, >>>if the >>> > strategy is still several projects sharing a Jenkins instance, then I >>> > disagree with Infra's approach. >>> > >>> > The code you build on build.a.o currently has to be independent of >>>Java >>> > version, Jenkins version and probably other dependency versions as >>>well >>> > (Ant, Maven, etc). Somebody else decides which versions are >>>available and >>> > when to install/uninstall them. Your build is sharing compute cycles >>>and >>> > disk space with other project’s builds, and you have limited access >>>to the >>> > low-level. I could never run a debug session on the Flash Player on >>> > builds.a.o. >>> > >>> > If they want to give us our own VM then we’re not sharing and that >>>would >>> > be more interesting, but then I think we can’t deploy to Maven. >>> > >>> > That’s why this thread is exploring the logistics of building Maven >>> > artifacts if you can or can’t do GUI testing of the build. That >>>seems to >>> > be the key issue to me. Assuming Apache Flex becomes more and more >>> > popular, we will want to eventually have automated tests for all of >>>our >>> > releases except for shared libraries like Flex-Tool-API. BlazeDS >>> > automated testing might require knowing a port to install Tomcat on >>>and >>> > launching some browser to run FlexUnit or Mustella tests. Dealing >>>with >>> > collisions with other projects over whether they also have a Tomcat >>> > instance running or something else that uses a port we want to use or >>> > wanting to use a different browser version sounds like an awful >>>future. >>> > >>> > If our Maven builds can somehow trust what they’ve built is good >>>without >>> > GUI testing then they are more likely to work on builds.a.o with less >>> > hassle since the actual Maven build seems to be more version >>>tolerant: it >>> > appears to just compile and run java code (which in turn compiles but >>> > doesn’t run ActionScript). >>> > >>> > -Alex >>> > >> >
