it's so funny how much rumour circulates around this issue... i posted a link in this thread to the corresponding manual section which the op might have chosen to ignore. oh well...
> to be honest, I have never understood the rationale why the source version > should not be used with a web server the rational is very simple, and it's *not technical*: running the source version from disk is what we *support*. it's in our programming model. that doesn't mean you cannot do it differently, but we cannot support each and every possible scenario. we try to give hints, but we don't fight for it. if you get it running otherwise - fine. if we change something that works in the from-disk scenario, but breaks yours, your on your own. it's that simple. > - I have never had any problems with > this setup, it's not difficult, if you get the key issue, like Derrell put it, and know what to do on your file system and web server config. but this is not generally true. > as long as you put the CACHE into the source tree itself. > now, this line on it's own is nearly wrong, and probably adds as much confusion as it might provide help. the truth is, slightly re-phrasing what Derrell wrote: all libraries of your qooxdoo application (your app is a library, the framework is a library, any contrib is a library,...) must be reachable from the web server, and relative paths between them on the file system must result in valid URL paths when served through the web server. with apache, there are several ways of achieving this (one of which is using aliases, which hasn't been mentioned so far). in the case of contrib libs referenced with the "contrib://" pseudo protocol, that means your download path has to be reachable from your web server in the above sense, and pointing the CACHE config macro into your source tree is a *very coarse* approach to achieve this. the download path can just as well be the default location (<system-tmp-dir>/cache/downloads), but can be any other path if you adapt the config key "cache/downloads" for your build jobs accordingly. the *compile* cache has nothing to do with it, so there is no need to shuffle it around (which you do when you change CACHE). t. ------------------------------------------------------------------------------ Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev _______________________________________________ qooxdoo-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
