Download develop

[jburel]

Fix download of images see https://trac.openmicroscopy.org.uk/ome/ticket/10400
To test:

• Import a single image e.g. jpeg.
  • Download the image
  • Check that the file is the same.
• Import a multi-image file e.g. lei
  • download the image
  • Check that a zip is created.
  • unzip.
  • Check that all the files are there.

Note : the last commit d2b7c42 will have to be cherry-picked

---

--rebased-to #1089

[mtbc]

Travis failure is just >50min test run, it looks like.

[mtbc]

I'm not sure when we should add them here versus adding to the actions in components/model/resources/ome/util/actions/*.properties.

[mtbc]

Update: @joshmoore kindly explains that HQL (for now) goes in our code, it's only SQL in those properties files.

[mtbc]

Under the suggested testing, this PR seems to work well. (The only problem I observe is that, although the downloaded zip from 050118.lei has all the files I'd expect, and they do seem to be distinct TIFFs, if I try showinf on any one of them it shows me only blackness -- but I think that's okay and that the data is actually properly in those files.)

It might be nice if the image files in the zipfile were all in a folder therein, perhaps named for the multi-image file from which they originally came, so they don't just get dumped into the (possibly already crowded) current directory upon extraction, but that can be a to-do for the future.

Despite the above musings, from my point of view this PR is good to merge.

[jburel]

I have only fixed the calls in order to get it to work.
While reviewing that code, major points:

• Heavy usage of query.get(OriginalFile.class, id) so the problem noticed while loading the original data could happen in several places in the stack.
  • Currently when we download the original file, no checksum check.
• Name of imported image to sort out, setting to the path the image is going from is not an option.

[jburel]

excluding it from the demo build

[joshmoore]

@bpindelski / @mtbc: @jburel suggested merging this first in order to get the demo code safely into develop. Any objections/worries?

[mtbc]

Yes, can go ahead and merge, I think.

[bpindelski]

@joshmoore No worries from me.

[mtbc]

Does this turn out to all be FS-specific, or is there anything here worth rebasing back to dev_4_4?

[jburel]

As indicated in the description of the PR, the last commit will have to be cherry-picked
@mtbc could you take care of it? Thanks

[mtbc]

sure, will rebase the commit back to dev_4_4