Bug: "bin/omero web start" doesn't pick up file changes

[bpindelski]

As an offshoot from #9302, it has been discovered that bin/omero web start and the underlying manage.py collectstatic only copies files to dist/lib/python/omeroweb/static that are missing in the target directory. Any changes to existing files are not picked up. Only removing contents from /static triggers a copy of resources.

Django 1.4 has a special static file storage class (django.contrib.staticfiles.storage.CachedStaticFilesStorage) that versions files by their MD5 hash. It might be worth investigating.

[wmoore]

Hmmm: ​https://docs.djangoproject.com/en/dev/ref/contrib/staticfiles/#django.contrib.staticfiles.storage.CachedStaticFilesStorage states "The purpose of this storage is to keep serving the old files in case some pages still refer to those files, e.g. because they are cached by you or a 3rd party proxy server". So it's not really designed to fix the problem above. Seems like there are other deployment and admin burdens associated with this too. Also we're not on this version of Django yet, so for now we'll have to work-around the sync failure.

This is not so bad, since when developing OMERO.web (static files changing a lot) we tend to run the development server via

$ cd components/tools/OmeroWeb/omeroweb
$ python manage.py runserver

Don't need to copy static files (served from original location)

[jmoore]

Will, I'm re-opening this. It may be that we can't have django automatically pick up changes, but we will definitely need to come up with a solution for the webstart issue, or at least be very clear in the documentation. (One specific use case that you can imagine is having someone drop in new bioformats jars to fix some issue)

[wmoore]

I guess we could add our own check into bin/omero web start?

[jburel]

Moved from sprint 2012-08-28 (3)

[wmoore]

Won't have time to investigate and work on this for 4.4.4

[jmoore]

Blazej, then we need to say as much under limitations, no?

[bpindelski]

It wouldn't hurt to point out what the user can and also shouldn't expect from this specific behavior. We could then refer to those limitations in the jar signing doc.

[jmoore]

Ok, I'll do that. I will be touching limitations.html tomorrow.

[wmoore]

http://www.openmicroscopy.org/site/support/omero4/sysadmins/limitations.html

[wmoore]

Seems that Django 1.4 has a --clear option on collectstatic: ​https://docs.djangoproject.com/en/dev/ref/contrib/staticfiles/#collectstatic which probably does what we want.

But even this will not affect jars under OMERO_DIST/lib/insight/. So we'd need to handle these ourselves (Even if we update Django from 1.3 -> 1.4).
However, I've never seen anything in OMERO_DIST/lib/insight on my local machine and can't find any docs on building these.

[jmoore]

What do you mean "will not affect jars under..."? Just to be clear, the goal is just to have collectstatic copy any new files from under lib/insight to whereever they are copied on initial creation.

[wmoore]

Ah - OK, I'm still learning about webstart. I see that it is added to the 'installed apps' and 'static dirs' in Django.

Also I find that if we simply remove the destination folder then the files will be replaces by collectstatic.
Is it too painful to remove and replace every time we do bin/omero web start?

[jmoore]

Too painful? Probably not. It's certainly slower, but correctness would be my preference over speed.

[jmoore]

(In production web will only be stopped/started infrequently. If you want to speed things up for devs, you could prevent the removal: bin/omero web start --fast )

[wmoore]

​https://github.com/openmicroscopy/openmicroscopy/pull/404

[Blazej Pindelski <bpindelski@…>]

(In [3145d2a039ee1b4abfaa62e20fc54e31b24f1d2c/ome.git] on branch develop) Update timestamp when signing JARs (See #9370)

[jean-marie burel <j.burel@…>]

(In [83578523c2ca208e8d1c4da0b380765620cbfc1b/ome.git] on branch develop) Merge pull request #424 from bpindelski/jarsign_timestamp

Update timestamp when signing JARs (See #9370)