ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Xavier Hanin" <>
Subject Re: Resolving latest "integration" artifacts
Date Wed, 06 Dec 2006 16:30:06 GMT
On 12/6/06, John Brugge <> wrote:
> Well duh, now I see the 'deliver' task documentation. I'm not sure where
> my eyes were earlier. That part of the process makes a little more sense,
> although I'm still a little cloudy on it all. It's a complex process going
> on, or at least complex to try to describe in words.
> Gilles Scokart said:
> > If I'm not wrong, the deliver task writes the ivy.xml file that will
> > be published (the name might be changed I think).  I think that it
> > check if the file exist and if it does, the local file is unchanged
> > and will be reused for the publish.  That was probably the reason for
> > which you had to put an option to force a new deliver.
> >
> > I have no idea when it is usefull to reuse a delivered file, but there
> > is probably some use case.
> >
> > You story is very interresting.  If I follow you well, you have now at
> > least 3 defect to enter :
> > 1. The default generate ivy files stored in the cache should clearly
> > indicates it contains default values.

There is already something which indicates that: the attribute
default="true" on the info element of a default file. Maybe we could add
something more obvious, like a big comment at the beginning.

> 2. The ssh resolver errors should be reported on a higher level than debug


> 3. A warning should be printed when a deliverd ivy files is reused,

The confusion between deliver and publish and the few cases where people
really have to care about deliver make me think that it would be better to
have forcedeliver="true" by default, so that this step could be more easily
ignored. But my concern is about backward compatibility, changing this
behaviour would break some build using previous Ivy versions. That's why I'd
prefer changing the default behaviour only in a 2.0 version. But outputting
a warning (that people could easily disable with a property for instance) is
a good idea to ease the adoption.


I think those are good defects to add, and will help make the process more
> transparent to the users.
> thanks,
> John

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