Rhino 1.7R5 release?

[nilskp]

Will this ever happen, or has development stopped?

[Greg Brail]

From looking at the responses over the last few months, it seems to me that no one is actively maintaining this project.

That's too bad because a whole bunch of us are relying on Rhio and would like to make some improvements.

Does anyone know the process whereby we'd elect some new committers so that we can all move forward?

On Mon, Nov 4, 2013 at 10:30 AM, nilskp <nil...@gmail.com> wrote:

Will this ever happen, or has development stopped?

--
You received this message because you are subscribed to the Google Groups "mozilla-rhino" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mozilla-rhin...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--

greg brail | apigee | m: +1.650.937.9302 | twitter @gbrail @apigee

[frank.w...@gmail.com]

From nilskp :

>Will this ever happen, or has development stopped?

It looks to me like all the Rhino developers have gone
over to the Nashorn group. I suggest that if you or
others wish to remain with Rhino and have the time and
skills to work on it then get the necessary access and
go to work!

Frank
Not-a-programmer.

[Simon Oberhammer]

we use this R5 snapshot since mid 2012:

https://oss.sonatype.org/content/repositories/snapshots/org/mozilla/rhino/1.7R5-SNAPSHOT/rhino-1.7R5-20120629.144839-4.jar

and there's an even newer version on maven central released by this guy: https://github.com/wro4j/rhino i haven't tested that one myself.

  simon

[Greg Brail]

Thanks for sending out this link. We are also relying on Rhino 1.7R4 from the "official" distribution and I'm seriously considering moving to my own fork so that I can cherry-pick the fixes that we need. But there must be a better way?

Does anyone on this list know if Mozilla has a process for electing a new set of committers? I can volunteer to help coordinate an effort if necessary since I see enough activity on this list to know that there are still people around the world who need to find a way to maintain this code base.

--

You received this message because you are subscribed to the Google Groups "mozilla-rhino" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mozilla-rhin...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Simon Oberhammer]

I'm in favor of forking. It's been over a year. We need a new release 
candidate for people to use and test.

If we do a good job (get enough people to use our version and collect
feedback) then this will also make it easier for someone with mozilla authority
to take what we prepared and ship it as a new RC.

Our group has been using the snapshot I linked earlier for over a year but
there were quite some important sounding changes in master since then:

https://github.com/mozilla/rhino/compare/d933ef427fd8746ecd43368042af6ba184b233a5...master

...I'm interested in all changes/fixes. You mentioned cherry-picking: what
are you priorities? :)

[frank.w...@gmail.com]

From Greg Brail :

>Does anyone on this list know if Mozilla has a process
>for electing a new
>set of committers?

It looks like Oracle took all of the Rhino developers to
work on Nashorn. For a while after that one of those
developers, Hannes, continued to respond to this group,
but now it looks like they have all abandoned us, and
without notifying us.

I suggest you write to the Nashorn group and ask for one
of the ex-Rhino developers to tell you how to take over
as a Rhino contributer. Below is the address of the
Nashorn list; I don't know if you can send without
subcribing, but I think subscription is only for
receiving from the list. Be sure to say that you have
not subscribed and ask for an e-mail reply.


To: Nashorn <nasho...@openjdk.java.net>

Frank

[Greg Brail]

Thanks for the suggestion -- I just emailed the Nashorn Dev list. If that fails then I will try to see who we can get in touch with at Mozilla.

--
You received this message because you are subscribed to the Google Groups "mozilla-rhino" group.

To unsubscribe from this group and stop receiving emails from it, send an email to mozilla-rhino+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.

[Greg Brail]

Sure, I'd be happy to do that.

For context, my coworkers and I use Rhino a lot inside Apigee Edge, most intensively to run Node.js code using a project we're working on called "Trireme" (https://github.com/apigee/trireme)

As for specific changes, just looking at pull requests and not at Bugzilla yet, here are the top ones that are causing incompatibility with Node:

