flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Harui <aha...@adobe.com>
Subject Re: [Maven - Squiggly] release (was: RE: [jira] [Created] (FLEX-34640) Squiggly: Generate / Package RSLs and deploy with Maven)
Date Fri, 21 Nov 2014 17:51:40 GMT

On 11/21/14, 3:22 AM, "Justin Mclean" <justinmclean@me.com> wrote:

>> If you're feeling brave, go ahead. Past experience with INFRA makes me
>> 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

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


View raw message