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 >
