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 >> > >
