flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Harui <aha...@adobe.com>
Subject Re: AW: AW: AW: [Maven - Squiggly] release (was: RE: [jira] [Created] (FLEX-34640) Squiggly: Generate / Package RSLs and deploy with Maven)
Date Mon, 24 Nov 2014 04:50:53 GMT
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.dutz@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
>Von: Alex Harui <aharui@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
>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.
>On 11/22/14, 8:37 AM, "Frédéric THOMAS" <webdoublefx@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.dutz@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 <webdoublefx@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]
>>> > From: christofer.dutz@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 <aharui@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" <justinmclean@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
>>> > >provider and are here to help and are in the process of
>>> > >consolidating/fixing their offerings. We should take advantage of
>>> > >were we can as it should mean less work for us, better security,
>>> > >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
>>> > version, Jenkins version and probably other dependency versions as
>>> > (Ant, Maven, etc).  Somebody else decides which versions are
>>>available and
>>> > when to install/uninstall them.  Your build is sharing compute cycles
>>> > 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
>>> > 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
>>> > releases except for shared libraries like Flex-Tool-API.  BlazeDS
>>> > automated testing might require knowing a port to install Tomcat on
>>> > launching some browser to run FlexUnit or Mustella tests.  Dealing
>>> > 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
>>> >
>>> > If our Maven builds can somehow trust what they’ve built is good
>>> > 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
>>> >

View raw message