Mailing-List: contact ivy-user-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: ivy-user@incubator.apache.org
Received-SPF: pass (herse.apache.org: domain of xavier.hanin@gmail.com
 designates 64.233.182.188 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references;
        b=FrdYyC7/tZ3Ut+dUN51Z6/l+g31qFYO9C+qu/AHnS//uawvysLp+kaDchbwQeeIU7cpQM8cE1zwZUtIEkgNh1J4fSHsDlw+7kmpUYoyyNmVg1YOXq4D8rp0vIat0XsbCxI9qXXYQ6emMv0436BmRcUL9g5cDsKP0AKXfCMxFXDc=
Message-ID: <635a05060612060830kcf267a0od471d774fd7aab03@mail.gmail.com>
Date: Wed, 6 Dec 2006 17:30:06 +0100
From: "Xavier Hanin" <xavier.hanin@gmail.com>
To: ivy-user@incubator.apache.org
Subject: Re: Resolving latest "integration" artifacts
In-Reply-To: <48568.204.246.8.179.1165420273.squirrel@mail.isthmusgroup.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_33534_28848923.1165422606838"
References: <42768.204.246.8.179.1165351894.squirrel@mail.isthmusgroup.com>
	 <635a05060612051516r4e5b6334wce08d552c946991@mail.gmail.com>
	 <47224.204.246.8.179.1165417740.squirrel@mail.isthmusgroup.com>
	 <e9d8a2610612060746x92736e7u368d9669323a8f1e@mail.gmail.com>
	 <48568.204.246.8.179.1165420273.squirrel@mail.isthmusgroup.com>

------=_Part_33534_28848923.1165422606838
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

On 12/6/06, John Brugge <John.Brugge@isthmusgroup.com> 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


Definitly

> 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.

Xavier

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

------=_Part_33534_28848923.1165422606838--