On 3/27/07, Gilles Scokart <[EMAIL PROTECTED]> wrote:
I started to try to scoping for the ivy:settings with the same idea than Maarten (<ivy:settings id="my-settings" settings="settings.xml" /> <ivy:resolve resolveId="my-resolve" settingsRef="my-settings" /> <ivy:cachepath resolveId="my-resolve" settingsRef="my-settings" />) And during the test I notice a side effect that I didn't expected. The trace of the old configure task are now present in the first task to use the settings (of curse, you would say). For the settings, it is not really an issue. However, if we go up to the ivy:cachepath datatype, it might be more problematic. We could end with all the resolve traces under a [java] task, which might be disappointing for the user. We should probably see it in action before really evaluate the impact, but that's a potential issue. What is your feeling about that?
I agree that users will certainly be disapointed by traces like that, but fortunately we can control the output. It will require some more work on the Messages API, but I think we can log using another task logger, and thus seeing the configure trace in the settings or configure task, even if it's triggered by a cachepath in java. BTW, according to your discussion about datatype lifecycle on ant mailing list, I think the major concern for now is that datatype have no real lifecycle, so I don't think converting cachepath and cachefileset to datatypes is a good idea with current Ant version. - Xavier Gilles
