You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flex.apache.org by Bertrand Delacretaz <bd...@apache.org> on 2012/02/10 16:32:47 UTC
Continuous integration for Flex (was: [RT] Recommendation Unit-Test System?)
On Fri, Feb 10, 2012 at 4:12 PM, Martin Heidegger <mh...@leichtgewicht.at> wrote:
> On 11/02/2012 00:04, David Francis Buhler wrote:
>> Is there any interest in adopting a Continuous Integration environment
>> which kick off the Unit Tests, perhaps using Hudson?
>>
> ...Apache has a continuous integration server project called Continuum [1] that
> seems to be quite active...
Info about build services for Apache projects is at http://ci.apache.org/
-Bertrand
Re: Continuous integration for Flex (was: [RT] Recommendation Unit-Test System?)
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> The SVN history is not important for creating a proposal and it is not important for us to start discussing next steps.
Not essential no but still can be very useful.
> The code in Github should be sufficient to start the Building discussion and subsequently create Jira entries with diffs.
As long as it's keep in sync with the real trunk no issues. There's the minor issue of path name is diff files (but certainly not a huge issue). Certainly not an impediment to start playing about.
Thanks,
Justin
Re: Continuous integration for Flex (was: [RT] Recommendation Unit-Test
System?)
Posted by Martin Heidegger <mh...@leichtgewicht.at>.
On 12/02/2012 17:54, Justin Mclean wrote:
> Yes there is a version in the whiteboard (but it's missing the full SVN history) the "real" trunk is due to be imported this weekend so should be there real soon now. There was a request for for a Git mirror of Flex SVN but I'm not sure where that's at.
>
> Justin
The SVN history is not important for creating a proposal and it is not
important for us to start discussing next steps. The code in Github
should be sufficient to start the Building discussion and subsequently
create Jira entries with diffs.
yours
Martin.
Re: Continuous integration for Flex (was: [RT] Recommendation Unit-Test System?)
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi Martin,
Yes there is a version in the whiteboard (but it's missing the full SVN history) the "real" trunk is due to be imported this weekend so should be there real soon now. There was a request for for a Git mirror of Flex SVN but I'm not sure where that's at.
Justin
On 12/02/2012, at 7:41 PM, Martin Heidegger wrote:
> On 12/02/2012 17:08, Justin Mclean wrote:
>> Hi Yennick,
>>
>> The truck hasn't been checked in yet. It's due to happen (unless there is an issue with the import) this weekend so hopefully it will occur in the next 24 hours.
>>
>> Justin
>>
> Hello Justin,
>
> you are talking about the SVN History for the trunk in the Whiteboard/frameworks section of the SVN there is already a version that is enough to start work with.
> I am in the process of cloning that to github (takes a while): https://github.com/martinheidegger/Apache-Flex---Whiteboard-4.6
>
> yours
> Martin.
Re: Continuous integration for Flex (was: [RT] Recommendation Unit-Test
System?)
Posted by Martin Heidegger <mh...@leichtgewicht.at>.
On 12/02/2012 19:01, Martin Heidegger wrote:
> I don't know why to wait for it. The source doesn't change because its
> history is not imported yet. It seems like a boring excuse not to start.
>
> The pushing is now through.[1] I'd say: lets start branching :)
>
> yours
> Martin.
>
> https://github.com/martinheidegger/Apache-Flex---Whiteboard-4.6/watchers
I found a organization more appropriate, so I transferred it.
https://github.com/Flex-Community-Efforts/Apache-Flex---Whiteboard-4.6
Re: Continuous integration for Flex (was: [RT] Recommendation Unit-Test
System?)
Posted by Martin Heidegger <mh...@leichtgewicht.at>.
On 12/02/2012 18:09, Justin Mclean wrote:
> Hi,
>
> Svn git mirror request is:
> https://issues.apache.org/jira/browse/INFRA-4366
>
> Looks like is just waiting for the trunk to be imported?
>
> Justin
>
>
I don't know why to wait for it. The source doesn't change because its
history is not imported yet. It seems like a boring excuse not to start.
The pushing is now through.[1] I'd say: lets start branching :)
yours
Martin.
https://github.com/martinheidegger/Apache-Flex---Whiteboard-4.6/watchers
Re: Continuous integration for Flex (was: [RT] Recommendation Unit-Test System?)
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
Svn git mirror request is:
https://issues.apache.org/jira/browse/INFRA-4366
Looks like is just waiting for the trunk to be imported?
Justin
Re: Continuous integration for Flex (was: [RT] Recommendation Unit-Test
System?)
Posted by Martin Heidegger <mh...@leichtgewicht.at>.
On 12/02/2012 17:08, Justin Mclean wrote:
> Hi Yennick,
>
> The truck hasn't been checked in yet. It's due to happen (unless there is an issue with the import) this weekend so hopefully it will occur in the next 24 hours.
>
> Justin
>
Hello Justin,
you are talking about the SVN History for the trunk in the
Whiteboard/frameworks section of the SVN there is already a version that
is enough to start work with.
I am in the process of cloning that to github (takes a while):
https://github.com/martinheidegger/Apache-Flex---Whiteboard-4.6
yours
Martin.
Re: Continuous integration for Flex (was: [RT] Recommendation Unit-Test System?)
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi Yennick,
The truck hasn't been checked in yet. It's due to happen (unless there is an issue with the import) this weekend so hopefully it will occur in the next 24 hours.
Justin
Re: Continuous integration for Flex (was: [RT] Recommendation
Unit-Test System?)
Posted by Yennick Trevels <ye...@gmail.com>.
I tried to create a mirror from git://git.apache.org/flex.git to
https://github.com/SlevinBE/ApacheFlex, but I'm only getting one text file
when checking out the repo. So the original git repo isn't working or I'm
doing something wrong :)
Re: Continuous integration for Flex (was: [RT] Recommendation Unit-Test
System?)
Posted by Martin Heidegger <mh...@leichtgewicht.at>.
I am all in! Who opens a github clone of the svn so we can start working
on a proposal code?
yours
Martin
On 11/02/2012 20:18, Yennick Trevels wrote:
>> *) The SDK (and some applications) has code that is timezone specific
>> (different output in a different timezone):
>> Does Gradle support to run the same tests in different environments
>> and eventually compiler settings?
>>
> There are two ways to do this:
>
> - init scripts:
> http://gradle.org/docs/current/userguide/init_scripts.html
> - configuration file:
> http://mrhaki.blogspot.com/2009/11/gradle-goodness-using-properties-for.html
>
>
>
>> *) Some of the functionality might require to be tested against the adl
>> and not the flash player, does that work?
>>
> GradleFx has support for FlexUnit, which supports running tests against
> ADL. We support all the properties exposed by FlexUnit, so you configure
> FlexUnit the way you like.
> For more information about those options see the GradleFx properties
> documentation:
> https://github.com/GradleFx/GradleFx/wiki/Properties-conventions
> More information about testing with FlexUnit in GradleFx can be found here:
> https://github.com/GradleFx/GradleFx/wiki/Flexunit
>
Re: Continuous integration for Flex (was: [RT] Recommendation
Unit-Test System?)
Posted by Taylor Brown <ta...@taytay.com>.
I just thought I'd throw some weight behind Gradle (and GradleFx) as an
excellent build platform. Just this week I moved 90% of our build from Ant,
and it has been a breath of fresh air. We have an AIR app with 10+
libraries, Flex monkey patches, compiled CSS swfs, reliance on lots of 3rd
party libraries, etc. It is a pretty good real-world test.
I have found Ant to be verbose and difficult to read, whereas many of my
Gradle scripts to compile my sub-projects were about 6 lines long,
including braces. If my sub-projects follow convention, the scripts are
literally 0 lines long.
Here were the pros as I saw them:
* Access to a real language (including if statements). No more "coding" in
XML to do trivial things. "If" statements are naturally supported and don't
require a 3rd-party add-in. ;)
* Build server and fellow developers don't even need Gradle installed.
Gradle knows how to bootstrap itself.
* I don't know the first thing about Maven, but it was easy tell my script,
"Hey, you need these plugins to run this script," and it took care of the
rest.
* I could *easily* change the "convention" in the "convention over
configuration". Since my 10+ projects use conventions that were slightly
different than GradleFx, it was easy to say things like "source lives here
unless you're told otherwise." or "Use these common compile parameters for
most builds."
* Gradle is naturally structured the way that I already thought about my
builds: I've got one main master project I'm trying to build, and then lots
of sub-projects that depend on each other and that generally look alike. If
a sub-project doesn't break convention, it doesn't even need its own build
script!
* Native integration with Ant for tasks you don't want to rewrite. Just
tell it to "import build.xml" and it exposes all of your ant tasks
natively. We had a few Ant tasks that I haven't moved over yet, so this was
perfect. If the only thing we use Gradle for is running the legacy ant
build, I think it would be worth it! :)
* Easy integration with TeamCity (our CI server), or your build server of
choice.
* Excellent documentation
* The GradleFx guys were responsive when I filed a couple of minor issues
in GitHub.
Cons:
* Maybe I'd spent too long in the Ant world, but when I wanted an easy way
to have different properties files that were used in different contexts
(dev machine overrides, build server, etc), I had to turn to a plugin:
http://wiki.gradle.org/display/GRADLE/Plugins#Plugins-JavaPropFilePlugin
(Not a huge con: This plugin worked great, and it downloads and installs
itself as part of my build)
* There were a few times where the cleverness of the syntax/DSL was too
clever for me. Most of the time it's unnoticed, but sometimes I found
myself wanting/needing to know when certain closures were going to be
evaluated.
*When debugging my build, I had a choice between "Just tell me the error,
but don't give me enough info to fix it." (default) or "run in debug mode
and give me a LOT to read through." I didn't find the switch for "Tell me
what Ant is trying to execute here, but don't tell me about the Gradle
internals". It wasn't too bad. Just meant a lot of scrolling through debug
statements.
In short, even if we don't use Gradle and GradleFx for building the
FlexSDK, you should check it out for your own projects.
Cheers,
Taylor Brown
On Sat, Feb 11, 2012 at 10:26 AM, Yennick Trevels <yennick.trevels@gmail.com
> wrote:
> Hi, I'm the Co-founder of the GradleFx project, a plugin for the Gradle
> build system to compile Flex projects.
> I'm also interested in evaluating Gradle/GradleFx to build the Flex SDK,
> because I think Gradle will benefit us in the long term. Gradle has
> basically all the good things from Ant and Maven, without most of the
> disadvantages.
> These are some of its features:
>
> - Convention-over-configuration
> - Advanced multi-project support
> - Dependency Management (better handling of transitive dependencies)
> - Groovy scripting instead of xml
> - Support for Maven and Ivy repositories
> - Source file change detection (only recompiles the projects which have
> changed)
> - Very easy to add custom build logic
>
> All this leads to a much shorter build script which is easier to customize
> and understand.
>
> Gradle can be found here: http://www.gradle.org
> GradleFx can be found here: http://gradlefx.github.com
> Some GradleFx sample projects can be found here:
> https://github.com/GradleFx/GradleFx-Examples
>
On Sat, Feb 11, 2012 at 12:18 PM, Yennick Trevels <yennick.trevels@gmail.com
> wrote:
> > *) The SDK (and some applications) has code that is timezone specific
> > (different output in a different timezone):
> > Does Gradle support to run the same tests in different environments
> > and eventually compiler settings?
> >
>
> There are two ways to do this:
>
> - init scripts:
> http://gradle.org/docs/current/userguide/init_scripts.html
> - configuration file:
>
> http://mrhaki.blogspot.com/2009/11/gradle-goodness-using-properties-for.html
>
>
>
> > *) Some of the functionality might require to be tested against the adl
> > and not the flash player, does that work?
> >
>
> GradleFx has support for FlexUnit, which supports running tests against
> ADL. We support all the properties exposed by FlexUnit, so you configure
> FlexUnit the way you like.
> For more information about those options see the GradleFx properties
> documentation:
> https://github.com/GradleFx/GradleFx/wiki/Properties-conventions
> More information about testing with FlexUnit in GradleFx can be found here:
> https://github.com/GradleFx/GradleFx/wiki/Flexunit
>
Re: Continuous integration for Flex (was: [RT] Recommendation
Unit-Test System?)
Posted by Yennick Trevels <ye...@gmail.com>.
> *) The SDK (and some applications) has code that is timezone specific
> (different output in a different timezone):
> Does Gradle support to run the same tests in different environments
> and eventually compiler settings?
>
There are two ways to do this:
- init scripts:
http://gradle.org/docs/current/userguide/init_scripts.html
- configuration file:
http://mrhaki.blogspot.com/2009/11/gradle-goodness-using-properties-for.html
> *) Some of the functionality might require to be tested against the adl
> and not the flash player, does that work?
>
GradleFx has support for FlexUnit, which supports running tests against
ADL. We support all the properties exposed by FlexUnit, so you configure
FlexUnit the way you like.
For more information about those options see the GradleFx properties
documentation:
https://github.com/GradleFx/GradleFx/wiki/Properties-conventions
More information about testing with FlexUnit in GradleFx can be found here:
https://github.com/GradleFx/GradleFx/wiki/Flexunit
Re: Continuous integration for Flex (was: [RT] Recommendation Unit-Test
System?)
Posted by Martin Heidegger <mh...@leichtgewicht.at>.
Hello Yennick,
as I have never been a fan of maven - mostly because of the flex mojo
implementation: I think this is awesome!
Specially after peeking into the syntax and that its released under the APL!
Out of curiosity:
*) The SDK (and some applications) has code that is timezone specific
(different output in a different timezone):
Does Gradle support to run the same tests in different
environments and eventually compiler settings?
*) Some of the functionality might require to be tested against the
adl and not the flash player, does that work?
yours
Martin.
On 11/02/2012 18:26, Yennick Trevels wrote:
> Hi, I'm the Co-founder of the GradleFx project, a plugin for the Gradle
> build system to compile Flex projects.
> I'm also interested in evaluating Gradle/GradleFx to build the Flex SDK,
> because I think Gradle will benefit us in the long term. Gradle has
> basically all the good things from Ant and Maven, without most of the
> disadvantages.
>
> These are some of its features:
>
> - Convention-over-configuration
> - Advanced multi-project support
> - Dependency Management (better handling of transitive dependencies)
> - Groovy scripting instead of xml
> - Support for Maven and Ivy repositories
> - Source file change detection (only recompiles the projects which have
> changed)
> - Very easy to add custom build logic
>
> All this leads to a much shorter build script which is easier to customize
> and understand.
>
> Gradle can be found here: http://www.gradle.org
> GradleFx can be found here: http://gradlefx.github.com
> Some GradleFx sample projects can be found here:
> https://github.com/GradleFx/GradleFx-Examples
>
Re: Continuous integration for Flex (was: [RT] Recommendation
Unit-Test System?)
Posted by Yennick Trevels <ye...@gmail.com>.
Hi, I'm the Co-founder of the GradleFx project, a plugin for the Gradle
build system to compile Flex projects.
I'm also interested in evaluating Gradle/GradleFx to build the Flex SDK,
because I think Gradle will benefit us in the long term. Gradle has
basically all the good things from Ant and Maven, without most of the
disadvantages.
These are some of its features:
- Convention-over-configuration
- Advanced multi-project support
- Dependency Management (better handling of transitive dependencies)
- Groovy scripting instead of xml
- Support for Maven and Ivy repositories
- Source file change detection (only recompiles the projects which have
changed)
- Very easy to add custom build logic
All this leads to a much shorter build script which is easier to customize
and understand.
Gradle can be found here: http://www.gradle.org
GradleFx can be found here: http://gradlefx.github.com
Some GradleFx sample projects can be found here:
https://github.com/GradleFx/GradleFx-Examples
Re: Continuous integration for Flex (was: [RT] Recommendation Unit-Test
System?)
Posted by Martin Heidegger <mh...@leichtgewicht.at>.
On 11/02/2012 09:39, Michael A. Labriola wrote:
>>> That's too bad because we are running into issues with file system path length limitations on Windows in our local Perforce workspace, even with our root in C:\.perforce.
As far as I can see, neither buildbot nor Jenkins (the two systems
offered by apache by default have this problem. So: do we need to care?
From what I can tell both systems will run fine if its a maven project
(which shouldn't be a problem for Flex).
I wonder if Gradle FX might be a good alternative - easier to write,
easier to understand ... same powerful, same backend(maven repository)
yours
Martin.
RE: Continuous integration for Flex (was: [RT] Recommendation
Unit-Test System?)
Posted by "Michael A. Labriola" <la...@digitalprimates.net>.
>>That's too bad because we are running into issues with file system path length limitations on Windows in our local Perforce workspace, even with our root in C:\.perforce.
Yes, it sure is.
Notice: This transmission is intended only for the use of the individual or entity to which it is addressed and may contain information that is privileged or confidential. Any dissemination, distribution or copying of this transmission by anyone other than the intended recipient is strictly prohibited. If you have received this transmission in error, please notify the sender immediately by e-mail or telephone and delete the original transmission. Thank you.
Re: Continuous integration for Flex (was: [RT] Recommendation Unit-Test System?)
Posted by Ariel Jakobovits <ar...@yahoo.com>.
That's too bad because we are running into issues with file system path length limitations on Windows in our local Perforce workspace, even with our root in C:\.perforce.
Ariel Jakobovits
Email: arieljake@yahoo.com
Phone: 650-690-2213
Fax: 650-641-0031
Cell: 650-823-8699
________________________________
From: Michael A. Labriola <la...@digitalprimates.net>
To: "flex-dev@incubator.apache.org" <fl...@incubator.apache.org>
Sent: Friday, February 10, 2012 10:52 AM
Subject: RE: Continuous integration for Flex (was: [RT] Recommendation Unit-Test System?)
> Having said that, running Flexmojos 4 with FlexUnit and coverage is pretty painless on Redhat.
>I have had pretty many problems running AIR tests (for air specific code) on linux.
Also remember that, so far as I know, Adobe AIR for linux is not under development so we won't be able to run unit tests on the AIR framework if we use a linux build server
Notice: This transmission is intended only for the use of the individual or entity to which it is addressed and may contain information that is privileged or confidential. Any dissemination, distribution or copying of this transmission by anyone other than the intended recipient is strictly prohibited. If you have received this transmission in error, please notify the sender immediately by e-mail or telephone and delete the original transmission. Thank you.
RE: Continuous integration for Flex (was: [RT] Recommendation
Unit-Test System?)
Posted by "Michael A. Labriola" <la...@digitalprimates.net>.
> Having said that, running Flexmojos 4 with FlexUnit and coverage is pretty painless on Redhat.
>I have had pretty many problems running AIR tests (for air specific code) on linux.
Also remember that, so far as I know, Adobe AIR for linux is not under development so we won't be able to run unit tests on the AIR framework if we use a linux build server
Notice: This transmission is intended only for the use of the individual or entity to which it is addressed and may contain information that is privileged or confidential. Any dissemination, distribution or copying of this transmission by anyone other than the intended recipient is strictly prohibited. If you have received this transmission in error, please notify the sender immediately by e-mail or telephone and delete the original transmission. Thank you.
Re: Continuous integration for Flex (was: [RT] Recommendation Unit-Test
System?)
Posted by Martin Heidegger <mh...@leichtgewicht.at>.
On 11/02/2012 01:56, Skogen, Espen wrote:
> Having said that, running Flexmojos 4 with FlexUnit and coverage is pretty painless on Redhat.
I have had pretty many problems running AIR tests (for air specific
code) on linux.
yours
Martin.
RE: Continuous integration for Flex (was: [RT] Recommendation
Unit-Test System?)
Posted by "Skogen, Espen" <es...@jpmorgan.com>.
Having said that, running Flexmojos 4 with FlexUnit and coverage is pretty painless on Redhat.
Definitely we worth looking at.
Espen Skogen | Vice President | IB Tech Market | Investment Bank | J.P. Morgan | 125 London Wall, EC2Y 5AJ, London, United Kingdom | T: +442077420836 | espen.skogen@jpmorgan.com | jpmorgan.com
-----Original Message-----
From: Martin Heidegger [mailto:mh@leichtgewicht.at]
Sent: 10 February 2012 15:43
To: flex-dev@incubator.apache.org
Subject: Re: Continuous integration for Flex (was: [RT] Recommendation Unit-Test System?)
On 11/02/2012 00:32, Bertrand Delacretaz wrote:
> Info about build services for Apache projects is at http://ci.apache.org/
Awesome! There are two systems that actually have Windows and MacOS
servers at their hands to choose from:
http://ci.apache.org/buildbot.html
https://builds.apache.org/ (jenkins)
I still think it will be unavoidable to run the tests in flashplayer/air
- specially since the unit tests provided by Adobe are mustella stuff
and mustella has pixel based tests.
yours
Martin.
This email is confidential and subject to important disclaimers and
conditions including on offers for the purchase or sale of
securities, accuracy and completeness of information, viruses,
confidentiality, legal privilege, and legal entity disclaimers,
available at http://www.jpmorgan.com/pages/disclosures/email.
Re: Continuous integration for Flex (was: [RT] Recommendation Unit-Test
System?)
Posted by Martin Heidegger <mh...@leichtgewicht.at>.
The BSD license is similar to the APL - Category A
http://www.apache.org/legal/resolved.html#category-a
so I don't see a problem.
yours
Martin.
On 11/02/2012 00:52, David Francis Buhler wrote:
> Do the FlexPMD and FlexCPD licenses allow us to use the aforementioned
> projects in an Apache Project (as part of a CI Environment)?
>
> http://opensource.adobe.com/wiki/display/flexpmd/License
>
Re: Continuous integration for Flex (was: [RT] Recommendation
Unit-Test System?)
Posted by David Francis Buhler <da...@gmail.com>.
Do the FlexPMD and FlexCPD licenses allow us to use the aforementioned
projects in an Apache Project (as part of a CI Environment)?
http://opensource.adobe.com/wiki/display/flexpmd/License
On Fri, Feb 10, 2012 at 10:42 AM, Martin Heidegger <mh...@leichtgewicht.at> wrote:
> On 11/02/2012 00:32, Bertrand Delacretaz wrote:
>>
>> Info about build services for Apache projects is at http://ci.apache.org/
>
>
> Awesome! There are two systems that actually have Windows and MacOS servers
> at their hands to choose from:
>
> http://ci.apache.org/buildbot.html
> https://builds.apache.org/ (jenkins)
>
> I still think it will be unavoidable to run the tests in flashplayer/air -
> specially since the unit tests provided by Adobe are mustella stuff and
> mustella has pixel based tests.
>
> yours
> Martin.
>
Re: Continuous integration for Flex (was: [RT] Recommendation Unit-Test
System?)
Posted by Martin Heidegger <mh...@leichtgewicht.at>.
On 11/02/2012 00:32, Bertrand Delacretaz wrote:
> Info about build services for Apache projects is at http://ci.apache.org/
Awesome! There are two systems that actually have Windows and MacOS
servers at their hands to choose from:
http://ci.apache.org/buildbot.html
https://builds.apache.org/ (jenkins)
I still think it will be unavoidable to run the tests in flashplayer/air
- specially since the unit tests provided by Adobe are mustella stuff
and mustella has pixel based tests.
yours
Martin.