commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jacob Beard <>
Subject Re: [all] preparing initial commit
Date Wed, 19 May 2010 15:43:21 GMT
Rahul, thanks for the feedback.  Please see my replies below:

On Tue, May 18, 2010 at 11:08 PM, Rahul Akolkar <> wrote:
> Also take a look at the YUI Loader if you haven't already:

I have looked into the YUI loader. The API is similar in style to
RequireJS. Unfortunately, I couldn't find any documentation that
suggested it could be used under Rhino, so this made it inappropriate
for this project.

> Yup, either RequireJS or YUI Loader seems to make sense (I haven't
> used the former).
> Though I imagine we'd be producing a complete rollup of the compiler at the end.

Yes, and this is one way in which Dojo is useful: it comes with
tooling for creating custom builds, so that all modules are combined
into one JavaScript file, and the code is minimized. RequireJS is
supposed to have similar functionality, but I've never used it, so
this remains to be seen.

> Right, we probably want more structure than a single directory and the
> m2 layout will seem familiar. OTOH, the m2 layout means little if it
> isn't an m2 build. So I'd say pick something to your liking and we can
> always move stuff around in SVN later as needed.

Here's my proposed project structure:



lib/java contains the Java libs needed to run the compiler in a shell
environment. Right now, I think only Rhino would go there.

lib/test-java contains the Java libs needed for testing. Right now, I
think only Selenium is needed there.

lib/javascript contains JavaScript libraries needed at runtime. Right
now, I think this would be RequireJS and beautify.js.

lib/test-javascript would contain JavaScript libraries needed for
testing. This would contain dojo and env.js.

Here's my proposed module structure, which would go in src/


scxml.cgf would contain code that could pertain to multiple language
backends. So, it would contain the front-end to the command-line, the
class responsible for initially pulling data out of the SCXML DOM,
general utils, etc.

scxml.cgf.js would contain the classes for the JavaScript compiler backend. would contain the build script, and associated helper modules.

scxml.cgf.analysis would contain modules relating to performance analysis.

You may note that one weird thing about this is that the build script
is located in the regular package structure, when normally it is
located at the root of the project. The reason for this is that, in
order for the build script to import other modules, the module system
must first be bootstrapped[0]. This is a common concern between the
compiler and the build script, and so it makes sense to isolate this
concern into a single top-level script, which I call runner.js.
runner.js bootstraps the module system, and then runs another script,
which it is given as a command-line argument. There will then be a
bash script in the root of the project, called, which is
responsible for calling runner.js, which then calls the real build
script in I spent some time thinking about this when
first hooking up the module system with Dojo, and I think it is the
most elegant possible approach, given the constraints of the

Please let me know what you think about this. Thanks,



To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message