This is now available for review https://github.com/apache/ant-ivy/pull/38
-Jaikiran On 02-Jun-2017, at 5:39 PM, Jan Matèrne (jhm) <apa...@materne.de> wrote: +1 Jan > -----Ursprüngliche Nachricht----- > Von: Nicolas Lalevée [mailto:nicolas.lale...@hibnet.org] > Gesendet: Freitag, 2. Juni 2017 12:39 > An: Ant Developers List > Betreff: Re: IVY-1475 - cachefileset task and its inherent limitation > > >> Le 2 juin 2017 à 12:05, J Pai <jai.forums2...@gmail.com> a écrit : >> >> So that does mean cachefileset has a role to play in at least some > cases. In that case, I think the approach we could take is to _not_ > deprecate it and instead include this limitation as part of the > documentation *and* enhance the code of this task to explicit fail with > a proper error when it can’t determine a common base directory. >> > > Sounds good to me. > > Nicolas > > >> -Jaikiran >> On 02-Jun-2017, at 2:55 PM, Nicolas Lalevée > <nicolas.lale...@hibnet.org> wrote: >> >> >>> Le 2 juin 2017 à 08:22, Jan Matèrne (jhm) <apa...@materne.de> a > écrit : >>> >>> From a naive user point of view, it doesnt matter (to me) if I use >>> ivy:chachefileset or ivy:resources. >>> I want to specify the dependency and have a 'thing' which contains >>> all required jars, so I could use external tasks/antlibs. >>> >>> Ant itself moved from fileset to resource collection some years ago > and Ivy could follow. >>> But I am not sure that we could use RCs _everywhere_. >>> In the few exceptions you have to use ivy:cachefileset - maybe >>> multiple … >> >> One limitation of resource collections is that they doesn’t have >> necessarily a basedir, contrary to a fileset :) For instance a > basedir it is quite useful for the copy task, so a set of files be be > copied with their relative paths to the basedir, rather than with their > absolute paths. >> >> Nicolas >> >>> Jan >>> >>>> -----Ursprüngliche Nachricht----- >>>> Von: J Pai [mailto:jai.forums2...@gmail.com] >>>> Gesendet: Freitag, 2. Juni 2017 05:29 >>>> An: Ant Developers List >>>> Betreff: IVY-1475 - cachefileset task and its inherent limitation >>>> >>>> One of the Ivy users has pointed out to an issue in cachefileset >>>> task[1] of Ivy here https://issues.apache.org/jira/browse/IVY-1475. >>>> >>>> To summarize, the cachefileset task is expected to create a Ant >>>> Fileset of the resolved artifacts in the cache(s). Ant Fileset >>>> requires a >>>> (single) basedir to work on and the Ivy cachefileset has a piece of >>>> logic which tries to determine a common base directory for the >>>> resolved artifacts. It’s very much possible that there won’t be a >>>> common base directory for artifacts if the caches have been >>>> configured to be on multiple different filesystem roots, as noted > in >>>> that JIRA. So essentially, to me, it looks like this cachefileset >>>> has an inherent deficiency which can’t really be fixed. >>>> >>>> The user in that JIRA notes that we can deprecate this task (and >>>> also add a note about this limitation) in favour of “resources” > task >>>> [2] which provides a similar functionality but is much more > flexible >>>> and doesn’t suffer this limitation. >>>> >>>> Any thoughts on how we should go about this JIRA and the >>>> cachefileset task? >>>> >>>> [1] https://ant.apache.org/ivy/history/latest- >>>> milestone/use/cachefileset.html >>>> [2] https://ant.apache.org/ivy/history/latest- >>>> milestone/use/resources.html >>>> >>>> -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 >> >> >> >> --------------------------------------------------------------------- >> 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 --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