• Add trimRight and trimLeft to String: https://github.com/mozilla/rhino/pull/41
• Find some way to execute scripts that are larger than 64K: https://github.com/mozilla/rhino/pull/76
  
• Add "stack" property to Error object: https://github.com/mozilla/rhino/pull/109
  
• Make Date parse a much wider variety of valid date formats -- I know that there is a branch out there for this but I don't see an open pull request in GitHub.

Looking at many of the other GitHub pull requests, they look nice too, but those are the ones that have given us trouble in running the (huge amount) of JS code generated by Node programmers.

--
You received this message because you are subscribed to the Google Groups "mozilla-rhino" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mozilla-rhin...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Michael Schwartz]

I think Nashorn only runs on Java 8, but so does rhino last time I tried it.

So there probably is a need to support rhino for the foreseeable future.

I would love to see an aggressive support effort for rhino.  I have some wish list items to offer:

1) fix the debugger.  Have it remember screen position and window size, including multiple displays.  Remember the bottom tab states, too - I never use watch, but heavily use the interactive console.  The variable display pane bottom left barely works: I cannot examine members of objects.

2) arguments.caller is supported by every other js engine but rhino.  Some code cannot be ported - see callParent() implementation in ExtJS and Sencha Touch.

3) deal with the new ConsString logic that most 3rd party libraries don't grok, they won't serialized them.

I'm not a Java programmer, or I'd throw my weight behind the effort.  I will help any way I can, though.

[Michael Schwartz]

String.prototype.trimLeft = function() { return this.replace(/^\s+/, ''); };

Granted it's not native, but trivial to implement transparently.

[Hannes Wallnöfer]

It's great to see things moving here, and I hope there's enough momentum to get a new release out.

I've learned by now that I don't have the time or energy needed to be the driving force in this. I made promises about this in the past, and I'm sorry about that.

However, I have some suggestions for those of you willing to move Rhino onward.

My main suggestion is not to be too concerned about official blessing from Mozilla, at least not in the beginning. Mozilla has done a great job at supporting Rhino, even though it never mattered as core product. But with the code on github, waiting for somebody from Mozilla to appoint new committers is just like waiting for a permission you don't need.

What you need to do is to agree on what patches/pull requests should be included in the release. This should be thrashed out on this list, and somebody who is trusted needs go ahead with a fork. I offer my help in reviewing changes as time permits.

If you get this done, merging the changes back into mozilla/rhino plus whatever else is needed for an official release should be relatively minor tasks.

Hannes

2013/12/2 Michael Schwartz <myk...@gmail.com>

[Greg Brail]

Thanks, Hannes, that's a big help.

What would you guys think of something like this:

1. Create a fork somewhere (I'm happy to do it unless there is another pre-forked repo that someone on the list owns and would rather use)
2. Set up Jenkins on the fork -- I can also see if we can help there
3. Use GitHub issues and merge requests to take solicitations from the community for what should be pulled from various other branches and existing pull requests
4. A volunteer or two merges the pull requests and ensures code quality and test coverage
5. We all test the proposed new release
6. We go back to Hannes for help reviewing the changes
7. Finally, we also ask him to help by pushing the new release candidate to Mozilla and distribute via Maven Central as usual

I'm happy to do this another way if someone else has a suggestion.

If not then I'm happy to get started with the first two steps. Any volunteers to help manage the pull requests in step 4?

[Hannes Wallnöfer]

Sounds good to me! I recommend starting with a clean fork.

Hannes

2013/12/3 Greg Brail <gr...@apigee.com>

[Christopher Hunt]

Hi Hannes,

I imagine that you're stretched between Nashorn and perhaps other commitments. I was wondering though whether it'd be useful to at least make a 1.7R5 release with the current code base. Would you be able to allocate that time? Is the current code base up to scratch for a 1.7R5?

I'm also assuming that you have the authority to deploy releases. Please advise otherwise.

Thanks.

Kind regards,

Christopher