ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David R Robison <drrobi...@openroadsconsulting.com>
Subject Re: 1.4.1 Resolve Slowness
Date Thu, 14 Dec 2006 16:02:20 GMT
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

 



Mime
View raw message