Support non-workspace *.als resources in IALSFile

[GoogleCodeExporter]

What steps will reproduce the problem?
- Provide *.als resources in an Eclipse plugin
- bundle resources are not accessible as Eclipse IResource

Outline of the modification:
- add an IPath attribute to IALSFile for cases where the *.als resource is
in a bundle instead of the workspace
- modify uses of the IALSFile interface to accomodate the case where the
*.als resource isn't in the workspace (e.g., don't try to refresh it)

Original issue reported on code.google.com by nicolas....@gmail.com on 7 Apr 2008 at 4:42

[GoogleCodeExporter]

I would suggest to have a specific BundledALSFile implementation of IALSFile 
that
will be used to managed als files bundled within Eclipse plugins.

Maybe an abstract ALSFile will be needed to avoid code duplication between 
ALSFile
and BundledALSFile.

Original comment by daniel.l...@gmail.com on 8 Apr 2008 at 9:05

[GoogleCodeExporter]

I am unsure of the difficulty of that task. I am marking it for M4.

Original comment by daniel.l...@gmail.com on 8 Apr 2008 at 9:06

• Added labels: Milestone-M4

[GoogleCodeExporter]

I checked in a refactoring that provides ExternalALSFile as an IPath-based
implementation of the IALSFile interface and removes some of the dependencies 
in the
code on the IResource-based ALSFile implementation.

Original comment by nicolas....@gmail.com on 8 Apr 2008 at 8:12

[GoogleCodeExporter]

Great!

I will take a look at it.

Does it mean that we could use ExternalALSFile to display A4 sample models 
inside A4E
without uncompressing them on the file system? (It would require theFileChooser 
to be
able to look for a file inside a plugin jar file).

Original comment by daniel.l...@gmail.com on 9 Apr 2008 at 8:36

• Changed state: Started

[GoogleCodeExporter]

This is no longer applicable, since we are now xtext based.

Original comment by daniel.l...@gmail.com on 2 Jun 2011 at 7:55

• Changed state: WontFix