Forums

I've been doing this for more than a year, and now it occurred to me that I may be facing trouble in the future if I continue building my modules the same way without checking what the future may bring.

First, my need may seem bizarre to people here: I need to serve YUI locally, and instead of configuring loader to pull stuff from various places, I chose to deploy my modules inside the YUI tree using the YUI builder (and reaped handsome benefits, having done that). At around the time of 3.1 I (kinda) figured out how builder works, stuck a bunch of modules into the YUI source tree, and wrote a combo server that works exactly like the combo server at CDN. It worked great, and still does.

The first problem I encountered was that it took ant more than a minute to build just one of my modules. I can't wait that long.

So the first question is, why ant? I get the sense that now there is an effort underway to phase it out, and recently I heard a talk about Buildy by Eamon Brosnan. It seems like the vector is pointing in the right direction. But when I started the project, I could not wait and wrote a bunch of Makefiles to do the job. I don't have a generic way of setting up any arbitrary module with appropriate Makefiles, but I can share a few examples, if anybody is interested. It is super-easy to replace an ant job with a Makefile (or several), once you know where things are supposed to go.

Then, with 3.3 (if I am not mistaken), the module structure has changed; in particular, the way submodules are laid out and loaded. I am under the impression that the submodule-level ant properties are simply ignored, with all dependency information available in meta/*.json. If that is so, why all module authors are still maintaining these files?

Looking ahead, are there any radical changes in the pipeline? If there is an alternative build system on the horizon, is it going to be able to do dependency resolution, or should I stick to my Makefiles?

Stockpile is indeed a very able combo server -- thank you for pointing it out. I will try it in a new application I am building from scratch.

However, the problem at hand is not serving the code. At work, I am limited to using the cherokee/uwsgi/python server solution in an existing application, the front end to which I am extending with YUI. The whole thing is packaged as a mac app with a requirement to be able to work off-line, and there is penalty for bringing new things in and creating dependencies. Also, the idea of having multiple servers using different ports does not fly well with the application developers, so I have to serve YUI and my modules off the same server that provides the API. That is not a problem; I have written a simple combo server that works in this environment and plays well with loader.

Because this solution is very basic, it kind of it invites me to mix my modules with YUI, so they are served off the same file tree and are packaged using the same rules. And I like how things are packaged in YUI; it allows me to organise my code in modules in a very convenient way. I like it that even the styles are divided into functionally important ones and skin styles, which are kept in separate files and out of the way. The only thing I don't like is deploying all that stuff with ant scripts; so I replaced them with Makefiles. Because these makefiles are based on my current knowledge of server-side module layout, I wonder whether they are in danger of becoming invalid soon. I did have to fix them once during the past year; I can keep doing that if I have to, but if there are definite plans for making a new build system or using new file layouts for modules, I would appreciate a heads-up.