Implemented "include" for sub-scripts.

[Lothar-Tradescape]

Show script stack trace in case of errors.

[fornwall]

Nice - I've merged it and will test it a bit more before pushing it in a 1.0.8 release!

[fornwall]

I've modified it with commit https://github.com/fornwall/eclipsescript/commit/ef59de29cadd8344719a7426e16bb6da7da15ea2

This tries to handle relative includes, such as in the following case:

/start.eclipse.js // require('folder/scriptb.js') /folder/scriptb.js // require('scriptc.js') /folder/scriptc.js

That is, scriptb.js should be able to include 'scriptc.js' by relative path regardless of the starting script being in a different folder. What do you think about it?

[Lothar-Tradescape]

I like the idea of allowing relative includes even from the included scripts. I had only time to review the commit briefly and will test it later when I'm in the office. However it seems that you are treating absolute path names as project relative, whereas eclipse treats absolute paths as workspace relative. Is there a special reason to break with the eclipse convention?

I also like that you refactored some of your API to be IFile based instead of string based. I thought about that, too, but I considered it to invasive for my patch as I tried to keep the changes to your API to a minimum.

Lothar Werzinger

Sent from a mobile device. On Apr 23, 2013 1:27 AM, "Fredrik Fornwall" notifications@github.com wrote:

I've modified it with commit ef59de2https://github.com/fornwall/eclipsescript/commit/ef59de29cadd8344719a7426e16bb6da7da15ea2

This tries to handle relative includes, such as in the following case:

/start.eclipse.js // require('folder/scriptb.js') /folder/scriptb.js // require('scriptc.js') /folder/scriptc.js

That is, scriptb.js should be able to include 'scriptc.js' by relative path regardless of the starting script being in a different folder. What do you think about it?

— Reply to this email directly or view it on GitHubhttps://github.com/fornwall/eclipsescript/pull/11#issuecomment-16845523 .

This message and any attachment (the "message") is intended solely for the addressees and is confidential. If you receive this message by mistake, please delete it and notify the sender immediately. Any use not in accordance with its purpose, any out-spread or disclosure, either as a whole or partially, is prohibited except with formal approval. Internet cannot guarantee the integrity of this message, therefore Tradescape will not be liable for the message if modified.

[fornwall]

On Tue, Apr 23, 2013 at 3:57 PM, Lothar Werzinger notifications@github.comwrote:

I had only time to review the commit briefly and will test it later when I'm in the office. However it seems that you are treating absolute path names as project relative, whereas eclipse treats absolute paths as workspace relative. Is there a special reason to break with the eclipse convention?

The reasoning behind project-relative paths was that in our projects we have the scripts inside the projects, and we do not want to depend on naming of eclipse project by different developers - projects are often checked out with different names under different branches by different developers, and we want the scripts to be run in project-context independent of that.

But I agree that it feels strange and against eclipse convention, perhaps project-relative paths can be offered with an alternative syntax.

Fredrik

[Lothar-Tradescape]

On Wed, Apr 24, 2013 at 12:48 PM, Fredrik Fornwall <notifications@github.com

wrote:

On Tue, Apr 23, 2013 at 3:57 PM, Lothar Werzinger notifications@github.comwrote:

I had only time to review the commit briefly and will test it later when I'm in the office. However it seems that you are treating absolute path names as project relative, whereas eclipse treats absolute paths as workspace relative. Is there a special reason to break with the eclipse convention?

Seems to work fine. When do you plan to do a release?

The reasoning behind project-relative paths was that in our projects we have the scripts inside the projects, and we do not want to depend on naming of eclipse project by different developers - projects are often checked out with different names under different branches by different developers, and we want the scripts to be run in project-context independent of that.

wouldn't the (new) script relative paths already catch that scenario?

But I agree that it feels strange and against eclipse convention, perhaps project-relative paths can be offered with an alternative syntax.

If they are not already caught by the script relative paths, then maybe something like /${SCRIPT_PROJECT}/folder/file.js ?

Fredrik

Lothar

This message and any attachment (the "message") is intended solely for the addressees and is confidential. If you receive this message by mistake, please delete it and notify the sender immediately. Any use not in accordance with its purpose, any out-spread or disclosure, either as a whole or partially, is prohibited except with formal approval. Internet cannot guarantee the integrity of this message, therefore Tradescape will not be liable for the message if modified.

[fornwall]

I've pushed 1.0.8 containing the eclipse.runtime.include() function to the update site now.

It uses workspace-relative paths as you suggested - for project-relative one can use eclipse.runtime.include('/' + eclipse.resources.currentProject.name + '/path/to/file.js').