Home » Modeling » GMF (Graphical Modeling Framework) » Implementation of a new FileSystem based on Reusable Asset
|
| Re: Implementation of a new FileSystem based on Reusable Asset [message #187896 is a reply to message #187849] |
Tue, 20 May 2008 11:47   |
Eclipse User |
|
|
|
Originally posted by: merks.ca.ibm.com
Jacques,
Comments below.
Jacques LESCOT wrote:
> Hi all,
>
> - I need to implement a sort of "archive" model corresponding to a
> unique file containing a set of model files : the goal of this work
> would be to improve model management when a model references another
> one and help users to share their models (it is easier to send a
> single file than a set of files with references between them).
You could store a bunch of files in a single zip file...
>
> - A basic use case would be for example to provide a single file
> containing the domain model and the notational one of a GMF editor.
> This mechanism could be activated (a single "archive" model is used)
> or not (domain model and notational one are separated, as default).
> Ideally, I would like also that depending on the storing method the
> user choosed, references are kept without any changes in the XMI files.
I suppose two files contained by a single zip would fit the bill still...
>
> - Files that are stored in the "archive" model should be extensible
> (it should be also possible to add a configuration file, an OCL rule
> file, ....) : in fact I guess it should be an implementation of the
> Reusable Asset Specification [1].
Zip files seem good from this perspective too.
>
> - To implement this mechanism I think of a way to add my own
> FileSystem (based on the Zip [2] one). However the "archive" model
> should not be saved as a binary file : it should be possible to easily
> synchonise with a CVS repository for example. The solution would
> consist in the concatenation of the model files...
Bummer. Zip files are binary...
>
> - Do you know whether a similar implementation/work that I am not
> aware of have already been implemented/started ?
Of course XMIResourceImpl allows you to contain an arbitrary number of
root objects in a single resource and produce one combined XML
serialization.
>
>
> Any comment would be highly appreciated.
Zip files are already supported when
https://bugs.eclipse.org/bugs/show_bug.cgi?id=84327 was completed. I
wonder though if putting a bunch of related files under a single folder
and zipping them when you want to share them with someone else doesn't
accomplish much the same goal...
>
> Regards,
> Jacques
>
>
> [1] http://www.omg.org/technology/documents/formal/ras.htm
> [2]
> http://wiki.eclipse.org/index.php/EFS#UI_Examples:_Zip_and_M emory_file_systems
>
|
|
|
| Re: Implementation of a new FileSystem based on Reusable Asset [message #188666 is a reply to message #187896] |
Thu, 22 May 2008 10:47 |
 Jacques LESCOT
Messages: 247
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
--------------010808050108030104020905
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Ed,
Thanks for your fast answer.
In a first time, I am playing with the ZipFileSystem example referenced
in my previous post [1]. First, I zipped a simple ecore model into a zip
file, and try to open it using the Tree Structure editor. Opening is
done well, but when I select an element in the editor, some commands are
preparing and the isReadOnly() method from AdapterFactoryEditingDomain
class try to detect whether the selected Resource is readonly from its
EMF uri. At this point, the EMF uri equals
"platform:/resource/test/My.zip/My.ecore". URI resolvment failed with
the given URI (see the ZipEFS.png attached file to better see the context)
Here is the Exception I got :
java.lang.NullPointerException
at
org.eclipse.core.internal.resources.PlatformURLResourceConne ction.resolve(PlatformURLResourceConnection.java:66)
at
org.eclipse.core.internal.boot.PlatformURLHandler.openConnec tion(PlatformURLHandler.java:67)
at
org.eclipse.osgi.framework.internal.protocol.URLStreamHandle rProxy.openConnection(URLStreamHandlerProxy.java:112)
at java.net.URL.openConnection(Unknown Source)
at
org.eclipse.core.internal.runtime.PlatformURLConverter.toFil eURL(PlatformURLConverter.java:33)
at org.eclipse.core.runtime.FileLocator.toFileURL(FileLocator.j ava:165)
at
org.eclipse.emf.common.CommonPlugin$Implementation.asLocalUR I(CommonPlugin.java:177)
at org.eclipse.emf.common.CommonPlugin.asLocalURI(CommonPlugin. java:85)
at
org.eclipse.emf.edit.domain.AdapterFactoryEditingDomain.isRe adOnly(AdapterFactoryEditingDomain.java:808)
....
Things are better when I use URI.createURI() method instead of
URI.createPlatformURI() in the createModel() method of the EcoreEditor
class.
For example, I changed :
URI resourceURI = EditUIUtil.getURI(getEditorInput());
by URI resourceURI = URI.createURI(((IFileEditorInput)
getEditorInput()).getFile().getLocationURI().toString()); in the
createModelGen() method.
But using an unknown scheme ("ras" for example) than the "zip" one is
needed so that the Resource is not handled as an archive one.
Then, it is not possible to edit the My.ecore file (contained in the
My.zip file), the file is considered always as readonly. I must then
override the isReadOnly() method in the AdapterFactoryEditingDomain
class to enable modifications :
protected boolean isReadOnlyURI(URI uri) {
if ("ras".equals(uri.scheme()))
return false;
return super.isReadOnlyURI(uri);
}
That's why I really wonder whether EMF fully support Eclipse File System
implementation different from the LocalFileSystem one.
All those concepts are still quite confusing for me, so I do not really
know which component is responsible of this unexpected behavior.
So I really appreciate your comments and maybe some experiments you
could had to open/edit an ecore model contained in a zip file.
Regards,
Jacques
Ed Merks a
|
|
|
| Re: Implementation of a new FileSystem based on Reusable Asset [message #188727 is a reply to message #188666] |
Thu, 22 May 2008 11:57 |
| Eclipse User |
|
|
|
Originally posted by: merks.ca.ibm.com
This is a multi-part message in MIME format.
--------------000700010306090608040809
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Jacques,
I have to run to meetings soon, so I can't look at this in detail. It
doesn't make sense that the platform would get a null exception for the
simple URI you used... It should properly support delegating that
symbolic URI to the underlying EFS implementation.
Jacques LESCOT wrote:
> Ed,
>
> Thanks for your fast answer.
>
> In a first time, I am playing with the ZipFileSystem example
> referenced in my previous post [1]. First, I zipped a simple ecore
> model into a zip file, and try to open it using the Tree Structure
> editor. Opening is done well, but when I select an element in the
> editor, some commands are preparing and the isReadOnly() method from
> AdapterFactoryEditingDomain class try to detect whether the selected
> Resource is readonly from its EMF uri. At this point, the EMF uri
> equals "platform:/resource/test/My.zip/My.ecore". URI resolvment
> failed with the given URI (see the ZipEFS.png attached file to better
> see the context)
>
> Here is the Exception I got :
>
> java.lang.NullPointerException
> at
> org.eclipse.core.internal.resources.PlatformURLResourceConne ction.resolve(PlatformURLResourceConnection.java:66)
>
> at
> org.eclipse.core.internal.boot.PlatformURLHandler.openConnec tion(PlatformURLHandler.java:67)
>
> at
> org.eclipse.osgi.framework.internal.protocol.URLStreamHandle rProxy.openConnection(URLStreamHandlerProxy.java:112)
>
> at java.net.URL.openConnection(Unknown Source)
> at
> org.eclipse.core.internal.runtime.PlatformURLConverter.toFil eURL(PlatformURLConverter.java:33)
>
> at
> org.eclipse.core.runtime.FileLocator.toFileURL(FileLocator.j ava:165)
> at
> org.eclipse.emf.common.CommonPlugin$Implementation.asLocalUR I(CommonPlugin.java:177)
>
> at
> org.eclipse.emf.common.CommonPlugin.asLocalURI(CommonPlugin. java:85)
> at
> org.eclipse.emf.edit.domain.AdapterFactoryEditingDomain.isRe adOnly(AdapterFactoryEditingDomain.java:808)
>
> ...
>
>
> Things are better when I use URI.createURI() method instead of
> URI.createPlatformURI() in the createModel() method of the EcoreEditor
> class.
>
> For example, I changed :
> URI resourceURI = EditUIUtil.getURI(getEditorInput());
> by URI resourceURI = URI.createURI(((IFileEditorInput)
> getEditorInput()).getFile().getLocationURI().toString()); in the
> createModelGen() method.
>
> But using an unknown scheme ("ras" for example) than the "zip" one is
> needed so that the Resource is not handled as an archive one.
EMF does have a URI handler to deal with EFS-based URIs.
>
> Then, it is not possible to edit the My.ecore file (contained in the
> My.zip file), the file is considered always as readonly. I must then
> override the isReadOnly() method in the AdapterFactoryEditingDomain
> class to enable modifications :
>
> protected boolean isReadOnlyURI(URI uri) {
> if ("ras".equals(uri.scheme()))
> return false;
> return super.isReadOnlyURI(uri);
> }
>
>
> That's why I really wonder whether EMF fully support Eclipse File
> System implementation different from the LocalFileSystem one.
There is direct support for EFS URIs. I did explore changing the above
to use the new read only support of the URI converter, but the problem
is that some folks rely on being able to edit read-only resource and use
that to automatically check files out of a repository, so I didn't know
how to make it work without breaking that and didn't have time...
>
>
> All those concepts are still quite confusing for me, so I do not
> really know which component is responsible of this unexpected behavior.
I don't think the platform's URL handler should have just barffed.
>
> So I really appreciate your comments and maybe some experiments you
> could had to open/edit an ecore model contained in a zip file.
I have two days of meetings so I won't have much time until next week.
>
> Regards,
> Jacques
>
> Ed Merks a
|
|
|
| Re: Implementation of a new FileSystem based on Reusable Asset [message #188850 is a reply to message #188727] |
Thu, 22 May 2008 17:07 |
Jacques LESCOT
Messages: 247
Registered: July 2009 |
Senior Member |
|
|
I am sure e4 summit will take you lot of time (It was quite funny to
assist this meeting through internet :
http://www.ustream.tv/channel/eclipse) and Ganymede so.
I tried a few more things :
- Loading a resource (model2.ecore) contained in another "archive model"
(archive2.ras) using "Load Resource..." action
/test (my project)
/archive1.ras (a first archive)
/model1.ecore
/archive2.ras (a second archive)
/model2.ecore
Here again, the resource is loaded in the ResourceDialog class using
URI.createPlatformResourceURI(files[i].getFullPath().toStrin g(), true));
There I need to change this using again
URI.createURI(files[i].getLocationURI().toString())
In fact I really wonder how the EMF uri should be like ? And probably
the changes are made are not good : I use an absolute position of the
resource in the filesystem (using getLocationURI()) instead of using the
position of the resource in the workspace (using getFullPath())
I am waiting for your feedbacks on this point...
Thanks again for your help !
Regards
Ed Merks a écrit :
> Jacques,
>
> I have to run to meetings soon, so I can't look at this in detail. It
> doesn't make sense that the platform would get a null exception for the
> simple URI you used... It should properly support delegating that
> symbolic URI to the underlying EFS implementation.
>
> Jacques LESCOT wrote:
>> Ed,
>>
>> Thanks for your fast answer.
>>
>> In a first time, I am playing with the ZipFileSystem example
>> referenced in my previous post [1]. First, I zipped a simple ecore
>> model into a zip file, and try to open it using the Tree Structure
>> editor. Opening is done well, but when I select an element in the
>> editor, some commands are preparing and the isReadOnly() method from
>> AdapterFactoryEditingDomain class try to detect whether the selected
>> Resource is readonly from its EMF uri. At this point, the EMF uri
>> equals "platform:/resource/test/My.zip/My.ecore". URI resolvment
>> failed with the given URI (see the ZipEFS.png attached file to better
>> see the context)
>>
>> Here is the Exception I got :
>>
>> java.lang.NullPointerException
>> at
>> org.eclipse.core.internal.resources.PlatformURLResourceConne ction.resolve(PlatformURLResourceConnection.java:66)
>>
>> at
>> org.eclipse.core.internal.boot.PlatformURLHandler.openConnec tion(PlatformURLHandler.java:67)
>>
>> at
>> org.eclipse.osgi.framework.internal.protocol.URLStreamHandle rProxy.openConnection(URLStreamHandlerProxy.java:112)
>>
>> at java.net.URL.openConnection(Unknown Source)
>> at
>> org.eclipse.core.internal.runtime.PlatformURLConverter.toFil eURL(PlatformURLConverter.java:33)
>>
>> at
>> org.eclipse.core.runtime.FileLocator.toFileURL(FileLocator.j ava:165)
>> at
>> org.eclipse.emf.common.CommonPlugin$Implementation.asLocalUR I(CommonPlugin.java:177)
>>
>> at
>> org.eclipse.emf.common.CommonPlugin.asLocalURI(CommonPlugin. java:85)
>> at
>> org.eclipse.emf.edit.domain.AdapterFactoryEditingDomain.isRe adOnly(AdapterFactoryEditingDomain.java:808)
>>
>> ...
>>
>>
>> Things are better when I use URI.createURI() method instead of
>> URI.createPlatformURI() in the createModel() method of the EcoreEditor
>> class.
>>
>> For example, I changed :
>> URI resourceURI = EditUIUtil.getURI(getEditorInput());
>> by URI resourceURI = URI.createURI(((IFileEditorInput)
>> getEditorInput()).getFile().getLocationURI().toString()); in the
>> createModelGen() method.
>>
>> But using an unknown scheme ("ras" for example) than the "zip" one is
>> needed so that the Resource is not handled as an archive one.
> EMF does have a URI handler to deal with EFS-based URIs.
>>
>> Then, it is not possible to edit the My.ecore file (contained in the
>> My.zip file), the file is considered always as readonly. I must then
>> override the isReadOnly() method in the AdapterFactoryEditingDomain
>> class to enable modifications :
>>
>> protected boolean isReadOnlyURI(URI uri) {
>> if ("ras".equals(uri.scheme()))
>> return false;
>> return super.isReadOnlyURI(uri);
>> }
>>
>>
>> That's why I really wonder whether EMF fully support Eclipse File
>> System implementation different from the LocalFileSystem one.
> There is direct support for EFS URIs. I did explore changing the above
> to use the new read only support of the URI converter, but the problem
> is that some folks rely on being able to edit read-only resource and use
> that to automatically check files out of a repository, so I didn't know
> how to make it work without breaking that and didn't have time...
>>
>>
>> All those concepts are still quite confusing for me, so I do not
>> really know which component is responsible of this unexpected behavior.
> I don't think the platform's URL handler should have just barffed.
>>
>> So I really appreciate your comments and maybe some experiments you
>> could had to open/edit an ecore model contained in a zip file.
> I have two days of meetings so I won't have much time until next week.
>>
>> Regards,
>> Jacques
>>
>> Ed Merks a écrit :
>>> Jacques,
>>>
>>> Comments below.
>>>
>>> Jacques LESCOT wrote:
>>>> Hi all,
>>>>
>>>> - I need to implement a sort of "archive" model corresponding to a
>>>> unique file containing a set of model files : the goal of this work
>>>> would be to improve model management when a model references another
>>>> one and help users to share their models (it is easier to send a
>>>> single file than a set of files with references between them).
>>> You could store a bunch of files in a single zip file...
>>>>
>>>> - A basic use case would be for example to provide a single file
>>>> containing the domain model and the notational one of a GMF editor.
>>>> This mechanism could be activated (a single "archive" model is used)
>>>> or not (domain model and notational one are separated, as default).
>>>> Ideally, I would like also that depending on the storing method the
>>>> user choosed, references are kept without any changes in the XMI files.
>>> I suppose two files contained by a single zip would fit the bill
>>> still...
>>>>
>>>> - Files that are stored in the "archive" model should be extensible
>>>> (it should be also possible to add a configuration file, an OCL rule
>>>> file, ....) : in fact I guess it should be an implementation of the
>>>> Reusable Asset Specification [1].
>>> Zip files seem good from this perspective too.
>>>>
>>>> - To implement this mechanism I think of a way to add my own
>>>> FileSystem (based on the Zip [2] one). However the "archive" model
>>>> should not be saved as a binary file : it should be possible to
>>>> easily synchonise with a CVS repository for example. The solution
>>>> would consist in the concatenation of the model files...
>>> Bummer. Zip files are binary...
>>>>
>>>> - Do you know whether a similar implementation/work that I am not
>>>> aware of have already been implemented/started ?
>>> Of course XMIResourceImpl allows you to contain an arbitrary number
>>> of root objects in a single resource and produce one combined XML
>>> serialization.
>>>>
>>>>
>>>> Any comment would be highly appreciated.
>>> Zip files are already supported when
>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=84327 was completed.
>>> I wonder though if putting a bunch of related files under a single
>>> folder and zipping them when you want to share them with someone else
>>> doesn't accomplish much the same goal...
>>>>
>>>> Regards,
>>>> Jacques
>>>>
>>>>
>>>> [1] http://www.omg.org/technology/documents/formal/ras.htm
>>>> [2]
>>>> http://wiki.eclipse.org/index.php/EFS#UI_Examples:_Zip_and_M emory_file_systems
>>>>
>>
>>
>> ------------------------------------------------------------ ------------
>>
>
|
|
|
| Re: Implementation of a new FileSystem based on Reusable Asset [message #188877 is a reply to message #188850] |
Fri, 23 May 2008 01:17 |
| Eclipse User |
|
|
|
Originally posted by: merks.ca.ibm.com
Jacques,
I think for "normal workspace resources" getLocationURI will return the
file: URI and normally you'd not want access via the URI directly since
you'd bypass the workspace APIs that way. I'm surprised that the
platform's URL handler doesn't properly delegate to the underlying EFS
implementation. I suspect that's a bug. But in the end, you'll
probably want to specialize the isReadOnly logic anyway...
Jacques LESCOT wrote:
> I am sure e4 summit will take you lot of time (It was quite funny to
> assist this meeting through internet :
> http://www.ustream.tv/channel/eclipse) and Ganymede so.
>
> I tried a few more things :
> - Loading a resource (model2.ecore) contained in another "archive
> model" (archive2.ras) using "Load Resource..." action
>
> /test (my project)
> /archive1.ras (a first archive)
> /model1.ecore
> /archive2.ras (a second archive)
> /model2.ecore
>
> Here again, the resource is loaded in the ResourceDialog class using
> URI.createPlatformResourceURI(files[i].getFullPath().toStrin g(), true));
> There I need to change this using again
> URI.createURI(files[i].getLocationURI().toString())
>
> In fact I really wonder how the EMF uri should be like ? And probably
> the changes are made are not good : I use an absolute position of the
> resource in the filesystem (using getLocationURI()) instead of using
> the position of the resource in the workspace (using getFullPath())
>
> I am waiting for your feedbacks on this point...
>
> Thanks again for your help !
> Regards
>
> Ed Merks a écrit :
>> Jacques,
>>
>> I have to run to meetings soon, so I can't look at this in detail.
>> It doesn't make sense that the platform would get a null exception
>> for the simple URI you used... It should properly support delegating
>> that symbolic URI to the underlying EFS implementation.
>>
>> Jacques LESCOT wrote:
>>> Ed,
>>>
>>> Thanks for your fast answer.
>>>
>>> In a first time, I am playing with the ZipFileSystem example
>>> referenced in my previous post [1]. First, I zipped a simple ecore
>>> model into a zip file, and try to open it using the Tree Structure
>>> editor. Opening is done well, but when I select an element in the
>>> editor, some commands are preparing and the isReadOnly() method from
>>> AdapterFactoryEditingDomain class try to detect whether the selected
>>> Resource is readonly from its EMF uri. At this point, the EMF uri
>>> equals "platform:/resource/test/My.zip/My.ecore". URI resolvment
>>> failed with the given URI (see the ZipEFS.png attached file to
>>> better see the context)
>>>
>>> Here is the Exception I got :
>>>
>>> java.lang.NullPointerException
>>> at
>>> org.eclipse.core.internal.resources.PlatformURLResourceConne ction.resolve(PlatformURLResourceConnection.java:66)
>>>
>>> at
>>> org.eclipse.core.internal.boot.PlatformURLHandler.openConnec tion(PlatformURLHandler.java:67)
>>>
>>> at
>>> org.eclipse.osgi.framework.internal.protocol.URLStreamHandle rProxy.openConnection(URLStreamHandlerProxy.java:112)
>>>
>>> at java.net.URL.openConnection(Unknown Source)
>>> at
>>> org.eclipse.core.internal.runtime.PlatformURLConverter.toFil eURL(PlatformURLConverter.java:33)
>>>
>>> at
>>> org.eclipse.core.runtime.FileLocator.toFileURL(FileLocator.j ava:165)
>>> at
>>> org.eclipse.emf.common.CommonPlugin$Implementation.asLocalUR I(CommonPlugin.java:177)
>>>
>>> at
>>> org.eclipse.emf.common.CommonPlugin.asLocalURI(CommonPlugin. java:85)
>>> at
>>> org.eclipse.emf.edit.domain.AdapterFactoryEditingDomain.isRe adOnly(AdapterFactoryEditingDomain.java:808)
>>>
>>> ...
>>>
>>>
>>> Things are better when I use URI.createURI() method instead of
>>> URI.createPlatformURI() in the createModel() method of the
>>> EcoreEditor class.
>>>
>>> For example, I changed :
>>> URI resourceURI = EditUIUtil.getURI(getEditorInput());
>>> by URI resourceURI = URI.createURI(((IFileEditorInput)
>>> getEditorInput()).getFile().getLocationURI().toString()); in the
>>> createModelGen() method.
>>>
>>> But using an unknown scheme ("ras" for example) than the "zip" one
>>> is needed so that the Resource is not handled as an archive one.
>> EMF does have a URI handler to deal with EFS-based URIs.
>>>
>>> Then, it is not possible to edit the My.ecore file (contained in the
>>> My.zip file), the file is considered always as readonly. I must then
>>> override the isReadOnly() method in the AdapterFactoryEditingDomain
>>> class to enable modifications :
>>>
>>> protected boolean isReadOnlyURI(URI uri) {
>>> if ("ras".equals(uri.scheme()))
>>> return false;
>>> return super.isReadOnlyURI(uri);
>>> }
>>>
>>>
>>> That's why I really wonder whether EMF fully support Eclipse File
>>> System implementation different from the LocalFileSystem one.
>> There is direct support for EFS URIs. I did explore changing the
>> above to use the new read only support of the URI converter, but the
>> problem is that some folks rely on being able to edit read-only
>> resource and use that to automatically check files out of a
>> repository, so I didn't know how to make it work without breaking
>> that and didn't have time...
>>>
>>>
>>> All those concepts are still quite confusing for me, so I do not
>>> really know which component is responsible of this unexpected behavior.
>> I don't think the platform's URL handler should have just barffed.
>>>
>>> So I really appreciate your comments and maybe some experiments you
>>> could had to open/edit an ecore model contained in a zip file.
>> I have two days of meetings so I won't have much time until next week.
>>>
>>> Regards,
>>> Jacques
>>>
>>> Ed Merks a écrit :
>>>> Jacques,
>>>>
>>>> Comments below.
>>>>
>>>> Jacques LESCOT wrote:
>>>>> Hi all,
>>>>>
>>>>> - I need to implement a sort of "archive" model corresponding to a
>>>>> unique file containing a set of model files : the goal of this
>>>>> work would be to improve model management when a model references
>>>>> another one and help users to share their models (it is easier to
>>>>> send a single file than a set of files with references between them).
>>>> You could store a bunch of files in a single zip file...
>>>>>
>>>>> - A basic use case would be for example to provide a single file
>>>>> containing the domain model and the notational one of a GMF
>>>>> editor. This mechanism could be activated (a single "archive"
>>>>> model is used) or not (domain model and notational one are
>>>>> separated, as default). Ideally, I would like also that depending
>>>>> on the storing method the user choosed, references are kept
>>>>> without any changes in the XMI files.
>>>> I suppose two files contained by a single zip would fit the bill
>>>> still...
>>>>>
>>>>> - Files that are stored in the "archive" model should be
>>>>> extensible (it should be also possible to add a configuration
>>>>> file, an OCL rule file, ....) : in fact I guess it should be an
>>>>> implementation of the Reusable Asset Specification [1].
>>>> Zip files seem good from this perspective too.
>>>>>
>>>>> - To implement this mechanism I think of a way to add my own
>>>>> FileSystem (based on the Zip [2] one). However the "archive" model
>>>>> should not be saved as a binary file : it should be possible to
>>>>> easily synchonise with a CVS repository for example. The solution
>>>>> would consist in the concatenation of the model files...
>>>> Bummer. Zip files are binary...
>>>>>
>>>>> - Do you know whether a similar implementation/work that I am not
>>>>> aware of have already been implemented/started ?
>>>> Of course XMIResourceImpl allows you to contain an arbitrary number
>>>> of root objects in a single resource and produce one combined XML
>>>> serialization.
>>>>>
>>>>>
>>>>> Any comment would be highly appreciated.
>>>> Zip files are already supported when
>>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=84327 was
>>>> completed. I wonder though if putting a bunch of related files
>>>> under a single folder and zipping them when you want to share them
>>>> with someone else doesn't accomplish much the same goal...
>>>>>
>>>>> Regards,
>>>>> Jacques
>>>>>
>>>>>
>>>>> [1] http://www.omg.org/technology/documents/formal/ras.htm
>>>>> [2]
>>>>> http://wiki.eclipse.org/index.php/EFS#UI_Examples:_Zip_and_M emory_file_systems
>>>>>
>>>
>>>
>>> ------------------------------------------------------------ ------------
>>>
>>>
>>
|
|
|
Goto Forum:
Current Time: Fri Apr 19 09:50:09 GMT 2024
Powered by FUDForum. Page generated in 0.01959 seconds |
] 
Search
Help
Register
Login
Home
