On Fri, Feb 17, 2012 at 11:41 AM, Omar Gonzalez
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
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 p
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
> > > wrote:
> >> ...Unless there are objections if there is a "lazy consensus" reached
> there is
> >> no need to [VOTE] on everything.
On Feb 17, 2012, at 3:38 AM, Bertrand Delacretaz wrote:
> On Fri, Feb 17, 2012 at 11:36 AM, Omar Gonzalez
> 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 con
On Friday, February 17, 2012, Bertrand Delacretaz wrote:
> On Fri, Feb 17, 2012 at 11:16 AM, Jun Heider >
> 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
On Friday, February 17, 2012, Bertrand Delacretaz wrote:
> On Fri, Feb 17, 2012 at 11:16 AM, Jun Heider >
> 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
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 h
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
On Fri, Feb 17, 2012 at 11:36 AM, Omar Gonzalez
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 t
On Fri, Feb 17, 2012 at 11:16 AM, Jun Heider 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 def
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 go
2012/2/17 Jun Heider :
>
> 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 con
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
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
w
On Monday, February 13, 2012, Alex Harui wrote:
> My understanding is we should not check in swcs
>
> Sent from my Motorola ATRIX™ 4G on AT&T
I believe that is correct too, sans the site files, I believe binary files
are not supposed to be checked in.
-omar
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
wrote:
> Gradle works with configurations to group dependencies. For GradleFx we
> have the merged, internal, external
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.eac
> From: Martin Heidegger [mailto:m...@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 tha
> From: Roland Zwaga [mailto:rol...@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 havin
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,
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, whils
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 wrote:
> The release
> From: Roland Zwaga [mailto:rol...@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
>
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
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 con
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
My understanding is we should not check in swcs
Sent from my Motorola ATRIX™ 4G on AT&T
-Original message-
From: Martin Heidegger
To: "flex-dev@incubator.apache.org"
Sent: Mon, Feb 13, 2012 11:20:55 GMT+00:00
Subject: Re: [DECISION] Unit Testing and Mocking Framew
On 13/02/2012 18:39, Omar Gonzalez wrote:
Here is the list of compatible licenses:
http://www.apache.org/legal/3party.html#category-a and what to do when
a dependency has incompatible licenses.
http://www.apache.org/legal/3party.html#options -omar
If I don't mistake it then the "binary form
On Mon, Feb 13, 2012 at 12:31 AM, Martin Heidegger wrote:
> +1
>
> But we still have a practical problem: Even when FlexUnit is given to the
> Flex SDK: Mockolate and
> its dependencies are not. Those would be the first "external" libraries
> that Apache Flex would rely
> on. Flex can not be built
+1
But we still have a practical problem: Even when FlexUnit is given to
the Flex SDK: Mockolate and
its dependencies are not. Those would be the first "external" libraries
that Apache Flex would rely
on. Flex can not be built without them.
In my mind: Open source is open source: That means A
+1 for FlexUnit and Mockolate, sounds like a plan
On 13 February 2012 01:04, Omar Gonzalez wrote:
> After the discussion we had around unit testing and mocking frameworks we
> had two very generous offers from Michael Labriola (FlexUnit) and Drew
> Bourne (Mockolate/hamcrest-as3).
>
> Michael is
31 matches
Mail list logo
