It's not possible to keep metadata when running FlexUnit tests

[SlevinBE]

Currently the Test task doesn't support keeping the metadata, which makes it impossible to run tests.

[Yarovoy]

I just want to describe this issue more detailed.

Suppose you have SWC library project which declares some additional custom metadata tags (for example, Copyable and Cloneable) by using "-keep-as3-metadata+=Cloneable,Copyable" compiler option.

…
additionalCompilerOptions = [
        '-keep-as3-metadata+=Cloneable,Copyable'
]

type = 'swc'
…

If you try to test your project's code which uses this metadata tags through unit-tests and "gradle test" task you will be fail because "-keep-as3-metadata+=Cloneable,Copyable" option will not be passed to the compiler when it compiles project's source classes in test scope.

[RIAstar]

I might be wrong, but did we not discuss the possibility of adding compiler options specifically for the test task?
What would such a feature look like?

additionalTestCompilerOptions = []

and so on for any option you might want to override for testing?

Or perhaps something like:

testConfig { 
    additionalCompilerOptions = []
    ...
}

I'm just thinking out loud.

[SlevinBE]

Yes, that's how it will look like on the outside. But in GradleFx we'll have to rework the Test task since it's delegating the compilation to the FlexUnit ant task, which has no parameter to specify compiler options. So instead of delegating the compilation to the ant task, we should do it ourselfs and then just provide the swf to the ant task.

[RIAstar]

Let's hope the ant task takes a compiled swf as an argument. Or did you already verify that?

[SlevinBE]

Yes, you can provide your own swf to the ant task.

[Yarovoy]

Maybe it would be better to implement the following behaviour in the Test task. By default compiler in test scope will inherit options from additionalCompilerOptions but we keep a way to fully override it with additionalTestCompilerOptions. This is only a suggestion.

The other way is dividing of configuration on two (or three) scopes — production and test (and, maybe, development) — by using closures:

configuration {
    development { … }
    test { … }
    production { … }
}

I prefer a second way as more evident and less error-prone.

[RIAstar]

I like the notion of scopes. I also think both approaches could be combined:
declarations outside a scope are default and they can be overriden inside a scope closure.

example:

additionalCompilerOptions = ["-defaultOption"]

configuration {
    development { 
        //uses default
    }

    test {
        additionalCompilerOptions = ["-testOption"]
    }

    production {
        //uses default
    }
}

[Yarovoy]

Hmm, I like your suggestion, Maxime.

[RIAstar]

Here's another related issue on StackOverflow: http://stackoverflow.com/questions/14628726/how-do-i-load-rsl-libraries-during-unit-tests-with-flexunit-using-gradlefx

Dependencies defined as RSL in the main app are not used in the unit-test application.

[SlevinBE]

While the configuration style looks pretty, I'm not entirely sure it makes sense.

Configurations are used to group dependencies, not for configuration usages (see http://www.gradle.org/docs/current/dsl/org.gradle.api.artifacts.Configuration.html).
Another reason is that we can't know which environments the user will have. It can be only dev & test, or it can be dev, test, prod or it can be dev, test, staging, prod etc.
There is a way to support multiple environments (see http://mrhaki.blogspot.be/2009/11/gradle-goodness-using-properties-for.html) but that's not related to this issue.

Imo it's also just a more verbose way to what we have now (the default config and the test{} subconfig) without adding any benefits. Unless I'm missing something :)

[RIAstar]

Well the idea was to add as many configurations as you want; not just the default and 'test'. As an example use case: I need to make a build with mock data embedded to be able to give a demonstration to a customer without a server (or even let him play with it a little while). This other build requires additional source folders, as well as additional dependencies and a different output name, when compared to the default production build. I've been able to work my way around this, but it is a workaround.

In the meantime - i.e. after I wrote that previous comment - I've been digging around a little. So I agree with you that what I proposed in that comment, is in conflict with how Gradle works. As you mentioned, the existing Configuration class has a different purpose.
But not entirely. Gradle configurations can be used to create different outputs. rklaren gave an example of this in another thread; this example doesn't work with GradleFx, but it does with the Java plugin for instance.

The reason is this: using the Java plugin, every Configuration is tied to a different output. compile produces production classes; testCompile depends on compile and produces test classes; additional plugins add other Configurations with other outputs; with the approach as described by rklaren you can define your own output.
When using GradleFx, all available Configurations combined (internal, external, merged, rsl, theme) produce one single output. Or two if you add the test scope. They are all "facets" of one big configuration. The test scope only works because the other dependencies can be merged anyway: it doesn't matter if you get a big swf for running unit tests. But it does matter if you want a different kind of output.

So as a conclusion, I'm afraid that it is impossible to bring this feature to GradleFx in the same way as it exists in the Java plugin. Not without completely changing the way things work anyway :(

So what are the options:

• we don't implement the feature; in this case we should provide an example of a viable workaround; I can already provide this, since I already did it in a real-world situation
• we implement the feature in a different way than other plugins
• we implement the feature as found in other plugins and have to throw everything upside-down

Waw, I made this sound a lot more dramatic than I meant to, so let me throw in a ;) to lighten things up.

[RIAstar]

Come to think of it, now that I wrote that "facets of a configuration" thing down. Would it not be possible to do something like this?

configuration {
    //custom configuration
    mockCompile.extendsFrom compile
}

dependencies {
    compile {
        merged 'someLib'
        rsl 'someOtherLib'
    }

    testCompile {
        //depends on compile
        //merged by default
        'flexUnitLib'
    }

    mockCompile {
        //depends on compile
        merged 'myMockLib'
    }
}

[SlevinBE]

So using configurations (merged, rsl,..) inside configurations (compile, testCompile). I'll do some research to see if this is possible.

[RIAstar]

On a side note, I just wrote a blog post addressing the multiple configurations issue:
http://blog.riastar.net/2013/03/28/gradlefx-multiple-configurations/

[rbarreca]

What are your guys' current thoughts on the best way to get the compiler options to the test task? We've run up against this and were potentially going to try to help with some dev effort (if that's the need), but not sure what the current thinking is.