Eclipse Community Forums: EMF » Resolving relative path in standalone application

Help

Home

Home » Modeling » EMF » Resolving relative path in standalone application

Show: Today's Messages :: Show Polls :: Message Navigator

Resolving relative path in standalone application [message #1558629]

Sun, 11 January 2015 16:00

Hiroki Kondo

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,

Report message to a moderator

Re: Resolving relative path in standalone application [message #1560380 is a reply to message #1558629]

Mon, 12 January 2015 15:10

Ed Merks

Messages: 33140
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,

Ed Merks
Professional Support: https://www.macromodeling.com/

Report message to a moderator

Re: Resolving relative path in standalone application [message #1561513 is a reply to message #1560380]

Tue, 13 January 2015 06:14

Hiroki Kondo

Messages: 47
Registered: July 2009

Member

Hello, Ed Merks.

I understand the EMF's URI behavior.

Thank you.

Report message to a moderator

Re: Resolving relative path in standalone application [message #1562213 is a reply to message #1561513]

Tue, 13 January 2015 15:13

Hiroki Kondo

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,

Report message to a moderator

Re: Resolving relative path in standalone application [message #1562329 is a reply to message #1562213]

Tue, 13 January 2015 16:42

Ed Merks

Messages: 33140
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,

Ed Merks
Professional Support: https://www.macromodeling.com/

Report message to a moderator

Re: Resolving relative path in standalone application [message #1570640 is a reply to message #1562329]

Sun, 18 January 2015 05:45

Hiroki Kondo

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,

Report message to a moderator

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

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Wed Apr 24 23:21:10 GMT 2024

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter