Re: [ease-dev] Oomph Setup failed

[Raphael Geissler <raphael.geissler@xxxxxxxxx>]

Hi Christian,

2017-01-09 20:00 GMT+01:00 Christian Pontesegger <christian.pontesegger@xxxxxx>:
> 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.

I had an E4 training, but my daily business is 3.x with compatibility
layer, but I would need more details to start with that.

> We also need improvements for code completion, especially if you come from
> the python world.

Not that much experience with python. :(

> 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...

Here also I am interested in get more experience with groovy, I played
a little bit with beanshell, but also not that much. With Ruby I have
no experience beside writing vagrant configs...

> 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.

I am new in the the Eclipse community, but I have certainly a few
ideas for scripts, that I can provide and blog about.

> And of course documentation is always needed (I know, its boring :))

Yes, that seems to be an issue, I would say. :) I started with that:
https://rage5474.github.io/2017/01/08/Eclipse-Scripting-Basics-EASE.html
Maybe you or anyone can review it. A link to it would also be good. My
blog is not that popular.

>> 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.

You're right. Thanks for the hint.

> 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...

Maybe a really good starting point for me.

>> 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")

Thanks for the hint. I also saw this this afternoon in your scripts.
That's enough for the start I would say.

> 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.

Let me start with Cron stuff...Do you have there more 'requirements'?
As I said I am new in the Eclipse Community, maybe you have to help me
with some practical things as soon as I have code to integrate.


> cheers
> Christian

Raphael

> _______________________________________________
> ease-dev mailing list
> ease-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from
> this list, visit
> https://dev.eclipse.org/mailman/listinfo/ease-dev