scoping and datatype side effect

[Gilles Scokart <gs...@gmail.com>]

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?

Gilles

Re: scoping and datatype side effect

[Eric Crahen <er...@gmail.com>]

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 <xa...@gmail.com> wrote:
>
> On 3/27/07, Gilles Scokart <gs...@gmail.com> 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

Re: scoping and datatype side effect

[Xavier Hanin <xa...@gmail.com>]

On 3/27/07, Gilles Scokart <gs...@gmail.com> 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
>
>
>