You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flex.apache.org by Martin Heidegger <mh...@leichtgewicht.at> on 2012/02/13 16:21:39 UTC
Re: [DECISION] Unit Testing and Mocking Frameworks
On 14/02/2012 00:14, Alex Harui wrote:
> My understanding is we should not check in swcs
>
> Sent from my Motorola ATRIX™ 4G on AT&T
Quote from Apache licensing [1]:
By including only the object/binary form, there is less exposed
surface area of the third-party
work from which a work might be derived; this addresses the second
guiding principle of this
policy. By attaching a prominent label to the distribution and
requiring an explicit action by the
user to get the reciprocally-licensed source, users are less likely
to be unaware of restrictions
significantly different from those of the Apache License; this
addresses the fourth guiding
principle of this policy.
That does look a lot like we can include 3rd party libraries if their
licenses match. Like any other,
ordinary, As3 project. Flex could also use dependencies. Would that be
so much horror?
I understand that its not favorable but in contrary to core code: These
3rd party librarys would
only be included to run the framework but to run the tests.
yours
Martin.
[1] http://www.apache.org/legal/3party.html#category-b
Re: [DECISION] Unit Testing and Mocking Frameworks
Posted by Roland Zwaga <ro...@stackandheap.com>.
There's enough build extension that will be able to pull together all
dependencies from
the maven repositories, I don't think this will be an issue.
Perhaps Yennick can shed some light on how this might be possible using
GradleFX?
On 13 February 2012 16:36, Martin Heidegger <mh...@leichtgewicht.at> wrote:
> The release should also be available as zip, including all dependencies.
>
> yours
> Martin.
>
>
> On 14/02/2012 00:27, Roland Zwaga wrote:
>
>> Hey there,
>>
>> But if Maven is used for dependency management then we don't need to
>> include any third party stuff in our repositories.
>> You just reference the appropriate remote repositories and the build
>> system
>> will pull in the necessary files.
>> That's the nice option of using GradleFX, it uses the convenience of the
>> Maven dependency system combined with
>> a sane build syntax.
>> Or am I missing a point somewhere?
>>
>> cheers,
>>
>> Roland
>>
>>
>>
>
--
regards,
Roland
--
Roland Zwaga
Senior Consultant | Stack & Heap BVBA
+32 (0)486 16 12 62 | roland@stackandheap.com | http://www.stackandheap.com
Re: [DECISION] Unit Testing and Mocking Frameworks
Posted by Martin Heidegger <mh...@leichtgewicht.at>.
The release should also be available as zip, including all dependencies.
yours
Martin.
On 14/02/2012 00:27, Roland Zwaga wrote:
> Hey there,
>
> But if Maven is used for dependency management then we don't need to
> include any third party stuff in our repositories.
> You just reference the appropriate remote repositories and the build system
> will pull in the necessary files.
> That's the nice option of using GradleFX, it uses the convenience of the
> Maven dependency system combined with
> a sane build syntax.
> Or am I missing a point somewhere?
>
> cheers,
>
> Roland
>
>
Re: [DECISION] Unit Testing and Mocking Frameworks
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Fri, Feb 17, 2012 at 11:41 AM, Omar Gonzalez
<om...@gmail.com> wrote:
> On Friday, February 17, 2012, Bertrand Delacretaz wrote:
>>... BTW, in my opinion there's not much benefit in deciding for one test
>> framework or another until there are *actual tests in svn* that people
>> can use to make an opinion. Code speaks louder than words...
> Here's a link:
> http://svn.apache.org/viewvc/incubator/flex/whiteboard/s9tpepper/validators/src-tests/org/apache/flex/validators/StringValidatorTests.as?revision=1237166&view=markup
Ok, sorry I missed that. I take my words back: Flex *is* using those
test frameworks then, cool.
-Bertrand
Re: [DECISION] Unit Testing and Mocking Frameworks
Posted by Omar Gonzalez <om...@gmail.com>.
On Friday, February 17, 2012, Bertrand Delacretaz wrote:
> On Fri, Feb 17, 2012 at 11:16 AM, Jun Heider <jun@realeyes.com<javascript:;>>
> wrote:
> > ...can we realistically say that something has been adopted into the
> project
> > without a proper [VOTE] thread?
> >
> > Maybe one of the mentors can set me straight?..
>
> The final rule IMO is that decisions must be made by consensus.
>
> A [VOTE] is definitely consensus, if someone misses that it's their
> problem.
>
> Any other form of consensus can be challenged, because it's too easy
> to miss on a busy list.
>
> I've just added a note to
> https://cwiki.apache.org/confluence/display/FLEX/Getting+Started about
> [DECISION] which is confusing, will discuss in a separate thread.
>
> BTW, in my opinion there's not much benefit in deciding for one test
> framework or another until there are *actual tests in svn* that people
> can use to make an opinion. Code speaks louder than words.
>
> -Bertrand
>
Here's a link:
http://svn.apache.org/viewvc/incubator/flex/whiteboard/s9tpepper/validators/src-tests/org/apache/flex/validators/StringValidatorTests.as?revision=1237166&view=markup
-omar
Re: [DECISION] Unit Testing and Mocking Frameworks
Posted by Omar Gonzalez <om...@gmail.com>.
On Friday, February 17, 2012, Bertrand Delacretaz wrote:
> On Fri, Feb 17, 2012 at 11:16 AM, Jun Heider <jun@realeyes.com<javascript:;>>
> wrote:
> > ...can we realistically say that something has been adopted into the
> project
> > without a proper [VOTE] thread?
> >
> > Maybe one of the mentors can set me straight?..
>
> The final rule IMO is that decisions must be made by consensus.
>
> A [VOTE] is definitely consensus, if someone misses that it's their
> problem.
>
> Any other form of consensus can be challenged, because it's too easy
> to miss on a busy list.
>
> I've just added a note to
> https://cwiki.apache.org/confluence/display/FLEX/Getting+Started about
> [DECISION] which is confusing, will discuss in a separate thread.
>
> BTW, in my opinion there's not much benefit in deciding for one test
> framework or another until there are *actual tests in svn* that people
> can use to make an opinion. Code speaks louder than words.
>
> -Bertrand
>
There are actual tests in the SVN. Head into my whiteboard area,
s9tpepper/validators, the validators I added are tested using FlexUnit and
Mockolate.
-omar
Re: [DECISION] Unit Testing and Mocking Frameworks
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Fri, Feb 17, 2012 at 11:16 AM, Jun Heider <ju...@realeyes.com> wrote:
> ...can we realistically say that something has been adopted into the project
> without a proper [VOTE] thread?
>
> Maybe one of the mentors can set me straight?..
The final rule IMO is that decisions must be made by consensus.
A [VOTE] is definitely consensus, if someone misses that it's their problem.
Any other form of consensus can be challenged, because it's too easy
to miss on a busy list.
I've just added a note to
https://cwiki.apache.org/confluence/display/FLEX/Getting+Started about
[DECISION] which is confusing, will discuss in a separate thread.
BTW, in my opinion there's not much benefit in deciding for one test
framework or another until there are *actual tests in svn* that people
can use to make an opinion. Code speaks louder than words.
-Bertrand
Re: [DECISION] Unit Testing and Mocking Frameworks
Posted by Jun Heider <ju...@realeyes.com>.
On Feb 17, 2012, at 3:25 AM, almansour belleh blanco wrote:
>>
>>
>> That being said, I'm personally not contesting FlexUnit and Mockolate, but on the other hand can we realistically say that something has been adopted into the project without a proper [VOTE] thread?
>>
>> Maybe one of the mentors can set me straight?
>
>
>
> https://cwiki.apache.org/confluence/display/FLEX/Getting+Started
> you can see in the link above that [DECISION] is "Discussion to get a
> decision in a already discussed matter. " so, it means that the
> decision will be taken after everybody agreed on something, I guess.
@Mansour - Thanks for the clarification.
@Omar...proceed. +1 (binding) Looks like I need to re-read the getting started guide. :)
Re: [DECISION] Unit Testing and Mocking Frameworks
Posted by almansour belleh blanco <za...@gmail.com>.
2012/2/17 Jun Heider <ju...@realeyes.com>:
>
> On Feb 16, 2012, at 12:39 AM, Omar Gonzalez wrote:
>
>> I'm not really seeing any opposition to FlexUnit and Mockolate as the unit
>> testing and mocking libraries we should adopt. Unless I get some objections
>> before EOD tomorrow I'm going to assume we've reached a consensus on this
>> and add some verbiage to the project site to communicate which libraries
>> we'll be working with for unit testing the framework.
>>
>> --
>> Omar Gonzalez
>> s9tpepper@apache.org
>
> Hi Omar, sorry for the late response. In addition to this post I also saw some conversation on some commits from you regarding this verbiage.
>
> Two reasons for my tardiness:
>
> 1. Been swamped with tons of client work lately.
>
> 2. This was marked as [DECISION]. Seeing this post makes me wonder, can we here at Apache Flex adopt something holistically without a [VOTE] thread? To be quite honest this mailing list is so busy that when I get busy as in #1 above, I have a tendency to skim my inbox for threads marked with [VOTE].
>
> That being said, I'm personally not contesting FlexUnit and Mockolate, but on the other hand can we realistically say that something has been adopted into the project without a proper [VOTE] thread?
>
> Maybe one of the mentors can set me straight?
https://cwiki.apache.org/confluence/display/FLEX/Getting+Started
you can see in the link above that [DECISION] is "Discussion to get a
decision in a already discussed matter. " so, it means that the
decision will be taken after everybody agreed on something, I guess.
--
Mansour Blanco
Software engineer
Stackoverflow: http://stackoverflow.com/users/612920/mansuro
Blog: zuro.blogspot.com
github: https://github.com/Mansuro
Re: [DECISION] Unit Testing and Mocking Frameworks
Posted by Jun Heider <ju...@realeyes.com>.
On Feb 17, 2012, at 3:45 AM, Omar Gonzalez wrote:
>>
>> In the future I would have to agree with Bertrand on this [LAZY] marker
>> adoption. This will allow us to skim this busy list when we're swamped with
>> paid work and pay more attention when we're not. Also as Bertrand mentioned
>> in the previous response, if this decision had been made and I missed it,
>> then yes...definitely my problem.
>>
>> Thanks all.
>>
>>
> I have no problem doing it again, that's why I asked in this thread. I have
> not publishe the text yet and I'm still learning the ins and outs. I have
> been trying to move this forward for a week now.
>
> -omar
Nah man, push it forward. I'm the one coming in late. Like you I'm learning the ins and outs too. I have another thread going for [LAZY] for future stuffs. So...hack away I say. :)
Re: [DECISION] Unit Testing and Mocking Frameworks
Posted by Omar Gonzalez <om...@gmail.com>.
On Friday, February 17, 2012, Jun Heider wrote:
>
> On Feb 17, 2012, at 3:38 AM, Bertrand Delacretaz wrote:
>
> > On Fri, Feb 17, 2012 at 11:36 AM, Omar Gonzalez
> > <omarg.developer@gmail.com <javascript:;>> wrote:
> >> ...Unless there are objections if there is a "lazy consensus" reached
> there is
> >> no need to [VOTE] on everything...
> >
> > Agreed, but IMO the standard way to ask for lazy consensus is a [LAZY]
> > marker in a subject line, it would be good for Flex to adopt that
> > convention.
> >
> > -Bertrand
>
> In the future I would have to agree with Bertrand on this [LAZY] marker
> adoption. This will allow us to skim this busy list when we're swamped with
> paid work and pay more attention when we're not. Also as Bertrand mentioned
> in the previous response, if this decision had been made and I missed it,
> then yes...definitely my problem.
>
> Thanks all.
>
>
I have no problem doing it again, that's why I asked in this thread. I have
not publishe the text yet and I'm still learning the ins and outs. I have
been trying to move this forward for a week now.
-omar
Re: [DECISION] Unit Testing and Mocking Frameworks
Posted by Jun Heider <ju...@realeyes.com>.
On Feb 17, 2012, at 3:38 AM, Bertrand Delacretaz wrote:
> On Fri, Feb 17, 2012 at 11:36 AM, Omar Gonzalez
> <om...@gmail.com> wrote:
>> ...Unless there are objections if there is a "lazy consensus" reached there is
>> no need to [VOTE] on everything...
>
> Agreed, but IMO the standard way to ask for lazy consensus is a [LAZY]
> marker in a subject line, it would be good for Flex to adopt that
> convention.
>
> -Bertrand
In the future I would have to agree with Bertrand on this [LAZY] marker adoption. This will allow us to skim this busy list when we're swamped with paid work and pay more attention when we're not. Also as Bertrand mentioned in the previous response, if this decision had been made and I missed it, then yes...definitely my problem.
Thanks all.
Re: [DECISION] Unit Testing and Mocking Frameworks
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Fri, Feb 17, 2012 at 11:36 AM, Omar Gonzalez
<om...@gmail.com> wrote:
> ...Unless there are objections if there is a "lazy consensus" reached there is
> no need to [VOTE] on everything...
Agreed, but IMO the standard way to ask for lazy consensus is a [LAZY]
marker in a subject line, it would be good for Flex to adopt that
convention.
-Bertrand
Re: [DECISION] Unit Testing and Mocking Frameworks
Posted by Jun Heider <ju...@realeyes.com>.
On Feb 17, 2012, at 3:36 AM, Omar Gonzalez wrote:
>
> The short answer is yes.
>
> Unless there are objections if there is a "lazy consensus" reached there is
> no need to [VOTE] on everything, we'd never get anything done that way I
> imagine. You can read more on the decision making process here:
> http://www.apache.org/foundation/how-it-works.html
>
> -omar
Yep, I think you and I responded at the same time. Thanks.
Re: [DECISION] Unit Testing and Mocking Frameworks
Posted by Omar Gonzalez <om...@gmail.com>.
On Friday, February 17, 2012, Jun Heider wrote:
>
> On Feb 16, 2012, at 12:39 AM, Omar Gonzalez wrote:
>
> > I'm not really seeing any opposition to FlexUnit and Mockolate as the
> unit
> > testing and mocking libraries we should adopt. Unless I get some
> objections
> > before EOD tomorrow I'm going to assume we've reached a consensus on this
> > and add some verbiage to the project site to communicate which libraries
> > we'll be working with for unit testing the framework.
> >
> > --
> > Omar Gonzalez
> > s9tpepper@apache.org <javascript:;>
>
> Hi Omar, sorry for the late response. In addition to this post I also saw
> some conversation on some commits from you regarding this verbiage.
>
> Two reasons for my tardiness:
>
> 1. Been swamped with tons of client work lately.
>
> 2. This was marked as [DECISION]. Seeing this post makes me wonder, can we
> here at Apache Flex adopt something holistically without a [VOTE] thread?
> To be quite honest this mailing list is so busy that when I get busy as in
> #1 above, I have a tendency to skim my inbox for threads marked with [VOTE].
>
> That being said, I'm personally not contesting FlexUnit and Mockolate, but
> on the other hand can we realistically say that something has been adopted
> into the project without a proper [VOTE] thread?
>
> Maybe one of the mentors can set me straight?
The short answer is yes.
Unless there are objections if there is a "lazy consensus" reached there is
no need to [VOTE] on everything, we'd never get anything done that way I
imagine. You can read more on the decision making process here:
http://www.apache.org/foundation/how-it-works.html
-omar
Re: [DECISION] Unit Testing and Mocking Frameworks
Posted by Jun Heider <ju...@realeyes.com>.
On Feb 16, 2012, at 12:39 AM, Omar Gonzalez wrote:
> I'm not really seeing any opposition to FlexUnit and Mockolate as the unit
> testing and mocking libraries we should adopt. Unless I get some objections
> before EOD tomorrow I'm going to assume we've reached a consensus on this
> and add some verbiage to the project site to communicate which libraries
> we'll be working with for unit testing the framework.
>
> --
> Omar Gonzalez
> s9tpepper@apache.org
Hi Omar, sorry for the late response. In addition to this post I also saw some conversation on some commits from you regarding this verbiage.
Two reasons for my tardiness:
1. Been swamped with tons of client work lately.
2. This was marked as [DECISION]. Seeing this post makes me wonder, can we here at Apache Flex adopt something holistically without a [VOTE] thread? To be quite honest this mailing list is so busy that when I get busy as in #1 above, I have a tendency to skim my inbox for threads marked with [VOTE].
That being said, I'm personally not contesting FlexUnit and Mockolate, but on the other hand can we realistically say that something has been adopted into the project without a proper [VOTE] thread?
Maybe one of the mentors can set me straight?
Re: [DECISION] Unit Testing and Mocking Frameworks
Posted by Omar Gonzalez <om...@gmail.com>.
I'm not really seeing any opposition to FlexUnit and Mockolate as the unit
testing and mocking libraries we should adopt. Unless I get some objections
before EOD tomorrow I'm going to assume we've reached a consensus on this
and add some verbiage to the project site to communicate which libraries
we'll be working with for unit testing the framework.
--
Omar Gonzalez
s9tpepper@apache.org
Re: [DECISION] Unit Testing and Mocking Frameworks
Posted by Yennick Trevels <ye...@gmail.com>.
Well, my previous code example was just stupid,
project.configurations.merged.files is enough, no need for that loop
statement :D
On Mon, Feb 13, 2012 at 5:24 PM, Yennick Trevels
<ye...@gmail.com>wrote:
> Gradle works with configurations to group dependencies. For GradleFx we
> have the merged, internal, external, rsl and test configurations. You can
> do this to create a list of dependency files which are merged into the
> final swf:
>
> def mergedDependencyfiles = []
> project.configurations.merged.files.each { dependency ->
> mergedDependencyFiles.add(dependency);
> }
>
> so getting all those dependencies and adding them to a zip should be no
> problem. You've also got access to the Java API, which has classes to
> manipulate files, create zips etc.
>
>
Re: [DECISION] Unit Testing and Mocking Frameworks
Posted by Yennick Trevels <ye...@gmail.com>.
Gradle works with configurations to group dependencies. For GradleFx we
have the merged, internal, external, rsl and test configurations. You can
do this to create a list of dependency files which are merged into the
final swf:
def mergedDependencyfiles = []
project.configurations.merged.files.each { dependency ->
mergedDependencyFiles.add(dependency);
}
so getting all those dependencies and adding them to a zip should be no
problem. You've also got access to the Java API, which has classes to
manipulate files, create zips etc.
RE: [DECISION] Unit Testing and Mocking Frameworks
Posted by David Arno <da...@davidarno.org>.
> From: Martin Heidegger [mailto:mh@leichtgewicht.at]
> Sent: 13 February 2012 15:50
> The discussion about the build system is going on in another thread and in
jira [1]!
> On the table are Gradle (my favorite), Maven and now buildr.
> Please contribute to the matching thread.
Sorry about that. I've been off the mailing list for a few days and - as I'm
around 250 emails behind - I tried to just jump in on today's emails. Guess
that wasn't such a good idea :)
Gradle looks a good choice, so forget I mentioned buildr.
David.
Re: [DECISION] Unit Testing and Mocking Frameworks
Posted by Martin Heidegger <mh...@leichtgewicht.at>.
On 14/02/2012 00:44, David Arno wrote:
> Looks like Drew is anticipating that for Mockolate as he merged a pull
> request that includes a POM file for Mockolate earlier today.
Interesting.
> Incidentally, whilst I like the idea of us having Maven repositories for
> both Flex and 3rd party libraries, I really hope we don't use Maven for the
> build system too. I'd love to see us use buildr-as3 instead
> (https://github.com/devboy/buildr_as3.) It's better in many ways, not least
> because you don't have to write the build scripts in XML!
The discussion about the build system is going on in another thread and
in jira [1]!
On the table are Gradle (my favorite), Maven and now buildr. Please
contribute to the matching thread.
yours
Martin.
[1] https://issues.apache.org/jira/browse/FLEX-8
RE: [DECISION] Unit Testing and Mocking Frameworks
Posted by David Arno <da...@davidarno.org>.
> From: Roland Zwaga [mailto:roland@stackandheap.com]
> Sent: 13 February 2012 15:48
> GradleFX (http://gradlefx.github.com/) was suggested as the main build
system.
> It uses Groovy for build syntax and convention-over-configuration
> (so also no XML fiddling), we have the added benefit of having one of the
> authors on the malinglist here.
Hi Roland,
Just noticed that, thanks. Hadn't heard of GradleFX before, but a quick read
suggests it's a good choice.
David.
Re: [DECISION] Unit Testing and Mocking Frameworks
Posted by Roland Zwaga <ro...@stackandheap.com>.
Hi David,
GradleFX (http://gradlefx.github.com/) was suggested as the main build
system.
It uses Groovy for build syntax and convention-over-configuration (so also
no XML fiddling),
we have the added benefit of having one of the authors on the malinglist
here.
cheers,
Roland
Incidentally, whilst I like the idea of us having Maven repositories for
> both Flex and 3rd party libraries, I really hope we don't use Maven for the
> build system too. I'd love to see us use buildr-as3 instead
> (https://github.com/devboy/buildr_as3.) It's better in many ways, not
> least
> because you don't have to write the build scripts in XML!
>
> David.
>
>
--
regards,
Roland
--
Roland Zwaga
Senior Consultant | Stack & Heap BVBA
+32 (0)486 16 12 62 | roland@stackandheap.com | http://www.stackandheap.com
RE: [DECISION] Unit Testing and Mocking Frameworks
Posted by David Arno <da...@davidarno.org>.
> From: Roland Zwaga [mailto:roland@stackandheap.com]
> Sent: 13 February 2012 15:27
>
> But if Maven is used for dependency management then we don't need to
include
> any third party stuff in our repositories.
> You just reference the appropriate remote repositories and the build
system will
> pull in the necessary files.
Looks like Drew is anticipating that for Mockolate as he merged a pull
request that includes a POM file for Mockolate earlier today.
Incidentally, whilst I like the idea of us having Maven repositories for
both Flex and 3rd party libraries, I really hope we don't use Maven for the
build system too. I'd love to see us use buildr-as3 instead
(https://github.com/devboy/buildr_as3.) It's better in many ways, not least
because you don't have to write the build scripts in XML!
David.
Re: [DECISION] Unit Testing and Mocking Frameworks
Posted by Roland Zwaga <ro...@stackandheap.com>.
Hey there,
But if Maven is used for dependency management then we don't need to
include any third party stuff in our repositories.
You just reference the appropriate remote repositories and the build system
will pull in the necessary files.
That's the nice option of using GradleFX, it uses the convenience of the
Maven dependency system combined with
a sane build syntax.
Or am I missing a point somewhere?
cheers,
Roland
On 13 February 2012 16:21, Martin Heidegger <mh...@leichtgewicht.at> wrote:
>
> On 14/02/2012 00:14, Alex Harui wrote:
>
>> My understanding is we should not check in swcs
>>
>> Sent from my Motorola ATRIX™ 4G on AT&T
>>
> Quote from Apache licensing [1]:
>
> By including only the object/binary form, there is less exposed surface
> area of the third-party
> work from which a work might be derived; this addresses the second
> guiding principle of this
> policy. By attaching a prominent label to the distribution and requiring
> an explicit action by the
> user to get the reciprocally-licensed source, users are less likely to be
> unaware of restrictions
> significantly different from those of the Apache License; this addresses
> the fourth guiding
> principle of this policy.
>
> That does look a lot like we can include 3rd party libraries if their
> licenses match. Like any other,
> ordinary, As3 project. Flex could also use dependencies. Would that be so
> much horror?
>
> I understand that its not favorable but in contrary to core code: These
> 3rd party librarys would
> only be included to run the framework but to run the tests.
>
> yours
> Martin.
>
> [1] http://www.apache.org/legal/**3party.html#category-b<http://www.apache.org/legal/3party.html#category-b>
>
--
regards,
Roland
--
Roland Zwaga
Senior Consultant | Stack & Heap BVBA
+32 (0)486 16 12 62 | roland@stackandheap.com | http://www.stackandheap.com