I agree. Given that I think its better to stick with tasks that produce properties and references to Paths and filesets.
On 3/27/07, Xavier Hanin <[EMAIL PROTECTED]> wrote:
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 > > >
-- - Eric
