ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Xavier Hanin" <xavier.ha...@gmail.com>
Subject Re: publishing war files
Date Sat, 11 Nov 2006 10:29:16 GMT
On 11/10/06, Stephane Bailliez <sbailliez@gmail.com> 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
>
>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message