Hi again, The sample job was just an example to reproduce the problem / bug. What I was actually trying to do is having a second build job, with a different resource uri key.
About my motivation with the build system, it's just that as I pointed out everytime I need to do something it ends being painful. As I love Qooxdoo I would love to improve weaknesses in the framework (or what *I* perceive as weaknesses at least), thus this got me started thinking about this. Jean-Noel On Wed, Dec 16, 2009 at 3:44 PM, thron7 <[email protected]>wrote: > What is still not clear to me: What are you trying to achieve? What were > you trying to achive with your "sample" job? What is your motivation to > concern yourself with the build system? > > T. > > > > Removing the common extend did not help, but extending the build script > > did > > it, thanks. > > > > I thought a bit more about the current problems of the build system and I > > really think you should look at what Grails does. It is probably a very > > good > > example because Grails had exactly the same needs as Qooxdoo: there are > > some > > predefined jobs doing about the same thing (compiling source, compiling > > and > > building for production, etc), and IMHO the end result (eg the Grails > > script > > system) is quite good. (Btw, I would not say that in general of Grails; > eg > > I > > tend to like Qooxdoo much more than Grails for a number of reasons, but I > > do > > prefer the Grails build system :). > > > > I think the main strength of Grails build system is that it leverages an > > existing framework (Gant which is based on Ant) and extends it via code, > > and > > not parameters / config keys. This was really a brilliant idea because > you > > can extend predefined jobs as in Qooxdoo, but you also have the whole > > power > > underneath of Ant, with good documentation and many people familiar with > > it. > > And writin actual code is so much better than defining keys, because you > > are > > never limited, and it makes debugging much easier (just println a > variable > > if you are not sure of its value, etc). > > > > This obviously was not the case for Qooxdoo and changing that would > pretty > > much rewrite everything I guess, so this is not possible. However, apart > > from that, I think many interesting aspects from Grails can be taken and > > incorporated into Qx to resolve the problems I have spoke about. > > > > In particular, IMHO some ideas on what could be done: > > > > 1) There should be a "Settings" job that *all* other jobs include > > (currently > > that's kind of like the "common" job). Grails has that, with a documented > > list of all the possible settings / parameters. All macros that are > always > > defined in Qooxdoo should definitely be documented. > > 2) There should probably be only the concept of extension / inclusion, > not > > of overriding. In Grails you can use the predefined jobs in two ways: > > * first you can include them as prerequisite, which means that the script > > will be ran before your actual defined job; > > * second, if you need to somehow change a bit the behavior of an > > predefined > > job, you can hook at various places of the defined jobs to run your own > > code > > (like the "CompileStart" event, "CompileEnd" etc). There could be hooks > > for > > job specific settings so that you can change those if needed. (that also > > applies to global settings, instead of having a "let" key you would just > > hook into the Settings job and redefine the variables). > > 3) I am not sure how currently the macro are resolved, but it seems once > a > > macro is set it cannot be changed anymore. I think this causes a lot of > > confusions. Macros should just be variables, and their values changed as > > many time as you change the value of the variables. Eg, over the run of a > > job, the macro value evolves with each assignment. > > > > I am willing to help on this, file bugs, discuss a bit more over it via > > IRC, > > etc. > > > > Cheers > > Jean-Noel > > > > > > On Wed, Dec 16, 2009 at 1:22 AM, thron7 > > <[email protected]>wrote: > > > >> > >> > "let" : > >> > { > >> > "APPLICATION" : "custom", > >> > "QOOXDOO_PATH" : "/usr/local/opt/qooxdoo", > >> > "QXTHEME" : "custom.theme.Theme", > >> > "API_EXCLUDE" : ["qx.test.*"], > >> > "LOCALES" : [ "en", "fr" ], > >> > "CACHE" : "${TMPDIR}/cache", > >> > "ROOT" : "." > >> > }, > >> > > >> > "jobs" : > >> > { > >> > "sample": > >> > { > >> > "extend": ["common"], > >> > "compile-dist": > >> > { > >> > "code": > >> > { > >> > "format": false > >> > } > >> > } > >> > }, > >> > > >> > > >> > When I run ./generate.py build, the locales are correctly generated. > >> > But when I run ./generate.py sample, they are not: > >> > > >> > Why is this happening, I have the LOCALES macro correctly defined? How > >> > can I fix that? > >> > >> For one thing, it is not enough to define a macro, you also have to > >> *use* it in a job of your own. I wouldn't just extend "common" in the > >> hope that this will fix it. (It's actually easy to inspect what "common" > >> will provide you with in tool/data/config/base.json). A probably better > >> alternative would be to extend the "build-script" job (The config system > >> is designed such that you achieve best results when extending *existing* > >> jobs). > >> > >> But if you insist to roll your own job from the ground up, it is > >> necessary that you check all relevant keys and their sub-keys, to > >> provide sufficient information. Your main action key is a "compile-dist" > >> key, so you should check the reference for that key. Also mind the > >> "peer-keys" section that accompanies most of the key descriptions. As an > >> alternative, you could look into the "build-script" job in > >> tool/data/config/base.json, to see how it's done there. > >> > >> T. > >> > >> > >> > ------------------------------------------------------------------------------ > >> This SF.Net email is sponsored by the Verizon Developer Community > >> Take advantage of Verizon's best-in-class app development support > >> A streamlined, 14 day to market process makes app distribution fast and > >> easy > >> Join now and get one step closer to millions of Verizon customers > >> http://p.sf.net/sfu/verizon-dev2dev > >> _______________________________________________ > >> qooxdoo-devel mailing list > >> [email protected] > >> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel > >> > > > ------------------------------------------------------------------------------ > > This SF.Net email is sponsored by the Verizon Developer Community > > Take advantage of Verizon's best-in-class app development support > > A streamlined, 14 day to market process makes app distribution fast and > > easy > > Join now and get one step closer to millions of Verizon customers > > http://p.sf.net/sfu/verizon-dev2dev > > _______________________________________________ > > qooxdoo-devel mailing list > > [email protected] > > https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel > > > > > > > ------------------------------------------------------------------------------ > This SF.Net email is sponsored by the Verizon Developer Community > Take advantage of Verizon's best-in-class app development support > A streamlined, 14 day to market process makes app distribution fast and > easy > Join now and get one step closer to millions of Verizon customers > http://p.sf.net/sfu/verizon-dev2dev > _______________________________________________ > qooxdoo-devel mailing list > >
------------------------------------------------------------------------------ This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________ qooxdoo-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
