commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rahul Akolkar <>
Subject Re: [all] preparing initial commit
Date Wed, 19 May 2010 18:29:45 GMT
On Wed, May 19, 2010 at 11:43 AM, Jacob Beard <> wrote:
> 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:
> <snip/>
> 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.
> <snip/>
> 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.
> <snip/>
> Here's my proposed project structure:
> /
>        src/
>        test/
>        lib/
>                java/
>                test-java/
>                javascript/
>                test-javascript/
> 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
> scxml.cgf.js
> scxml.cgf.analysis
> 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.

Please put the above in a README along with your check in.

Two questions:
 * How do you build the lib/java and lib/test-java code?
 * How do you intend to download the dependencies in, for example,
"lib/test-javascript would contain JavaScript libraries"? For example,
an 'ant getdeps' target (some may be svn:externals, probably not all?)

Perhaps this will be clear when we can look at what you have set up.

> 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
> technology.

I think its best to start with what you have right now. Lets get it
out, have people look at it -- I'd like to get a better understanding
by looking at the setup and trying things out.

If we decide that some changes make sense based on feedback, we can do
those kind of project SVN reorgs fairly easily. Thanks.


> Please let me know what you think about this. Thanks,
> Jake
> [0]

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

View raw message