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?
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]
_______________________________________________
