Le 9 janv. 2014 à 19:43, Charles Duffy <char...@dyfis.net> a écrit :
> On Thu, Jan 9, 2014 at 12:17 PM, Nicolas Lalevée <nicolas.lale...@hibnet.org >> wrote: > >> Yep, a quite hard problem to resolve. At the ant task level I don't know >> how you could nail it without asking the end user to call some ivy:lock >> task. >> > > I'd like to argue that for ant tasks, a default behavior of releasing locks > only on process shutdown should be adequate -- ant invocations not being > long-lived by nature. I was just thinking about locking the usual configure - resolve - retrieve - report, but I forgot that to run tests you need a classpath which needs to continue to exist on disk. You're right, releasing at shutdown seems to fit every usual use case. > IDE plugins alter this a bit... but then, is it really safe to delete > caches while a running IDE expects them to persist? I think there will be some trouble with Eclipse users if IvyDE starts using locks. I remember IvyDE bugs on Windows where users would complain they cannot delete files because IvyDE via Eclipse was holding a reference to them. Since it is in an IDE and humans have only one brain, let's assume they only do one thing at a time, they are not ivy:cleaning via ant and running something in Eclipse at the same time, at least not on a daily basis. If they do, then thing will expectedly break, and the break is quite understandable. And actually Eclipse is having a layer of cache upon the filesystem, which make errors on file search if the cache is not in sync, generate unsolvable bugs [1]. So I guess it will be OK if Eclipse show errors on such concurrent use case, users should be used to it. To come back to the original topic, and to answer the use case about allowing to "safely" run an ivy:clean next to an ivy:resolve-and-others, for instance for the use case of a CI server, the IvyContext will not have an enough wide scope. The jvm shutdown hook should be better used, right ? And it should be optional so that in IDE like in IvyDE, locks can be disabled and won't be an issue. >> I myself don't have much experience with file based lock mechanism between >> different process. For instance what happens if a process holding a lock is >> killed -9, or whatever which make the jvm not even able to trigger its >> shutdown hooks ? >> > > I would only propose to support this with NIO locks in use. These are > implicitly released on file descriptor release, even when this is caused by > SIGKILL, power termination, etc. I didn't know, that is nice. Nicolas [1] https://issues.apache.org/jira/browse/IVYDE-302 --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
