commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rahul Akolkar <rahul.akol...@gmail.com>
Subject Re: [all] preparing initial commit
Date Wed, 19 May 2010 03:08:38 GMT
On Tue, May 18, 2010 at 6:13 PM, Jacob Beard <jbeard4@cs.mcgill.ca> wrote:
> Hi,
>
> Thanks to everyone for the feedback. In this email, I'm going to
> describe the structure of my project, the current build system, and
> try to propose solutions to some of the issues that have been raised.
>
> The overall goal of SCXMLcgf/js is to construct an SCXML-to-JavaScript
> compiler. The compiler should take one or more scxml source files, and
> produce JavaScript code that may be executed in a web browser, or in a
> shell environment using Mozilla Rhino. Additionally, the compiler
> itself should be portable, so that it may be run in a web browser or
> from the command line using Rhino. The code I have produced so far
> only runs from the command line, but decisions that are made going
> forward should attempt to ensure portability across both environments.
>
<snip-project-intro/>

Yes please, a portable compiler that runs in a web browser would
enable us to place SCXML markup in the web page where it needs to
execute.


> I have never used Maven, and so did not originally consider this as an
> option, but I did consider using Ant. I have used Rhino in conjunction
> with Ant on previous projects, but I decided against it for this
> project, because I felt I would be able to develop this nontrivial
> build logic more quickly by writing it in JavaScript. This allowed me
> to simply pass around native JavaScript data structures as I wired
> things together, and made things like looping straightforward.
>
<snip-build-tasks/>

At some point, we probably want a first-class build for some of these
tasks, but that can be a bit of a disruptive process for your project
work. Between the two approaches:

 * Design a build system (be it Ant and Maven), port your project to
it, commit code according to new layout, continue work
 * Commit code now, continue project work and keep thinking about
build system as a background thread

I'd take the latter.


> First, what role, if any, should Maven play in this project?
>
> I have never worked with Maven, so my perspective on this is based on
> an afternoon's research. I feel that Maven would, in theory, be useful
> to this project, but it would take a lot of work in order to get it to
> a point where it could be used, as plugins would need to be written to
> interact with the JavaScript front-end through stdin. Also, many
> portions of Maven's default lifecycle, such as compilation and
> packaging, are not really relevant to the project at this point. The
> main things that requires automation in the project, right now, are
> unit and performance testing, and, potentially, downloading of library
> dependencies. I'm not sure if Maven adds value when it comes to
> downloading external libraries, but it's not difficult for me to think
> about how this could be achieved using Rhino and a custom build
> script. My preference would be to continue using the project's current
> build system.
>
<snap/>

Sure, once you get a chance to commit the code, we'll be able to try
it out and have a better idea. Based on that, if some of the Maven
experts offer good advice, we can consider the implications of such a
build port then.


> The next question is, should external libraries be checked into the
> main source tree, or should they downloaded as part of a build script,
> or via svn:externals?
>
> It sounds like it would be desirable to download external libraries,
> rather than checking them in, and I think this is fine. It should be
> noted, however, that this decision will have an impact on the other
> technology that will be used in the project. Specifically, this
> decision will impact selection of a library for module loading.
>
> Here's just a bit of background on this: because JavaScript does not
> have native language features for module loading, it relies on
> libraries to provide this functionality. So far, in the project, I
> have been using the load() function provided Rhino to define
> dependencies between modules. Unfortunately, this approach has two
> disadvantages which make it inappropriate going forward: it is not
> portable to the browser environment, and it does not know where it is
> executing in the filesystem, which makes loading resources via
> relative paths awkward.
>
> I have investigated two libraries for module loading: Dojo, and
> RequireJS.
<snip/>

Also take a look at the YUI Loader if you haven't already:

  http://developer.yahoo.com/yui/yuiloader/


> I initially used Dojo, because I was already familiar with
> it, and am already using part of Dojo for unit testing. Unfortunately,
> the Dojo module system has a limitation that would make the
> downloading of external libraries difficult, which is that, for a
> JavaScript module to be used by dojo, it must have a
> "dojo.provide(<modulename>)" call in the file. For the majority of
> these JavaScript libraries, this means that the file must be modified
> to include this call. Dojo would therefore require JavaScript
> libraries to be modified, and checked in.
>
> RequireJS, on the other hand, does not impose this constraint, and is
> better-suited to the purposes of this project in other ways, which I
> can describe later if anyone is interested.
>
<snap/>

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.


> To summarize, my feeling on this is that it would be preferable to use
> RequireJS as opposed to Dojo for module loading, and that external
> libraries should be downloaded by a build script, or via
> svn:externals, as opposed to being checked in.
>
> If the above decisions seems reasonable (that Rhino be used for the
> build system, RequireJS as a module loader library, and external
> dependencies downloaded by the build script),
<snip/>

They certainly seem reasonable for getting started. If better
alternatives come to our attention, lets discuss then.


> then my next questions
> would be about the about the project structure. Right now, all
> artifacts are mostly located in one directory (as I said, Rhino's load
> function makes relative paths tricky), so there is a great deal of
> flexibility as to how this could be implemented. Would it make sense
> to use something similar to a standard m2 project layout? Would this
> help or hinder developer comprehension if maven is not being used?
>
<snap/>

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.

Thanks for describing the current state of the project in detail.

-Rahul


> Thanks again for the feedback. I look forward to hearing what you think,
>
> Jake
>
<snip-tail/>

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


Mime
View raw message