|
||||||||
|
This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira |
||||||||
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
Should also consider whether identifying items by relative path was a good idea to begin with. It is not always easy or even possible to evaluate a relative path when the value is needed. During form validation you can usually use hacks like @AncestorInPath to guess at the context, though not always; and there is no equivalent magic thread-local variable (that I know of) available during deserialization (Converter.unmarshal).
And what was the purpose? Depending on the UI control chosen, it is not necessarily more convenient for users. It is not necessary in order to order to maintain relationships between jobs in folders created from template, since you could simply ensure that the target folder path is a variable available during template expansion. It could be used to ensure that sets of related jobs behave the same way when moved or copied to another folder, but renaming jobs—and moving only dependent jobs to other folders—anyway requires that you search for and update item name references, whether they are relative or absolute.