Home » Modeling » EMF » Resolving relative path in standalone application
|Re: Resolving relative path in standalone application [message #1560380 is a reply to message #1558629]
||Mon, 12 January 2015 15:10
| Ed Merks
Registered: July 2009
On 11/01/2015 5:00 PM, Hiroki Kondo wrote:
> 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
> But it cannot resolve the correct URI...
> I'd like to understand the meaning of "platform" scheme in standard
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
> 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
|Re: Resolving relative path in standalone application [message #1562329 is a reply to message #1562213]
||Tue, 13 January 2015 16:42
| Ed Merks
Registered: July 2009
On 13/01/2015 4:13 PM, Hiroki Kondo wrote:
> 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.
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
> 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.
Current Time: Tue May 21 18:32:17 GMT 2019
Powered by FUDForum
. Page generated in 0.01543 seconds