Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » Resolving relative path in standalone application
Resolving relative path in standalone application [message #1558629] Sun, 11 January 2015 16:00 Go to next message
Hiroki Kondo is currently offline Hiroki KondoFriend
Messages: 47
Registered: July 2009
Member
Hi,

In some resources, they are referenced to other resources.
The resources's URI are relative.
How to resolve these resources in standalone application?

In my application, to resolve these resources by URIConverter#URI_MAP.
Some articles tells me to use EcorePlugin.getPlatformResourceMap().
But it cannot resolve the correct URI...

I'd like to understand the meaning of "platform" scheme in standard application.
In the Eclipse, "platform://resource" is the workspace location,
and "platform://plugin" is the plugin resources...
I read this article http://lmap.blogspot.jp/2008/03/platform-scheme-uri.html.
In the other side, I think "platform" scheme is not meaning in standard application,
So I'm mapping the resources in URIConverter#URI_MAP.
When should I use EcorePlugin.getPlatformResourceMap()?

Regards,
Re: Resolving relative path in standalone application [message #1560380 is a reply to message #1558629] Mon, 12 January 2015 15:10 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 30461
Registered: July 2009
Senior Member
Hiroki,

Comments below.

On 11/01/2015 5:00 PM, Hiroki Kondo wrote:
> Hi,
>
> In some resources, they are referenced to other resources.
> The resources's URI are relative.
> How to resolve these resources in standalone application?
As long as you use absolute URIs to load resources the relative URIs in
their contents will be resolved relative to that URI.
>
> In my application, to resolve these resources by URIConverter#URI_MAP.
> Some articles tells me to use EcorePlugin.getPlatformResourceMap().
Yes, you can always create a logical workspace-like mapping so that the
same URIs you used to load/save the resources from/to the workspace work
stand alone.
> But it cannot resolve the correct URI...
How so?
>
> I'd like to understand the meaning of "platform" scheme in standard
> application.
Note that the platform scheme has a real live registered
java.net.URLStreamHandler as defined by the Eclipse platform.
> In the Eclipse, "platform://resource" is the workspace location,
No, it's platform:/resource. It would have been more sensible for
"resource" to be the authority rather than the first segment, but
unfortunately that's not the case.
> and "platform://plugin" is the plugin resources...
> I read this article
> http://lmap.blogspot.jp/2008/03/platform-scheme-uri.html.
> In the other side, I think "platform" scheme is not meaning in
> standard application,
It's up to the application to decide what's meaningful. If one maps (in
the URI map) platform:/resource/<foo>/ to file:/C:/folder/project/ them
most certainly it's meaningful.
> So I'm mapping the resources in URIConverter#URI_MAP.
> When should I use EcorePlugin.getPlatformResourceMap()?
It's just a convenience for specifying a URI map, e.g., mapping <foo> to
file:/C:/folder/project/
>
> Regards,
Re: Resolving relative path in standalone application [message #1561513 is a reply to message #1560380] Tue, 13 January 2015 06:14 Go to previous messageGo to next message
Hiroki Kondo is currently offline Hiroki KondoFriend
Messages: 47
Registered: July 2009
Member
Hello, Ed Merks.

I understand the EMF's URI behavior.

Thank you.
Re: Resolving relative path in standalone application [message #1562213 is a reply to message #1561513] Tue, 13 January 2015 15:13 Go to previous messageGo to next message
Hiroki Kondo is currently offline Hiroki KondoFriend
Messages: 47
Registered: July 2009
Member
Hi,

Now I have another question.
I'd like to specify base directory when I call ExtensibleURIConverter#normalize(URI). The specified URI is relative path like "Default.profile.uml".

If the specified uri is relative path on the local system, it may run the line below.
https://github.com/eclipse/emf/blob/master/plugins/org.eclipse.emf.ecore/src/org/eclipse/emf/ecore/resource/impl/ExtensibleURIConverterImpl.java#L429

In standalone environment, [new File(relativePath)]'s base directory is the working directory -> System.getProperty("user.dir")
Some loading resources are not in the same directory. So I'd like to change the base directory.
I can change the base by System.setProperty("user.dir",theBaseDir).
I think it's not good way.

So I put all my resources in the resource's directory and walk in the file tree to put URI_MAP,
I could load all the content! Yey!

......But if the resource file is in the user's home directory,
the walking in the file tree logic is loaded all content in the home directory......

Why ExtensibleURIConverter#normalize(URI) doesn't provide the way to change the base directory for relative path?

Regards,
Re: Resolving relative path in standalone application [message #1562329 is a reply to message #1562213] Tue, 13 January 2015 16:42 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 30461
Registered: July 2009
Senior Member
Hiroki,

Comments below.

On 13/01/2015 4:13 PM, Hiroki Kondo wrote:
> Hi,
>
> Now I have another question.
> I'd like to specify base directory when I call
> ExtensibleURIConverter#normalize(URI). The specified URI is relative
> path like "Default.profile.uml".
The URI converter is generally working with URIs of resources and these
generally should not be relative URIs. So the use case is
questionable. Also, given it's UML, UML makes heavy use of "pathmaps"
so best to look into UML2's documentation.
>
> If the specified uri is relative path on the local system, it may run
> the line below.
> https://github.com/eclipse/emf/blob/master/plugins/org.eclipse.emf.ecore/src/org/eclipse/emf/ecore/resource/impl/ExtensibleURIConverterImpl.java#L429
>
Yes it certainly tried to find an absolute interpretation but best to
avoid that entirely.
>
> In standalone environment, [new File(relativePath)]'s base directory
> is the working directory -> System.getProperty("user.dir")
> Some loading resources are not in the same directory. So I'd like to
> change the base directory.
> I can change the base by System.setProperty("user.dir",theBaseDir).
> I think it's not good way.
No, the whole use case is questionable. Better to use something like a
logical absolute URI, i.e., like UML2's pathmaps.
>
> So I put all my resources in the resource's directory and walk in the
> file tree to put URI_MAP,
> I could load all the content! Yey!
>
> .....But if the resource file is in the user's home directory,
> the walking in the file tree logic is loaded all content in the home
> directory......
>
> Why ExtensibleURIConverter#normalize(URI) doesn't provide the way to
> change the base directory for relative path?
Because the whole use case is questionable and doesn't arise if you
follow the simple rule: use absolute URIs for all resources.
>
> Regards,
Re: Resolving relative path in standalone application [message #1570640 is a reply to message #1562329] Sun, 18 January 2015 05:45 Go to previous message
Hiroki Kondo is currently offline Hiroki KondoFriend
Messages: 47
Registered: July 2009
Member
Sorry, I resolved this issue.

When I get to load the resources, I should use URI.createFIleURI().
Because the resource in my machine. The relative path's contents are loaded when I wrote like below

ResourceSet resourceSet = new ResourceSet();
URI targetURI = URI.createFileURI("The local file path");
resourceSet.getResource(targetURI,true);


EMF resolves the relative URI.

At the first, I specified URI.createURI() like below.

ResourceSet resourceSet = new ResourceSet();
URI targetURI = URI.createURI("The local file path"); // NG
resourceSet.getResource(targetURI,true);


If the resource contains the relative uri path, it cannot open the contents in the relative path resources.

Regards,
Previous Topic:Annotated Java import missing
Next Topic:Generated extensions to Switch<T> are failing null analysis
Goto Forum:
  


Current Time: Sun Sep 22 11:54:57 GMT 2019

Powered by FUDForum. Page generated in 0.02226 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top