Home » Eclipse Projects » Eclipse Platform » IFile that corresponds to a logical view.
| IFile that corresponds to a logical view. [message #288680] |
Thu, 21 July 2005 06:13  |
Eclipse User |
|
|
|
Originally posted by: thhal.mailblocks.com
Hi,
I'm considering the creation of an IFile implementation that would
correspond to a logical view (XML) of some computed data. The data has
no natural corresponding file on disk.
Besides providing the actual data, what is required to do such an
implementation? How do I register the implementation with the workspace
so that it can be viewed, opened, etc. Is there an example somewhere
that I can look at?
Regards,
Thomas Hallgren
|
|
|
| Re: IFile that corresponds to a logical view. [message #288694 is a reply to message #288680] |
Thu, 21 July 2005 11:22  |
| Eclipse User |
|
|
|
Originally posted by: john.eclipsefaq.org
Thomas, do you mean:
1) That your "logical" file is not in the file system at all, or
2) That it doesn't map 1-1 with a single file, but the data is stored in
files (either the logical element spans multiple files or a single file
contains multiple logical elements).
We are interested in exploring these problems in the next Eclipse
release. We started to make progress on 2) in the 3.1 release. Our
approach has been to facilitate the mapping of logical elements to
physical files, rather than turning IFile into a logical layer and
hiding the physical layer entirely. In many cases this is the only
choice, since some tools, such as repository plugins, typically have no
choice but to deal directly with the physical file level. See for
example the following bug:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=37723
If you are interested in 1), that is a much more challenging problem.
Many plugins make the assumption that IFile maps closely to a physical
file, often by calling IFile.getLocation().toFile() to obtain a
java.io.File. This class of plugins (which includes most of the
platform itself), would not be able to handle an IFile that was not
backed by a java.io.File. However, you are welcome to enter an
enhancement request for this. It has frequently been discussed in the
past but I was surprisely unable to find anything in bugzilla on the
subject.
--
Thomas Hallgren wrote:
> Hi,
> I'm considering the creation of an IFile implementation that would
> correspond to a logical view (XML) of some computed data. The data has
> no natural corresponding file on disk.
>
> Besides providing the actual data, what is required to do such an
> implementation? How do I register the implementation with the workspace
> so that it can be viewed, opened, etc. Is there an example somewhere
> that I can look at?
>
> Regards,
> Thomas Hallgren
|
|
| |
| Re: IFile that corresponds to a logical view. [message #288723 is a reply to message #288694] |
Fri, 22 July 2005 05:55 |
| Eclipse User |
|
|
|
Originally posted by: thhal.mailblocks.com
John,
Let me try and elaborate on what it is I'm trying to do.
The Buckminster (Technology subproject) uses an Eclipse extension point
to produce a dependency graph for a component. One extension
implementation will use the the Eclipse plugin manifest files as its
source, another uses Maven's project.xml, a third uses the Buckminster
propriatary format. We forsee several other implementations. Buckminster
maintain the graph in its workspace meta-data. What I want to do is to
make this depencency graph available as an IFile regardless of if it is
a concrete file (the Buckminster proprietary format) or something that
is generated programmatically by an extension.
We could probably stipulate that an extension contributor must make a
"primary source" resource available and thus enable scenario 2). But if
we do, then that resource will be eclipsed by the generated resource.
The contributors to the dependency calculation are likely to be
resources in their own right and we can't really violate that. So, even
if it is likely that there will be at least one physical file, it still
feels like scenaro 1).
The more I think of it, isn't scenario 2) just as challenging in any
case? If some plugin does a getLocation().toFile() and ends up with a
file that somehow contributes to the logical content rather than no file
at all, then that might be just as bad or even worse. Sure, you would be
able to open the file or check if it exists but the content that you
read is incorrect and the existence of that single resource doesn't
necessarily mean that the logical resource is present. It might depend
on several files, on specific content, etc. And, as with my example
above, the physical file might be a resource in its own right.
I'd like to issue an enhancement request but I'd like to discuss a bit
furhter what it would say. The essence of it would (I think) be to make
the Eclipse plugins less dependent on that a resource location maps to
the presence of a file/directory in the local file system.
The abstraction is there already. The reason people break it is probably
lack of some functionality in IPath. I know I break it because theres no
IPath.exists(), IPath.delete(), IPath.isDirectory() or IPath.list().
Perhaps they could be implemented so that a check is made if the path
represents a resource, if it is, then the information/action would be
obtained/carried out by that resoruce. If not, then the local file
system would be consulted. Relative paths would always be relative to
the workspace of course.
Regards,
Thomas Hallgren
John Arthorne wrote:
> Thomas, do you mean:
>
> 1) That your "logical" file is not in the file system at all, or
> 2) That it doesn't map 1-1 with a single file, but the data is stored in
> files (either the logical element spans multiple files or a single file
> contains multiple logical elements).
>
> We are interested in exploring these problems in the next Eclipse
> release. We started to make progress on 2) in the 3.1 release. Our
> approach has been to facilitate the mapping of logical elements to
> physical files, rather than turning IFile into a logical layer and
> hiding the physical layer entirely. In many cases this is the only
> choice, since some tools, such as repository plugins, typically have no
> choice but to deal directly with the physical file level. See for
> example the following bug:
>
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=37723
>
> If you are interested in 1), that is a much more challenging problem.
> Many plugins make the assumption that IFile maps closely to a physical
> file, often by calling IFile.getLocation().toFile() to obtain a
> java.io.File. This class of plugins (which includes most of the
> platform itself), would not be able to handle an IFile that was not
> backed by a java.io.File. However, you are welcome to enter an
> enhancement request for this. It has frequently been discussed in the
> past but I was surprisely unable to find anything in bugzilla on the
> subject.
> --
>
> Thomas Hallgren wrote:
>
>> Hi,
>> I'm considering the creation of an IFile implementation that would
>> correspond to a logical view (XML) of some computed data. The data has
>> no natural corresponding file on disk.
>>
>> Besides providing the actual data, what is required to do such an
>> implementation? How do I register the implementation with the
>> workspace so that it can be viewed, opened, etc. Is there an example
>> somewhere that I can look at?
>>
>> Regards,
>> Thomas Hallgren
|
|
|
| Re: IFile that corresponds to a logical view. [message #288911 is a reply to message #288723] |
Tue, 26 July 2005 12:30 |
| Eclipse User |
|
|
|
Originally posted by: john.eclipsefaq.org
Some responses below... I am also forwarding to the platform-core-dev
mailing list. That's a good place to continue discussion so that all
core committers are likely to see it.
Thomas Hallgren wrote:
> The Buckminster (Technology subproject) uses an Eclipse extension point
> to produce a dependency graph for a component. One extension
> implementation will use the the Eclipse plugin manifest files as its
> source, another uses Maven's project.xml, a third uses the Buckminster
> propriatary format. We forsee several other implementations. Buckminster
> maintain the graph in its workspace meta-data. What I want to do is to
> make this depencency graph available as an IFile regardless of if it is
> a concrete file (the Buckminster proprietary format) or something that
> is generated programmatically by an extension.
Why do you wan to make it available as an IFile? Do you want this
artifact to be treated as an IFile in all cases, appearing in the
Navigator inside some project, openable with editors, etc? Do you want
to attach markers or other metadata to it? I'm just trying to
understand if you want this to be a "first class" file in the workspace.
>
> We could probably stipulate that an extension contributor must make a
> "primary source" resource available and thus enable scenario 2). But if
> we do, then that resource will be eclipsed by the generated resource.
> The contributors to the dependency calculation are likely to be
> resources in their own right and we can't really violate that. So, even
> if it is likely that there will be at least one physical file, it still
> feels like scenaro 1).
>
> The more I think of it, isn't scenario 2) just as challenging in any
> case? If some plugin does a getLocation().toFile() and ends up with a
> file that somehow contributes to the logical content rather than no file
> at all, then that might be just as bad or even worse. Sure, you would be
> able to open the file or check if it exists but the content that you
> read is incorrect and the existence of that single resource doesn't
> necessarily mean that the logical resource is present. It might depend
> on several files, on specific content, etc. And, as with my example
> above, the physical file might be a resource in its own right.
My description of 2) was a bit scarce. I view this case as a logical
domain-specific model that is backed by a set of resources. Most
operations act directly on the domain model and don't care at all that
the logical model is stored in files. However, some operations require
access to the physical file (such as CVS operations). In this case all
that's needed is a transform that can take a logical model element as
input and produce (physical) IResource objects as output. In this case
the IResource objects retain their 1-1 mapping with the file system.
>
> I'd like to issue an enhancement request but I'd like to discuss a bit
> furhter what it would say. The essence of it would (I think) be to make
> the Eclipse plugins less dependent on that a resource location maps to
> the presence of a file/directory in the local file system.
I think it ends up being an all or nothing proposition. As soon as an
IResource is introduced that has no direct mapping to the local file
system, the whole platform needs to adhere to that new abstraction, or
things would simply stop working.
>
> The abstraction is there already. The reason people break it is probably
> lack of some functionality in IPath. I know I break it because theres no
> IPath.exists(), IPath.delete(), IPath.isDirectory() or IPath.list().
> Perhaps they could be implemented so that a check is made if the path
> represents a resource, if it is, then the information/action would be
> obtained/carried out by that resoruce. If not, then the local file
> system would be consulted. Relative paths would always be relative to
> the workspace of course.
I think IPath isn't rich enough to express it. IPath only has a device,
and an ordered array of String segments. I think you'd need something
that's structured more like a URI (with a scheme and a less structured
portion that may be interpreted differently depending on the scheme).
Also, IPath is currently heavily used to represent things other than
file system paths, such as abstract workspace paths. I.e., if IPath was
overhauled to fit the bill of a complete file system abstraction, it
would end up looking very different and would be difficult to do in a
compatible way. In any case, this is an implementation detail.
John
--
|
|
|
| Re: IFile that corresponds to a logical view. [message #288992 is a reply to message #288911] |
Wed, 27 July 2005 06:54 |
| Eclipse User |
|
|
|
Originally posted by: thhal.mailblocks.com
John Arthorne wrote:
> Some responses below... I am also forwarding to the platform-core-dev
> mailing list. That's a good place to continue discussion so that all
> core committers are likely to see it.
>
> Thomas Hallgren wrote:
>
>> The Buckminster (Technology subproject) uses an Eclipse extension
>> point to produce a dependency graph for a component. One extension
>> implementation will use the the Eclipse plugin manifest files as its
>> source, another uses Maven's project.xml, a third uses the Buckminster
>> propriatary format. We forsee several other implementations.
>> Buckminster maintain the graph in its workspace meta-data. What I want
>> to do is to make this depencency graph available as an IFile
>> regardless of if it is a concrete file (the Buckminster proprietary
>> format) or something that is generated programmatically by an extension.
>
>
> Why do you wan to make it available as an IFile? Do you want this
> artifact to be treated as an IFile in all cases, appearing in the
> Navigator inside some project, openable with editors, etc? Do you want
> to attach markers or other metadata to it? I'm just trying to
> understand if you want this to be a "first class" file in the workspace.
>
The answer is yes to all questions. We plan to support special purpose
viewers for this information (we use XML so the information is
"readable" already) and also editors where applicable. It's imperative
that we cant hint about problems in the dependency information in a way
that is consistent to the user. Other ways to use markers might be to
hint about the presence of new versions of components that your project
is dependent on and could upgrade to.
Other solutions than using an IFile are possible of course (something
similar to the Classpath container visible in the package explorer for
instance) but I think we have a good match for a "logical" entity in the
resource tree.
>> We could probably stipulate that an extension contributor must make a
>> "primary source" resource available and thus enable scenario 2). But
>> if we do, then that resource will be eclipsed by the generated
>> resource. The contributors to the dependency calculation are likely to
>> be resources in their own right and we can't really violate that. So,
>> even if it is likely that there will be at least one physical file, it
>> still feels like scenaro 1).
>>
>> The more I think of it, isn't scenario 2) just as challenging in any
>> case? If some plugin does a getLocation().toFile() and ends up with a
>> file that somehow contributes to the logical content rather than no
>> file at all, then that might be just as bad or even worse. Sure, you
>> would be able to open the file or check if it exists but the content
>> that you read is incorrect and the existence of that single resource
>> doesn't necessarily mean that the logical resource is present. It
>> might depend on several files, on specific content, etc. And, as with
>> my example above, the physical file might be a resource in its own right.
>
>
> My description of 2) was a bit scarce. I view this case as a logical
> domain-specific model that is backed by a set of resources. Most
> operations act directly on the domain model and don't care at all that
> the logical model is stored in files. However, some operations require
> access to the physical file (such as CVS operations). In this case all
> that's needed is a transform that can take a logical model element as
> input and produce (physical) IResource objects as output. In this case
> the IResource objects retain their 1-1 mapping with the file system.
>
I understand. And in cases where we want to edit the logical model we
must provide the mapping of course.
>>
>> I'd like to issue an enhancement request but I'd like to discuss a bit
>> furhter what it would say. The essence of it would (I think) be to
>> make the Eclipse plugins less dependent on that a resource location
>> maps to the presence of a file/directory in the local file system.
>
>
> I think it ends up being an all or nothing proposition. As soon as an
> IResource is introduced that has no direct mapping to the local file
> system, the whole platform needs to adhere to that new abstraction, or
> things would simply stop working.
>
If that's the case and if I'm the only one that would like to have this,
perhaps such a proposal is a bit unbalanced (resources spent versus the
gains). I wasn't aware that the platfrom was that dependent on the
physical mapping.
>>
>> The abstraction is there already. The reason people break it is
>> probably lack of some functionality in IPath. I know I break it
>> because theres no IPath.exists(), IPath.delete(), IPath.isDirectory()
>> or IPath.list(). Perhaps they could be implemented so that a check is
>> made if the path represents a resource, if it is, then the
>> information/action would be obtained/carried out by that resoruce. If
>> not, then the local file system would be consulted. Relative paths
>> would always be relative to the workspace of course.
>
>
> I think IPath isn't rich enough to express it. IPath only has a device,
> and an ordered array of String segments. I think you'd need something
> that's structured more like a URI (with a scheme and a less structured
> portion that may be interpreted differently depending on the scheme).
> Also, IPath is currently heavily used to represent things other than
> file system paths, such as abstract workspace paths. I.e., if IPath was
> overhauled to fit the bill of a complete file system abstraction, it
> would end up looking very different and would be difficult to do in a
> compatible way. In any case, this is an implementation detail.
>
You're right. An absolute IPath might still be relative to the workspace
so it would be up to the user to decide every time. It would be nice if
such capabilities did exist somewhere though. Perhaps in a helper class?
Extra parameters could be provided to denote the origin of the IPath. If
the platform is to be less dependent on physical files, then something
like that must be introduced I think.
Another thing that might help is to introduce a way to create an IFile
that hands you an OutputStream. Something that can replace:
OutputStream out = new FileOutputStream(foo.getLocation().toFile());
Regards,
Thomas Hallgren
|
|
|
Goto Forum:
Current Time: Sat May 10 01:43:52 EDT 2025
Powered by FUDForum. Page generated in 0.03254 seconds |
Home