> "let" :
> {
> "APPLICATION" : "ifsr",
> //This avriable is now set via a macro definition
> // "QOOXDOO_PATH" : "os.getenv(QOOXDOO_HOME)",
I presume, this means you are passing it on the command line, with the
-m option when invoking the generator, right?! - I believe you could
leave the config unchanged in this point, as the command line option
takes precedence.
But I'm wondering why you are doing this anyway. You are not switching
between qooxdoo versions, are you?! Because you would be using the same
tool chain in any case, and combining that with framework classes from
another version could result in problems (albeit not those we're
discussing right now).
> "jobs":
> {
> "testrunner::build-tests-script":
> {
> "add-script":[ {"uri":"../resource/ifsr/script/jshamcrest-source.js"},
> {"uri":"../resource/ifsr/script/jsmockito-source.js"}]
> }
> }
This looks good from a config point of view. What concerns me are again
your 'uri's: If you have an otherwise normal test app structure,
"../resource/..." will lead you to nowhere. But I think we have been at
this point before, and it wouldn't affect generation anyway (you would
only get misbehaviour at run time).
So, to get futher the generation issue, please run two commands and post
their output:
First, run "./generate.py info".
Then, run your usual command with which you build the "test" job, but
add the -w command line flag. Capture both stdout and stderr (e.g. with
"./generate.py test > log.txt 2>&1") and post the output.
T.
------------------------------------------------------------------------------
Create and publish websites with WebMatrix
Use the most popular FREE web apps or write code yourself;
WebMatrix provides all the features you need to develop and
publish your website. http://p.sf.net/sfu/ms-webmatrix-sf
_______________________________________________
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
