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
