You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Jacob Beard <jb...@cs.mcgill.ca> on 2010/05/17 05:25:29 UTC
[all] preparing initial commit
Hi,
I'm currently working to prepare the initial commit for my Google
Summer of Code project. I have a quick question regarding external
libraries. My project currently uses a few libraries which are
licensed under liberal, non-copyleft licenses. A list of these
libraries and their associated licenses is as follows:
Mozilla Rhino - MPL
Dojo JavaScript toolkit - BSD/AFL dual license
Selenium - Apache 2.0 License
js-beautify - something a bit non-standard:
http://github.com/einars/js-beautify/blob/master/license.txt
json2 - Public Domain
Is it possible to include these libraries in the source tree of my project?
Also, for a library like dojo, which is large (about 100MB,
uncompressed), and composed of many small files, would it be better to
include a compressed zip file in the library directory, with
instructions in the README for the user to unzip it, or would it be
better to use an svn:externals svn property to point to the dojo
source tree, so that it is automatically checked out (probably from a
specific tag), when the source tree is checked out.
Please let me know what you think. Thanks,
Jake
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [all] preparing initial commit
Posted by Luc Maisonobe <Lu...@free.fr>.
Le 17/05/2010 08:41, Jörg Schaible a écrit :
> Henri Yandell wrote:
>
>> Interesting questions - we've been Maven based for so long that
>> putting dependencies in SVN hasn't happened for a while.
>>
>> What's your build structure, and how are the below used?
>>
>> I like the notion of the svn:external for Dojo.
>
> Do you ever intent to make a release? subverison tags and externals are a
> no-no.
>
>> Otherwise I'd be
>> tempted to have it in zip format and have the build unpack it from the
>> zip into a directory that 'clean' removes [whatever your equivalent of
>> 'target', 'build' or 'private' is].
>
> Any chance to convert this project also to Maven instead?
At least with maven with have a strong confidence the project can be
rebuild at (almost) any time in the future. Are the published Dojo
source/binaries mirrored on some well-known archive ?
Luc
>
> - Jörg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [all] preparing initial commit
Posted by Henri Yandell <fl...@gmail.com>.
On Sun, May 16, 2010 at 11:41 PM, Jörg Schaible <jo...@gmx.de> wrote:
> Henri Yandell wrote:
>
>> Interesting questions - we've been Maven based for so long that
>> putting dependencies in SVN hasn't happened for a while.
>>
>> What's your build structure, and how are the below used?
>>
>> I like the notion of the svn:external for Dojo.
>
> Do you ever intent to make a release? subverison tags and externals are a
> no-no.
They're only a no-no if you point to a non-tag.
>> Otherwise I'd be
>> tempted to have it in zip format and have the build unpack it from the
>> zip into a directory that 'clean' removes [whatever your equivalent of
>> 'target', 'build' or 'private' is].
>
> Any chance to convert this project also to Maven instead?
Most are JavaScript, I'm assuming Maven + JavaScript don't have much
history, but maybe I'm wrong.
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [all] preparing initial commit
Posted by Jörg Schaible <jo...@gmx.de>.
Henri Yandell wrote:
> Interesting questions - we've been Maven based for so long that
> putting dependencies in SVN hasn't happened for a while.
>
> What's your build structure, and how are the below used?
>
> I like the notion of the svn:external for Dojo.
Do you ever intent to make a release? subverison tags and externals are a
no-no.
> Otherwise I'd be
> tempted to have it in zip format and have the build unpack it from the
> zip into a directory that 'clean' removes [whatever your equivalent of
> 'target', 'build' or 'private' is].
Any chance to convert this project also to Maven instead?
- Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [all] preparing initial commit
Posted by Henri Yandell <fl...@gmail.com>.
Interesting questions - we've been Maven based for so long that
putting dependencies in SVN hasn't happened for a while.
What's your build structure, and how are the below used?
I like the notion of the svn:external for Dojo. Otherwise I'd be
tempted to have it in zip format and have the build unpack it from the
zip into a directory that 'clean' removes [whatever your equivalent of
'target', 'build' or 'private' is].
Hen
On Sun, May 16, 2010 at 8:25 PM, Jacob Beard <jb...@cs.mcgill.ca> wrote:
> Hi,
>
> I'm currently working to prepare the initial commit for my Google
> Summer of Code project. I have a quick question regarding external
> libraries. My project currently uses a few libraries which are
> licensed under liberal, non-copyleft licenses. A list of these
> libraries and their associated licenses is as follows:
>
> Mozilla Rhino - MPL
> Dojo JavaScript toolkit - BSD/AFL dual license
> Selenium - Apache 2.0 License
> js-beautify - something a bit non-standard:
> http://github.com/einars/js-beautify/blob/master/license.txt
> json2 - Public Domain
>
> Is it possible to include these libraries in the source tree of my project?
>
> Also, for a library like dojo, which is large (about 100MB,
> uncompressed), and composed of many small files, would it be better to
> include a compressed zip file in the library directory, with
> instructions in the README for the user to unzip it, or would it be
> better to use an svn:externals svn property to point to the dojo
> source tree, so that it is automatically checked out (probably from a
> specific tag), when the source tree is checked out.
>
> Please let me know what you think. Thanks,
>
> Jake
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [all] preparing initial commit
Posted by Jacob Beard <jb...@cs.mcgill.ca>.
Thanks all for the replies.
Dennis, Maven for JavaScript sounds really promising, I'll definitely
look into it.
If anyone is interested in looking at the project, I've my the initial
commit, which you can find here:
https://svn.apache.org/repos/asf/commons/sandbox/gsoc/2010/scxml-js/trunk/
Thanks,
Jake
On Sat, May 22, 2010 at 7:23 AM, sebb <se...@gmail.com> wrote:
> On 22/05/2010, Dennis Lundberg <de...@apache.org> wrote:
>> 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 <ra...@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
>
> I'd just add that Maven is also used to build all the Commons websites.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [all] preparing initial commit
Posted by sebb <se...@gmail.com>.
On 22/05/2010, Dennis Lundberg <de...@apache.org> wrote:
> 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 <ra...@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
I'd just add that Maven is also used to build all the Commons websites.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [all] preparing initial commit
Posted by Dennis Lundberg <de...@apache.org>.
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 <ra...@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
Re: [all] preparing initial commit
Posted by Rahul Akolkar <ra...@gmail.com>.
On Thu, May 20, 2010 at 1:07 AM, Jacob Beard <jb...@cs.mcgill.ca> wrote:
> On Wed, May 19, 2010 at 2:29 PM, Rahul Akolkar <ra...@gmail.com> wrote:
>> 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.
>>
> </snip>
>
> Great. I have the module system and directory structure all set up
> with RequireJS, so now I'm just tying up the last loose ends before I
> send you the code for review. These are:
>
> * add a get-dep task to the build script
> * write a README
> * add license headers to all files
> * make sure that each module is at least minimally documented
>
> Can you think of anything else I should be aware of?
>
> I'm aiming to have this ready by tomorrow evening. Should I send you
> the code as a zip via email, or should I check it directly into SVN?
>
<snip/>
Please check it in (to your project trunk).
If you haven't already, before you check in, please update your SVN
client auto-props [1] and also include any filename extensions not
listed at [1] that you may be using, as appropriate.
-Rahul
[1] http://www.apache.org/dev/svn-eol-style.txt
> Please let me know what you think. Thanks,
>
> Jake
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [all] preparing initial commit
Posted by Jacob Beard <jb...@cs.mcgill.ca>.
On Wed, May 19, 2010 at 2:29 PM, Rahul Akolkar <ra...@gmail.com> wrote:
> 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.
>
</snip>
Great. I have the module system and directory structure all set up
with RequireJS, so now I'm just tying up the last loose ends before I
send you the code for review. These are:
* add a get-dep task to the build script
* write a README
* add license headers to all files
* make sure that each module is at least minimally documented
Can you think of anything else I should be aware of?
I'm aiming to have this ready by tomorrow evening. Should I send you
the code as a zip via email, or should I check it directly into SVN?
Please let me know what you think. Thanks,
Jake
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [all] preparing initial commit
Posted by Rahul Akolkar <ra...@gmail.com>.
On Wed, May 19, 2010 at 11:43 AM, Jacob Beard <jb...@cs.mcgill.ca> wrote:
> Rahul, thanks for the feedback. Please see my replies below:
>
> On Tue, May 18, 2010 at 11:08 PM, Rahul Akolkar <ra...@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.
>
<snip/>
OK.
>> 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.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.
>
<snap/>
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 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.
>
<snip/>
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.
-Rahul
> 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
Re: [all] preparing initial commit
Posted by Jacob Beard <jb...@cs.mcgill.ca>.
Rahul, thanks for the feedback. Please see my replies below:
On Tue, May 18, 2010 at 11:08 PM, Rahul Akolkar <ra...@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/
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
Re: [all] preparing initial commit
Posted by Rahul Akolkar <ra...@gmail.com>.
On Tue, May 18, 2010 at 6:13 PM, Jacob Beard <jb...@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
Re: [all] preparing initial commit
Posted by Jacob Beard <jb...@cs.mcgill.ca>.
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.
The project is currently composed of the following artifacts:
* the compiler: comprises six classes, each in their own .js file
* unit tests: comprises a test SCXML file, and a unit test script
* performance tests: comprises an SCXML file, a script that measures
performance of compiled js code, and a script that analyzes the
captured performance data
There is also an automation script written in JavaScript, which is
designed to be run under Rhino, which automates unit and performance
testing. The compiler is written entirely in JavaScript, and so a
compilation step is not required. Nevertheless, the automation script
does a lot. To illustrate this, here is a page from my notes which
illustrates the tasks performed in order to run performance tests:
http://jacobbeard.net/Note1.pdf
What this note says is that each test case can have many performance
tests. Each test case and each backend should be run through the
compiler to create JavaScript implementations. Each generated js
implementation and performance test are combined to create test html
files. Each test html file is then opened in all browsers on the
system, and data is captured in order to derive the final performance
results. These results are then passed to the analysis script to
create a summary of the results.
Unit testing is similar process.
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.
Here is a summary of the tasks currently performed by the automation script:
- clean: deletes the build directory
- init: creates the build directory
- genJavaScript: generates JavaScript from unit and performance test SCXML
- genPerformanceTestHtml: generates an HTML file for each performance
test script and each target JavaScript file
- runPerformanceTestsWithSelenium: uses Selenium to open generated
performance test HTML files in browsers that are available on the
system, and capture benchmark data from them
- doPerformanceAnalysis: sends captured benchmark data to the
performance analysis script
- genUnitTestHtml: generates an HTML file for each performance test
script and each target JavaScript file
- runUnitTestsWithSelenium: uses Selenium to open generated unit test
HTML files in browsers that are available on the system, and capture
unit test results from them
- runUnitTestsWithRhino: runs unit tests with Rhino.
So, that concludes the introduction to my project and its build
system. I'll now attempt to answer some of the questions that have
been raised.
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.
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. 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.
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), 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?
Thanks again for the feedback. I look forward to hearing what you think,
Jake
On Tue, May 18, 2010 at 1:38 AM, Henri Yandell <fl...@gmail.com> wrote:
> On Mon, May 17, 2010 at 11:21 AM, Rahul Akolkar <ra...@gmail.com> wrote:
>> On Sun, May 16, 2010 at 11:25 PM, Jacob Beard <jb...@cs.mcgill.ca> wrote:
>>> Hi,
>>>
>>> I'm currently working to prepare the initial commit for my Google
>>> Summer of Code project. I have a quick question regarding external
>>> libraries. My project currently uses a few libraries which are
>>> licensed under liberal, non-copyleft licenses. A list of these
>>> libraries and their associated licenses is as follows:
>>>
>>> Mozilla Rhino - MPL
>>> Dojo JavaScript toolkit - BSD/AFL dual license
>>> Selenium - Apache 2.0 License
>>> js-beautify - something a bit non-standard:
>>> http://github.com/einars/js-beautify/blob/master/license.txt
>>> json2 - Public Domain
>>>
>> <snip/>
>>
>> I'll first address the licenses and then get to the how to include the
>> libraries bit.
>>
>> You may have seen the following categorization of licenses we use
>> (Category A is generally easier to incorporate than B):
>>
>> http://www.apache.org/legal/3party.html#category-a
>>
>> http://www.apache.org/legal/3party.html#category-b
>>
>> Given that, the above list you have looks OK:
>> * Assuming we'll only depend on Rhino binaries
>> * The js-beautify license seems reasonable, we may have to ping the
>> ASF Legal Affairs committee for a definite answer
>
> js-beautify license == MIT.
>
> Hen
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [all] preparing initial commit
Posted by Rahul Akolkar <ra...@gmail.com>.
On Tue, May 18, 2010 at 1:38 AM, Henri Yandell <fl...@gmail.com> wrote:
> On Mon, May 17, 2010 at 11:21 AM, Rahul Akolkar <ra...@gmail.com> wrote:
>> On Sun, May 16, 2010 at 11:25 PM, Jacob Beard <jb...@cs.mcgill.ca> wrote:
>>> Hi,
>>>
>>> I'm currently working to prepare the initial commit for my Google
>>> Summer of Code project. I have a quick question regarding external
>>> libraries. My project currently uses a few libraries which are
>>> licensed under liberal, non-copyleft licenses. A list of these
>>> libraries and their associated licenses is as follows:
>>>
>>> Mozilla Rhino - MPL
>>> Dojo JavaScript toolkit - BSD/AFL dual license
>>> Selenium - Apache 2.0 License
>>> js-beautify - something a bit non-standard:
>>> http://github.com/einars/js-beautify/blob/master/license.txt
>>> json2 - Public Domain
>>>
>> <snip/>
>>
>> I'll first address the licenses and then get to the how to include the
>> libraries bit.
>>
>> You may have seen the following categorization of licenses we use
>> (Category A is generally easier to incorporate than B):
>>
>> http://www.apache.org/legal/3party.html#category-a
>>
>> http://www.apache.org/legal/3party.html#category-b
>>
>> Given that, the above list you have looks OK:
>> * Assuming we'll only depend on Rhino binaries
>> * The js-beautify license seems reasonable, we may have to ping the
>> ASF Legal Affairs committee for a definite answer
>
> js-beautify license == MIT.
>
<snip/>
Thanks Hen.
-Rahul
> Hen
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [all] preparing initial commit
Posted by Henri Yandell <fl...@gmail.com>.
On Mon, May 17, 2010 at 11:21 AM, Rahul Akolkar <ra...@gmail.com> wrote:
> On Sun, May 16, 2010 at 11:25 PM, Jacob Beard <jb...@cs.mcgill.ca> wrote:
>> Hi,
>>
>> I'm currently working to prepare the initial commit for my Google
>> Summer of Code project. I have a quick question regarding external
>> libraries. My project currently uses a few libraries which are
>> licensed under liberal, non-copyleft licenses. A list of these
>> libraries and their associated licenses is as follows:
>>
>> Mozilla Rhino - MPL
>> Dojo JavaScript toolkit - BSD/AFL dual license
>> Selenium - Apache 2.0 License
>> js-beautify - something a bit non-standard:
>> http://github.com/einars/js-beautify/blob/master/license.txt
>> json2 - Public Domain
>>
> <snip/>
>
> I'll first address the licenses and then get to the how to include the
> libraries bit.
>
> You may have seen the following categorization of licenses we use
> (Category A is generally easier to incorporate than B):
>
> http://www.apache.org/legal/3party.html#category-a
>
> http://www.apache.org/legal/3party.html#category-b
>
> Given that, the above list you have looks OK:
> * Assuming we'll only depend on Rhino binaries
> * The js-beautify license seems reasonable, we may have to ping the
> ASF Legal Affairs committee for a definite answer
js-beautify license == MIT.
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [all] preparing initial commit
Posted by Rahul Akolkar <ra...@gmail.com>.
On Sun, May 16, 2010 at 11:25 PM, Jacob Beard <jb...@cs.mcgill.ca> wrote:
> Hi,
>
> I'm currently working to prepare the initial commit for my Google
> Summer of Code project. I have a quick question regarding external
> libraries. My project currently uses a few libraries which are
> licensed under liberal, non-copyleft licenses. A list of these
> libraries and their associated licenses is as follows:
>
> Mozilla Rhino - MPL
> Dojo JavaScript toolkit - BSD/AFL dual license
> Selenium - Apache 2.0 License
> js-beautify - something a bit non-standard:
> http://github.com/einars/js-beautify/blob/master/license.txt
> json2 - Public Domain
>
<snip/>
I'll first address the licenses and then get to the how to include the
libraries bit.
You may have seen the following categorization of licenses we use
(Category A is generally easier to incorporate than B):
http://www.apache.org/legal/3party.html#category-a
http://www.apache.org/legal/3party.html#category-b
Given that, the above list you have looks OK:
* Assuming we'll only depend on Rhino binaries
* The js-beautify license seems reasonable, we may have to ping the
ASF Legal Affairs committee for a definite answer
Based on what actually gets included, the LICENSE (and perhaps the
NOTICE) in your project trunk will need to be updated. For an example
of how this is done, see the part of the httpd LICENSE (scroll down
below the AL 2.0 text):
http://svn.apache.org/repos/asf/httpd/httpd/trunk/LICENSE
> Is it possible to include these libraries in the source tree of my project?
>
> Also, for a library like dojo, which is large (about 100MB,
> uncompressed), and composed of many small files, would it be better to
> include a compressed zip file in the library directory, with
> instructions in the README for the user to unzip it, or would it be
> better to use an svn:externals svn property to point to the dojo
> source tree, so that it is automatically checked out (probably from a
> specific tag), when the source tree is checked out.
>
<snap/>
To recap what others have said, the guiding principles we use are
along these lines:
* Do not add dependencies to SVN, have the build retrieve a fixed version
- The version may be binaries from a Maven repo or source from
svn:externals via a tag (a SVN location that is immutable in practice)
* Use the standard Maven layout and build as far as possible
- Obviously, what this means for a JavaScript project remains to be
seen, maybe you can say whether or not you think Maven adds value for
your project and what build system you intend to use
Obviously, if there is a need to make modifications to any of the
dependencies, the above is not sufficient. In those cases where there
is merit in having a source copy in SVN, dependency code can be
checked in if its an amicable license. Indeed, we already include some
of the above dependency sources elsewhere at the ASF.
Struts 2 includes Dojo sources:
http://svn.apache.org/repos/asf/struts/struts2/trunk/plugins/dojo/src/main/resources/org/apache/struts2/static/dojo/
Tapestry 5 includes scriptaculous sources (as another JavaScript example):
http://svn.apache.org/repos/asf/tapestry/tapestry5/trunk/tapestry-core/src/main/resources/org/apache/tapestry5/scriptaculous_1_8_2/
Here is an example of using Rhino with modifications (Batik 1.7):
http://svn.apache.org/repos/asf/xmlgraphics/batik/tags/batik-1_7/lib/
(in particular, see LICENSE.js.txt and README.js.txt)
To summarize, if you can make a strong case to including sources in
SVN, it may be possible. If you are simply intending to use these as
runtime dependencies, its best to pull them down with the build rather
than check anything into SVN.
-Rahul
> Please let me know what you think. Thanks,
>
> Jake
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [all] preparing initial commit
Posted by Mark Thomas <ma...@apache.org>.
On 17/05/2010 04:25, Jacob Beard wrote:
> Hi,
>
> I'm currently working to prepare the initial commit for my Google
> Summer of Code project. I have a quick question regarding external
> libraries. My project currently uses a few libraries which are
> licensed under liberal, non-copyleft licenses. A list of these
> libraries and their associated licenses is as follows:
>
> Mozilla Rhino - MPL
> Dojo JavaScript toolkit - BSD/AFL dual license
> Selenium - Apache 2.0 License
> js-beautify - something a bit non-standard:
> http://github.com/einars/js-beautify/blob/master/license.txt
> json2 - Public Domain
>
> Is it possible to include these libraries in the source tree of my project?
I'd be very strongly against that. The exact versions required should be
downloaded from a stable location as part of the build process. Maven
should do this for you. Alternatively take a look at the Tomcat build
file that has a simple dependency download with the build script.
Given the widespread use of Maven in Commons, I'd suggest that Maven is
the way to go.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org