[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [ease-dev] Oomph Setup failed
|
On 09.01.2017 12:16, Raphael Geissler wrote:
generally I am open for many things to do. But maybe it's good to
start where I have experience and what is important from your point of
view.
From my point of view some e4 experience could push the project
further. Currently the whole keyword UI integration code is based on on
eclipse 3.x mechanisms. This prevents us from pushing scripts to the
main toolbar. If we could dynamically adapt the e4 model we would get
more freedom in where to hook our scripts to.
We also need improvements for code completion, especially if you come
from the python world.
From the engines point of view javascript and python have active
developers, ruby, groovy and beanshell are mere proof of concept
implementations. If you are into one of these languages, they would need
testing, sample scripts, possibly a debugger implementation...
If you are familiar with one of the other projects at eclipse it might
be worth looking into providing a module for that project helping EASE
users to do new stuff.
And of course documentation is always needed (I know, its boring :))
What I already did successfully last weekend is to add a new keyword
extension (http://consolescript.eclipse-plugin.ragedev.de/ - more or
less a learning project).
Adding keywords to the mechanism is already a good step into EASE.
Reading your howto I guess you should register the script location,
otherwise EASE would not pick up your js files.
As you already worked on keywords: would be nice to have keywords that
allow to resolve dependencies, eg
dependsOn: org.eclipse.jdk.feature.group [1.0.0, 3.0.0) from
http://downloads.eclipse.org....
Also a cron: keyword would be fine. Had a look at this but could not
find a free java cron library to calculate those nasty dates for the
next run...
I have some years experience with Eclipse RCP, so I can do also
internal stuff or extend modules or even write some example scripts.
What is important from my point of view is to make it possible to add
API from scripts, because otherwise you get big and unstructured
scripts with a lot of copy and paste lines of code.
(I tried to implement this issue
https://bugs.eclipse.org/bugs/show_bug.cgi?id=442447 last evening, but
I was lost somehow... I couldn't find this loadModules() stuff... )
I think there would be two solutions:
1. Extend modules by script
2. Import scripts from other scripts (I tried this with Rhino and
Python, but in both cases there were some errors)
importing scripts from other scripts works using the include("<uri>")
command. The included code will be executed right on the spot as if its
content would be part of the main file. Try something like
include("someFileInTheSameFolder.js")
include("workspace://project/someFile.js")
include("file://home/someone/file.js")
The bug you are referring to deals with allowing to write modules in a
script target language. While it seemed to be a good idea some time ago
I would not do it anymore from my practical experience with script
users. Having module code on a changeable location like the workspace
would quite likely result in lots of changes to these files and
therefore an inconsistent API. Further there would be no mechanism in
place to distribute and install these dynamic modules. I am not even
starting to think about versiion ranges, dependencies, ...
Here the p2 mechanism is really nice and solves all these topics for us.
Further modules written in Java work for all available script engines.
Modules in a dedicated script language will never work for another.
So from a practical point using include() is quite nice when you want to
build libraries for a dedicated language. It could also be a way for
rapid prototyping and once the lib gets stable, port it to Java and a
native module. There code completion could be improved a lot. Once that
works, users do not care much where their functions come from.
However there might be other use cases that I miss where dynamic modules
might come in handy.
What do think? What is important at the moment?
I do not see very urgent topics at this point in time, but some
interesting ideas for improvements. If you want to pick up one of the
proposals above, let me know.
cheers
Christian
