[jira] Created: (IVY-356) Resolve Slowness in 1.4.1

["David R Robison (JIRA)" <ji...@apache.org>]

Resolve Slowness in 1.4.1
-------------------------

                 Key: IVY-356
                 URL: http://issues.apache.org/jira/browse/IVY-356
             Project: Ivy
          Issue Type: Improvement
          Components: Ant
    Affects Versions: 1.4.1
         Environment: Windows XP Ant 1.6.5
            Reporter: David R Robison


Copied from e-mail log:

On 12/14/06, David R Robison <dr...@openroadsconsulting.com> wrote:
>
> 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


JIRA is now migrated on ASF infrastructure, so you can use it to file an
improvement issue. Then we'll see if somebody in the community provide a fix
for it. I can't say if it'll be part of the next release or not, the plan
for the next release is more focused on apache migration, code cleaning and
additional testing for the moment.

Xavier

Xavier Hanin wrote:
> > On 11/21/06, David R Robison <dr...@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
>
>
>
>
>



-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira