On 11/10/06, Stephane Bailliez <[EMAIL PROTECTED]> wrote:
Steve Loughran wrote:
>
> No, I fixed it. I had to delete the ivy xml file created in dist/ next
> to the WAR and the rebuild would recreate it...it looks like ivy
> doesnt recreate this file if the source ivy.xml file has changed.
Indeed, common source of mishaps that happen, my build process is
constantly getting rid of it as I have learned it the hard way.
That's certainly part of the thing that needs to be fixed.
What I would like for any subsequent release is to stop having too much
configuration entry points, too much assumptions and too much
autodecisions.
The fact that you can configure part of it with properties, other parts
with the xml that it does an auto configuration, auto resolve, if not
done, is creating more problem than it solve from my perspective. I
generally want thing to fail right away.
I understand your perspective, and personnally I prefer to call everything
explictly and always have all my configuration in the xml file. But I think
that it make things easier for the newbie (at least until they get
frustrated because something goes wrong :-)). Imagine that you want to use
Ivy only to get commons-collections artifacts in a directory. With those
default and auto calling things, you can do only that:
<ivy:retrieve organisation="apache" module="commons-collections" revision="
3.0" inline="true" pattern="${my.install.dir}/[artifact].[ext]"/>
Otherwise you would have to write an ivyconf.xml, and to call configure,
resolve and retrieve. It's a lot of things for a very simple use case.
So I personnaly think that we should keep such defaults and auto callings,
but improve them to make them more consistent, more obvious (on the
console), and better documented.
Xavier
-- stephane
