Indeed, that's a consequence of using a datatype instead of a task. As a
workaround you can use the deprecated configure task. We still need to
finalize a decision about what we do with settings and configure, from what
we discussed some time ago I think we may end up making settings a task,
hence allowing to have it loaded as soon as declared.
BTW, for cleaning the cache there is the ivy:cleancache task which avoid the
problem of locating the cache location using a property.
Xavier
On Nov 28, 2007 4:55 PM, jonathan doklovic <[EMAIL PROTECTED]> wrote:
> Hi,
>
> after working on a complex reusable build system with Ivy, it has become
> somewhat annoying that there's no "good" way to get at the default
> properties that ivy sets.
>
> Mainly, things like ivy.default.ivy.user.dir and
> ivy.default.settings.dir are very useful to have inside of ant, but
> outside of any ivy tasks.
>
> For instance, a simple cache clean target *should* be able to use
> ${ivy.default.ivy.user.dir}/cache
>
> Unfortunately, there's currently no way to get these properties set
> other than something like this:
>
> <ivy:settings id="ivy.default.settings.loader"/>
> <ivy:var
> settingsref="ivy.default.settings.loader"
> name="ivy.loaddefaults"
> value="true"/>
>
> This essentially sets the ivy settings xml, and then calls the var task
> simply to load the default file.
>
> It would be better if the settings task had an attribute like:
> load="true" which would immediately load the settings file.
>
> Better yet, it would be nice to have a <settings loadprops="true"/>
> which would only set the default properties.
>
> - Jonathan
>
>
--
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://ant.apache.org/ivy/
http://www.xoocode.org/
