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: local policy)
Message-ID: <4581758C.8040400@openroadsconsulting.com>
Date: Thu, 14 Dec 2006 11:02:20 -0500
From: David R Robison <drrobison@openroadsconsulting.com>
User-Agent: Thunderbird 1.5.0.8 (Windows/20061025)
MIME-Version: 1.0
To: ivy-user@incubator.apache.org
Subject: Re: 1.4.1 Resolve Slowness
References: <20061120023135.cb378b75@mail.openroadsconsulting.com>
	 <635a05060611200021p7bf4dbbes8bdb2cd737976a04@mail.gmail.com>
	 <4561B589.90400@openroadsconsulting.com>
	 <635a05060611200833n1a2f357bm69c514fbb57c290f@mail.gmail.com>
	 <4563268A.8030906@openroadsconsulting.com>
 <635a05060611211416q4a4d2bc8y256de834fad19329@mail.gmail.com>
In-Reply-To: <635a05060611211416q4a4d2bc8y256de834fad19329@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Is there any plans to fix this in the next release? It is really causing 
problems with time required to compile our system. Thanks, David Robison

Xavier Hanin wrote:
> On 11/21/06, David R Robison <drrobison@openroadsconsulting.com> wrote:
>>
>> I'm attaching the log from the "ant -d". The following, from the log,
>> looks interesting:
>>
>> [ivy:retrieve]     using default-chain to resolve [ xmlBlaster |
>> xmlBlaster | 1.4 ]
>> [ivy:retrieve] default-chain: no latest strategy defined: using default
>> [ivy:retrieve] orci: no namespace defined: using system
>> [ivy:retrieve] pre 1.3 ivy file: using exactOrRegexp as default matcher
>> [ivy:retrieve]     found ivy file in cache for [ xmlBlaster | xmlBlaster
>> | 1.4 ] (resolved by orci):
>>
>> C:\Workspaces\DataGateway\DataGateway-VDOT-OnCall-Task36\ivy\ivy-cache\xmlBlaster\xmlBlaster\ivy- 
>>
>> 1.4.xml
>> [ivy:retrieve]     orci: found revision in cache: [ xmlBlaster |
>> xmlBlaster | 1.4 ] (resolved by orci): but it's a default one, maybe we
>> can find a better one
>> [ivy:retrieve] orci: no latest strategy defined: using default
>> [ivy:retrieve]      trying
>>
>> http://www.openroadsconsulting.com/maven/xmlBlaster/jars/xmlBlaster-1.4.jar 
>>
>> [ivy:retrieve]     orci: no ivy file found for [ xmlBlaster | xmlBlaster
>> | 1.4 ]: using default data
>> [ivy:retrieve]         tried no ivy pattern => no attempt to find module
>> descriptor file for [ xmlBlaster | xmlBlaster | 1.4 ]
>> [ivy:retrieve]     checking [ xmlBlaster | xmlBlaster | 1.4 ][default]
>> from orci against null
>> [ivy:retrieve]     module revision kept as first found: [ xmlBlaster |
>> xmlBlaster | 1.4 ][default] from orci
>> [ivy:retrieve] ibiblio: no namespace defined: using system
>> [ivy:retrieve] pre 1.3 ivy file: using exactOrRegexp as default matcher
>> [ivy:retrieve]     found ivy file in cache for [ xmlBlaster | xmlBlaster
>> | 1.4 ] (resolved by orci):
>>
>> C:\Workspaces\DataGateway\DataGateway-VDOT-OnCall-Task36\ivy\ivy-cache\xmlBlaster\xmlBlaster\ivy- 
>>
>> 1.4.xml
>> [ivy:retrieve] found module in cache but with a different resolver:
>> discarding: [ xmlBlaster | xmlBlaster | 1.4 ]
>>
>>
>> It finds it in the cache but thinks there may be a better one so it
>> keeps looking. It eventually scans through all the configured
>> repositories and ends up using the one in the cache. Does anyone know
>> why it would not just use the one in the cache? Does this help any?
>
>
> OK, the problem is due to a modification in Ivy 1.4 which has a bad side
> effect in your case. When Ivy find a default module descriptor (i.e. a
> module descriptor generated because there is no ivy file for a 
> module), then
> in a chain it checks if there is no other element in the chain with a 
> real
> ivy file. This is the cause of your performance problem I think, so 
> the only
> workaround I see is to add an ivy file even for simple modules with 
> only one
> artifact. I'd also suggest submitting an improvement request in jira, but
> jira is currently in read only mode until it is migrated to apache.
>
> Xavier
>
> Thanks, David
>>
>>
>

-- 

David R Robison
Open Roads Consulting, Inc.
708 S. Battlefield Blvd., Chesapeake, VA 23322
phone: (757) 546-3401
e-mail: drrobison@openroadsconsulting.com
web: http://openroadsconsulting.com
blog: http://therobe.blogspot.com
book: http://www.xulonpress.com/bookstore/titles/1597816523.htm