+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