You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It's hard to refer to resources in Rascal in a consistent manner.
For source projects the project scheme works, but that is different from after deployment.
For deployed projects the lib scheme works, but it can be ambiguous due to different versions of the same library at run-time
Proposal:
add to util::Reflective:
loc getModuleRoot("my::module::Name") - produces the result of looking for /my/module/Name.rsc in the interpreter's search path and returns the root src folder. For the compiler it will return getClass("my.module.Name").getResource("/")
loc getModuleResource("my::module::Name", myPath) will use the child location of getModuleRoot with myPath appended to it.
The idea would be that the behavior of this function would abstract from a project source or a deployed situation. In either situation the output loc is different (one is a project source directory, the other is inside a jar file), but the same files would be found.
The user must make sure that resources end up in the target folder in the right place to make the above true.
The text was updated successfully, but these errors were encountered:
It could be that an answer to #1827 makes this a lot easier. There could be several instances of the URIResolverRegistry singleton, each for an application in which module://moduleName would indeed resolve to a unique module path. Or getModuleRoot would have a unique resolution within that layer.
It's hard to refer to resources in Rascal in a consistent manner.
project
scheme works, but that is different from after deployment.lib
scheme works, but it can be ambiguous due to different versions of the same library at run-timeProposal:
util::Reflective
:loc getModuleRoot("my::module::Name")
- produces the result of looking for/my/module/Name.rsc
in the interpreter's search path and returns the root src folder. For the compiler it will returngetClass("my.module.Name").getResource("/")
The idea would be that the behavior of this function would abstract from a project source or a deployed situation. In either situation the output
loc
is different (one is a project source directory, the other is inside a jar file), but the same files would be found.The user must make sure that resources end up in the target folder in the right place to make the above true.
The text was updated successfully, but these errors were encountered: