ANT script: issue with external reference in input file

[YvesTLS]

I have a transformation that executes without issue while when started from an eclipse "ATL EMFTVM" launcher. This transformation requires several UML input files that have external references (for property types, generalizations, etc...). However when I try executing it using an ANT script, the external references cannot be resolved.

I double checked the script against the run configuration in order to verify that all the models and metamodels used are declared in a same way. What could explain this difference and how can this problem be solved?

[YvesTLS]

I succeed in building a simple test case that reproduce the issue.
In the "ATL_Test2" sample attached, executing in using the Eclipse launcher "ATL_Test2.launch" or using the ANT script "Ant_Test2.xml" does not provide the same result.
The trace get from the .launch is
'Starting: Test2...'
key: 'MyProfile::ModelLibrary'
super types: Sequence{StereotypeDefinition:UML!Stereotype}
super type names: Sequence{'StereotypeDefinition'}

While the traces got from the Ant script is:
'Starting: Test2...'
key: 'MyProfile::ModelLibrary'
super types: Sequence{559cd4c4:UML!Stereotype}
super type names: Sequence{OclUndefined}

My interpretation is that, when run from an Ant script, ATL cannot resolve properly the external reference (href) in XMI files.

Also I notice that in some cases, Ant scripts can have issues for dealing with file paths that include space characters, implying to use an escape sequence (i.e. '%20') instead. I never had this issue with Eclipse launchers.

So it looks like the code managing the model loading is not the same in both cases. Is there a bug in the one used by Ant or do I miss something?
ATL_Test2.zip

[dwagelaar]

If you run your Ant script within the same JRE as your Eclipse instance, it should have full access to the Eclipse environment. If you look into the UML XMI source, what form do these external references have?

[dwagelaar]

I will look into your example...

[dwagelaar]

Found the issue: you need to prefix your (meta-)model URIs with platform:/resource/ if you want relative hyperlinks to work.

[YvesTLS]

Very good, thank you: you found it!

However, for those who are interested, let's add the following comments:

1. using this prefix for a ressource to be load implies using the "uri" parameter, because it doesn't work with "wspath"
2. for a resource to be saved, the "uri" parameter is not available, "wspath" is used instead and so that prefix shall NOT be used.