commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dennis Lundberg <denn...@apache.org>
Subject Re: [all] preparing initial commit
Date Sat, 22 May 2010 10:51:55 GMT
On 2010-05-19 17:43, Jacob Beard wrote:
> Rahul, thanks for the feedback.  Please see my replies below:
> 
> On Tue, May 18, 2010 at 11:08 PM, Rahul Akolkar <rahul.akolkar@gmail.com> wrote:
>>
>> Also take a look at the YUI Loader if you haven't already:
>>
>>  http://developer.yahoo.com/yui/yuiloader/
>>
> <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/

Hi Jacob and welcome aboard

I spend a lot of time over in Maven land, and like to give some feedback
on your proposed build and structure.

Even though Maven may not be the tool used to build your project in the
end, it will be a benefit to use Maven's standard directory layout [1]
when you structure the code. This will help others Commons developers to
quickly identify the different parts of your project.

My experience with developing in JavaScript is minimal, but I do think
that your project can benefit from using Maven. The two areas I spot
right away is downloading dependencies and packaging the project.
Another thing that you should have a look at is the JavaScript Maven
Tools [2]. These don't yet have a release, but if you try them out and
feel that they work for your project, I can help make a release happen
for you. The tools also proposes extensions to Maven's standard
directory layout, specifically for JavaScript development.

With that said I propose that you use the standard layout described at
[2] even if you decide not to use Maven as a tool for the project. This
layout does not have a specific location for dependencies, i.e. your
/lib directory, because those are stored outside of the project
structure in a project build using Maven. If you decide to not use Maven
then /lib is a good place to put your dependencies in.

If you have any questions regarding Maven don't hesitate to contact me.

[1]
http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html
[2] http://mojo.codehaus.org/javascript-maven-tools/index.html

> 
> 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.build
> 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.
> 
> scxml.cgf.build 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 build.sh, which is
> responsible for calling runner.js, which then calls the real build
> script in scxml.cgf.build. 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.
> 
> Please let me know what you think about this. Thanks,
> 
> Jake
> 
> 
> [0] http://requirejs.org/docs/api.html#rhino
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
> 
> 


-- 
Dennis Lundberg

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message