On 12-01-03 01:45 PM, Markus Moormann wrote: > Hi Tobias, > > some comments inline >> Hi Markus, >> >>> > I'm sorry, I'm not really up2date because I missed the dev meeting, but I >>> > think it's not usefull to change java tmp dir for felix when we can also >>> > change "org.opencastproject.storage.dir" in config.properties by default >>> > to a non tmp directory. So no data will be lost and one can change it to >>> > tmp dir if one needs to. >> You've got a valid point here. However, there are still 24 mentions of >> "java.io.tmpdir" in the codebase, which is a good hint that we should at >> least think about that directory. > I had a look at those mentions and most of it are tests, which seems > fine to me. Some of them are not clear to me. So there are only 5-10 > left to check. >>> > For example I'm quite happy to have a clean matterhorn each time I start >>> > my computer when starting to develop. Temp directories are meant to be >>> > temporary and not to be misused as something different. >> There are two problems with this: First of all, the tmp directory is only >> cleared on *some* architectures, not on all. So we are looking at >> inconsistencies in behavior, which makes it hard for us to reproduce bugs >> related to it. Second, as a developer you should be able to setup your >> development environment as you need it, including or excluding cleanup on >> restart. What I am proposing is a solution that will make test deployments >> more stable. > I agree, that deployments needs to be more stable. I think the best way > to get there is to check all mentions of "java.io.tmpdir" in the > codebase, whether they are really used as tmp or used as real saving > directory. > Furtheron we can change the default "org.opencast.storage.dir" to > something different as "java.io.tmpdir" such as "$FELIX_HOME/work". So a > developer can apply this to his own needs. Further on one could add a > further parameter to config.properties that matterhorn should clean all > data at start (org.opencast.cleanOnStartup = false;) But I think the > most effective way for a developer is to change storage.dir. What do you > think?
The problem is not that Matterhorn clears the directory, it is that the underlying OS clears it. This is the same problem we had way back when the project first started where people did not realize that all of their data lived in RAM. At least until they rebooted. It's easy for a developer/adopter to clear the files manually if they want to rather than trust in the OS to clear things on reboot. We should make it harder to lose all your data, not easier. G > Markus >> >> >From my point of view, we need to improve the installation experience at >> >all cost, developers will anyway invest much more time in their setup. But >> >with problems like this, we'll lose potential adopters. And at least this >> >one pitfall would be easy to remove. >> >> Tobias >> _______________________________________________ >> Matterhorn mailing list >> [email protected] >> http://lists.opencastproject.org/mailman/listinfo/matterhorn >> >> >> To unsubscribe please email >> [email protected] >> _______________________________________________ >> > > > _______________________________________________ > Matterhorn mailing list > [email protected] > http://lists.opencastproject.org/mailman/listinfo/matterhorn > > > To unsubscribe please email > [email protected] > _______________________________________________
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Matterhorn mailing list [email protected] http://lists.opencastproject.org/mailman/listinfo/matterhorn To unsubscribe please email [email protected] _______________________________________________
