flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christofer Dutz <christofer.d...@c-ware.de>
Subject AW: [FLEXJS][FALCONJX] Builds and CI (was Re: AW: AW: AW: AW: [DISCUSS] Release Apache FlexJS 0.5.0)
Date Tue, 06 Oct 2015 07:04:34 GMT

Yes it would be a separate repo ... as you could run the "testsuite" against falcon without
wanting to have the sdk or vice versa and this would destroy the circle (at least one of them).

I would do this, but I would do it thoroughly ... meaning I would also cleanup the build itself.
Starting with streamlined goal names (currently the target names are a mess ... I'd streamline
them similar to the phases of a maven build: clean, compile, test, integration-test, package,
install, deploy, ...).

And one thing will be that I will only be doing this on the ASF Jenkins, as this is - in my
belief - the only true place for the build to be. Im fine with other Jenkins instances (I
have a Teamcity running for my stuff), but there has to be one on the ASF machines.


Von: Alex Harui <aharui@adobe.com>
Gesendet: Dienstag, 6. Oktober 2015 08:37
An: dev@flex.apache.org
Betreff: Re: [FLEXJS][FALCONJX] Builds and CI  (was Re: AW: AW: AW: AW: [DISCUSS] Release
Apache FlexJS 0.5.0)

Renaming the thread to match the earlier fork.

On 10/5/15, 10:34 PM, "Christofer Dutz" <christofer.dutz@c-ware.de> wrote:

>Well ... as you asked the question ... ;-)
>A real test should be independent of the implementation it tests. So if
>in both cases (mxml and falcon) the same testsuite should be used. Only
>this way they actually test if the compiler tests the same thing.
>So in this case, I think the solution would be to take the testsuite out
>of both and merge them together in one testsuite ... the you can build
>"flex-sdk" and "falcon" and then run the testsuite against the compiler
>you like.

Are you thinking a different repo for the tests, or just not having “ant
all” run the tests?

>Actually everywhere you have cycles, you can usually resolve them by
>"merging the entire cicle into one" or by "splitting up the cycle" ... I
>would strongly suggest splitting up, as you should only use merging if
>you are unable to split it up cause the code is so mixed up, that it
>won't split (Actually have come across this several times in multiple
>projects) ;-)

Splitting sound better to me as well.  Are you envisioning more than just
choosing which ant targets to run in the right order?

Is this going to end up being roughly what Justin suggested as well?

No objections from me if someone wants to take a shot at it.  Does the
release need to wait for this?  I hope not.


View raw message