Exactly what I had in mind 👍 Gintas
2017-07-17 22:32 GMT+02:00 Jan Matèrne (jhm) <apa...@materne.de>: > Maybe you could set the timeout strategy globally: > /ivysettings/resolvers/@timeout-constraint > > <ivysettings> > <timeout-contraints> > <timeout-constraint name="smaller-timeout" connection-timeout="" > read-timeout="" /> > ... > </timeout-constraints> > > <resolvers timeout-constraint="global-timeout"> > <ibiblio timeout-constraint="smaller-timeout" ... /> > </resolvers> > </ivysettings> > > > Jan > > > > -----Ursprüngliche Nachricht----- > > Von: jai.forums2...@gmail.com [mailto:jai.forums2...@gmail.com] > > Gesendet: Montag, 17. Juli 2017 06:56 > > An: dev@ant.apache.org > > Betreff: Re: Proposed changes for IVY-735 - Ability to specify timeouts > > > > I think, that's actually a good idea. Defining the timeout constraints > > separately as named constraints and then referencing them would allow > > reusing these values on whichever resolvers want to: > > > > <ivysettings> > > > > <timeout-contraints> > > > > <timeout-constraint name="smaller-timeout" connection-timeout="" > > read-timeout=""> > > > > ... > > > > </timeout-constraints> > > > > <resolvers> > > > > <ibiblio timeout-constraint="smaller-timeout" .../> > > > > </resolvers> > > > > </ivysettings> > > > > > > -Jaikiran > > > > > > On 14/07/17 10:33 PM, Gintautas Grigelionis wrote: > > > my €.02 : currently, all resolvers only have artifact patterns as > > > child elements, so I'd rather have the timeouts as attributes that > > > might use references, similarly to cache managers or latest > > > strategies. That would imply a global default that may be overridden > > individually. > > > > > > Gintas > > > > > > 2017-07-14 13:34 GMT+02:00 <jaikiran....@cloudfabrix.com>: > > > > > >> https://issues.apache.org/jira/browse/IVY-735 is a feature request > > >> where the users have asked for relevant timeouts while dealing with > > >> downloads. A few weeks back we had a very brief discussion in an > > >> unrelated mail where it was proposed that we allow configuring these > > >> timeout all the way from ivy settings. > > >> > > >> I have an initial proposal/attempt to implement this feature. The > > >> initial changes are here in my personal repo[1]. It's a work in > > >> progress commit which sets up the necessary interfaces and the flow > > >> to show what I have in mind. Before proceeding further, I would like > > >> some inputs on whether this looks fine. Here's a summary of what the > > changes are going to be: > > >> > > >> - Each (dependency) resolver will have the ability to specify > > >> "timeout constraints"[2]. > > >> > > >> - These timeout constraints will be specified while defining the > > >> resolver in the ivy settings file. Imagine something like: > > >> > > >> <ivysettings> > > >> > > >> <resolvers> > > >> > > >> <ibiblio ...> > > >> > > >> <timeout-constraints connection-timeout="" > > >> read-timeout=""/> > > >> > > >> </ibiblio> > > >> > > >> .... > > >> > > >> - Each of the resolver will then use these timeout constraints (if > > >> specified) while resolving the module descriptor and downloading the > > >> artifacts and dealing with those resources. > > >> > > >> - The absence of the timeout constraints will let the resolvers > > >> behave the way they do currently > > >> > > >> The changes in the linked commit deprecate some APIs which weren't > > >> using timeouts and are replaced by APIs which pass along (an > > >> optional) TimeoutConstraints[2]. > > >> > > >> In summary, the change being proposed is that (dependency) resolvers > > >> have the ability to specify these timeout constraints and then use > > >> them while dealing with module descriptors and artifacts. One thing > > I > > >> have (to some extent intentionally) left out is the ability to > > define > > >> a global Ivy settings level or "all resolvers" level > > >> timeout-constraints. That's because I'm not too sure if it adds much > > >> value instead of defining it at individual resolver level. I'm > > however open to adding that support as well. > > >> > > >> The linked commit currently doesn't have the necessary support for > > >> parsing these additional XML elements, but if this whole approach > > >> looks fine, I will take this further and make sure things work as > > expected. > > >> > > >> [1] https://github.com/jaikiran/ant-ivy/commit/e501d9deca78db8b9 > > >> 34f8a2710ebcfeaeb1456c8 > > >> > > >> [2] https://github.com/jaikiran/ant-ivy/commit/e501d9deca78db8b9 > > >> 34f8a2710ebcfeaeb1456c8#diff-cd8ed454a52f4afa779574f5600a0ccb > > >> > > >> > > >> -Jaikiran > > >> > > >> > > >> -------------------------------------------------------------------- > > - > > >> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For > > additional > > >> commands, e-mail: dev-h...@ant.apache.org > > >> > > >> > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional > > commands, e-mail: dev-h...@ant.apache.org > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org > For additional commands, e-mail: dev-h...@ant.apache.org > >
