| Re: [eclipse-scripting-dev] EScriptMonkey birth |
|
05.09.2013 19:20, John Arthorne wrote:
If Christian is interested in becoming a committer on this effort then it is very easy. If he is a committer, and he wrote 100% of the code himself, he can commit it. Even if he is not a committer, we would just need to submit a CQ to get the code reviewed. If it is written 100% by a single author, and the author is involved in the process, this is quite easy (but may cause some delay).I am interested to become a committer as I want to work actively on this project. So there should not be any problems with that. That part you will need to resolve with Sharon and the rest of the IP team. If you actually want to *include* this code and it has uncertain history then it might become a blocker. If you want to make a dependency on it, where it is one of multiple scripting engines that you support, that is easier to deal with. Would it be possible at all to separate the Jython-specific piece from the rest of the code base or is it a fundamental part. In another Eclipse project I know a case where they host separate plugins/extensions that rely on "unclean" libraries in GitHub and host the rest of the project at Eclipse, for example. Currently 4 script languages are included in EScript: Rhino, Jython, Groovy and JRuby. The Rhino bundle comes already as part of JSDT, so we have no IP problems with that. For each of the other languages I currenty created a plugin containing eg the Jython interpreter. Integration in EScript is done by another plugin that depends on the script engine classes. For example we have an org.jython plugin and an ...escript.jython.interpreter plugin. The former may contain code where we need to clarify licensing issues the latter contains only code written by myself. So I guess your second suggestion would work as we could put the engines plugins on github sites. On the long run it would of course be more convenient to host all necessary stuff within eclipse.
I'd say it would be far better to host all this in an e4 repository than starting a migration after some months. As long as all the commits are from people who will be committers on the effort, it is easy to bring that work into Eclipse a bit later. That seems to be the case so far. We might continue on github until we are ready to move to e4, but we should trigger an e4 setup for our project as soon as possible. In the meantime it would be great to know which rules we should apply on commits, file headers and so on to make migration later on as smooth as possible. Christian |