I don't have a problem with depending on external SVN repo. It's unlikely that
a googlecode SVN will go anywhere. The Rhino build already pulls libraries from
Maven repositories. I actually started by adding:
<target name="get-interoperablejs">
<exec executable="svn" dir="build/test">
<arg value="checkout"/>
<arg value="http://interoperablejs.googlecode.com/svn/trunk/"/>
<arg value="interoperablejs-read-only"/>
</exec>
</target>
to testsrc/build.xml and making junit depend on it:
<target name="junit"
depends="junit-compile,coverage-instrument,get-interoperablejs">
...
This makes it reside in build/test/interoperablejs-read-only. Alternatively, we
could have it go under testsrc/org/mozilla/javascript/commonjs/module. But I'm
really not a fan of hosting 3rd party code in Mozilla CVS, for legal reasons.
Yes, I know InteroperableJS is MIT licensed, but still.
Attila.
On 2010.02.08., at 9:48, Jarosław Pałka wrote:
> Before I prepare my patch we need to decide where to put
> interoperablejs. I don't think that having dependencies to external
> SVN repo is a good solution. I think the best way is to simply commit
> content of http://interoperablejs.googlecode.com/svn/trunk into
> mozilla/js/rhino/testsrc/interoperablejs. This way we can also do a
> changes in tests itself.
>
> Let me know what do you think about it.
>
> Regards,
> Jarek
>
> W dniu 8 lutego 2010 08:59 użytkownik Attila Szegedi
> <[email protected]> napisał:
>>
>> Hi
>>
>> yes, please. I did start working on a JUnit driver for them myself, but if
>> you already have it completed, I'll be happy to accept your patch and save
>> me some work.
>>
>> Thanks,
>> Attila.
>>
>> On 2010.02.08., at 8:57, Jarosław Pałka wrote:
>>
>>> Attila,
>>>
>>> I have finished tests with interoperablejs. I wonder how should I share it
>>> with you. Should I attach tests suite to bugzilla issue?
>>>
>>> Jarek
>>>
>>> W dniu 8 lutego 2010 08:14 użytkownik Attila Szegedi <[email protected]>
>>> napisał:
>>> On 2010.02.07., at 20:33, Jarosław Pałka wrote:
>>>
>>>> Attila,
>>>>
>>>> I was playing with your patch for few days, and one thing I found is
>>>> annoying NullPointerException when module is not found :), I believe we
>>>> should have more meaningful exception message.
>>>>
>>>> I am also working on tests, using
>>>> http://code.google.com/p/interoperablejs/. Were you trying to run your
>>>> patch against these tests?
>>>
>>> Hi,
>>>
>>> No, I haven't, but I definitely will now. I'm writing JUnit tests. I just
>>> recently discovered that there's an EMMA plugin for Eclipse, it greatly
>>> improves my progress towards good coverage. I have found few bugs myself.
>>>
>>> Also, I have found a way to make Require thread-safe for use with shared
>>> top level scopes. And by "found a way" I mean "found a more efficient way
>>> than using a coarse synchronized block on it" :-)
>>>
>>> Attila.
>>>
>>> --
>>> home: http://www.szegedi.org
>>> twitter: http://twitter.com/szegedi
>>> weblog: http://constc.blogspot.com
>>>
>>>>
>>>> So far code looks good,
>>>> Regards,
>>>> Jarek
>>>>
>>>> W dniu 31 stycznia 2010 20:15 użytkownik Attila Szegedi
>>>> <[email protected]> napisał:
>>>> Hi all,
>>>>
>>>> I just put out the second implementation patch at
>>>> <https://bugzilla.mozilla.org/show_bug.cgi?id=540724>, against current CVS
>>>> HEAD. Check it out if you're interested. I have worked on this for I most
>>>> of my free time I can have for coding in the last 12 days, and have
>>>> arrived at a much better design than what was in the first attempt. I
>>>> attached a comment to the Bugzilla issue describing the design decisions I
>>>> took. It all feels round to me at the moment. I took care to document all
>>>> classes and interfaces in great detail. I'll proceed with writing tests
>>>> for it, but if you don't mind reviewing and trying bleeding-edge stuff, go
>>>> for it.
>>>>
>>>> Attila.
>>>>
>>>> On 2010.01.19., at 23:45, Attila Szegedi wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> I created a Bugzilla issue to track this work:
>>>>> <https://bugzilla.mozilla.org/show_bug.cgi?id=540724>
>>>>> I already attached a patch with the implementation to the above issue, so
>>>>> feel free to check it out and provide feedback. I believe that the
>>>>> JavaDocs I provided are sufficiently comprehensive so that no one should
>>>>> have trouble understanding how's it used.
>>>>>
>>>>> Be warned it's quite untested - I'll proceed with writing some tests
>>>>> tomorrow.
>>>>>
>>>>> Attila.
>>>>>
>>>>> --
>>>>> home: http://www.szegedi.org
>>>>> twitter: http://twitter.com/szegedi
>>>>> weblog: http://constc.blogspot.com
>>>>>
>>>>> On 2010.01.18., at 14:54, Jarosław Pałka wrote:
>>>>>
>>>>>> Count me in as well.
>>>>>>
>>>>>> Jarek
>>>>>>
>>>>>> 2010/1/18 Rapha <[email protected]>
>>>>>>
>>>>>>> I like the idea. Are you thinking of the 1.1 spec (
>>>>>>> http://wiki.commonjs.org/wiki/Modules/1.1 ) ?
>>>>>>>
>>>>>>> Raphael
>>>>>>>
>>>>>>> On Jan 17, 1:35 pm, Attila Szegedi <[email protected]> wrote:
>>>>>>>> Folks,
>>>>>>>>
>>>>>>>> I'm contemplating adding CommonJS Modules implementation to Rhino
>>>>>>> codebase proper. I'd create org.mozilla.javascript.commonjs package to
>>>>>>> hold
>>>>>>> it, and we could have a method similar to initStandardObjects(), i.e.
>>>>>>> initCommonJs() that'd initialize it - basically install a require()
>>>>>>> function
>>>>>>> with the expected semantics in the top-level scope. I want leave some
>>>>>>> of its
>>>>>>> aspects - most notably lookup of the module script - pluggable,
>>>>>>> defined by
>>>>>>> interfaces in the org.mozilla.javascript.commonjs package, so that
>>>>>>> specific
>>>>>>> embeddings of Rhino (JS app servers) can install their own module
>>>>>>> resolver
>>>>>>> logic. I'd provide a default implementation for the shell too.
>>>>>>>>
>>>>>>>> As I foresee that several Rhino-based JS products will adopt CommonJS
>>>>>>>> in
>>>>>>> the near future, it seems desirable to not have all of them reinvent the
>>>>>>> wheel (even though some already did, I'm guilty of coding my own
>>>>>>> require()
>>>>>>> too in the next-gen version of my company's server-side JS
>>>>>>> enviroment...).
>>>>>>>>
>>>>>>>> Opinions?
>>>>>>>>
>>>>>>>> Attila.
_______________________________________________
dev-tech-js-engine-rhino mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-js-engine-rhino
