I have to test jobs in a project where relative paths are used in file components, like "./sqlfolder/exec.sql". When the job is exported and run in a production setting using a UNIX-based OS, the paths are relative to the shell script, but when I press the Run button in TOS on Windows, relative paths start from "D:\Talend\TOS_DI-<version>\", and I would like to change that to something like "D:\Workspaces\Myproject\Project_One\Files\".
The solution is not to use a context variable with a root path, because I would have to append that in front of the relative paths used in every component.
Using "system" components for "cd" commands also seems to cause more problems for portability that it solves (the same code should run in Windows and UNIX environments).
Is there a way to achieve that ?
Many thanks in advance
Not a good idea (in my opinion). Also think the relative start path will change when you'll run jobs from outside of TOS.
Using context variables is the solution as you can concatenate their values with the partial filename in any component where you need a full pathname simply using
context.yourRootPath + "yourPath/yourFile"
context.yourRootPath + (String)globalMap.get("yourGlobalContiningFileName
Perhaps I wasn't clear enough, I am working on legacy code that I am not allowed to modify, the code cannot be tested in TOS as it is, only when exported, unless I move all the input files to Talend's installation folder, which would be a bad practice because we have multiple projects and multiple machines where Talend is installed.
It is either possible or not possible to change that folder before clicking the run button (without having to edit Talend's source code), since this folder is not randomly defined nor arbitrary, I believe someone knows at a technical level how this folder is defined (the run button calls talend.exe which calls the jar from the location of the exe maybe).
You don't have to move anything to Talend's installation folder.
Once again, concerning the input files (and files generaly speaking), the best practice is to define as many context variable as input folders with appropriate value depending on the context (DEV, UAT, PROD for example).
Please, explain the case for which it cannot works for you.