Fiji updater operates on what directories and what file types?

[Poczatek, Joseph Collin]

Hi all,

I haven't been able to find this in the docs, but I was wondering what
the Fiji (or is it IJ2 now?) updater can push to a 3rd party update site.

Poking around I think that only some directories will be looked at:
Fiji.app/plugins/
Fiji.app/luts/
Fiji.app/jars/
Fiji.app/macros/
Fiji.app/scripts/

And only file types:
.class/.jar
.lut
.txt
appropriate macro/script extensions (.ijm, .py, .rb, etc)

Am I correct? What I was attempting was to push a 1-2 bash script that
was just "ImageJ-linux64 --all-my-special-args..." and having no
extension or .sh didn't take.

I can think of several workarounds, the most obvious is to create
Fiji.app/scripts/mything.bsh where I guess the worst that could happen
is someone tries to run it as a beanshell script.

Is there a better way to do this? I can also think of other use cases
besides this specific one.

Thanks,
Collin



The information in this e-mail is intended only for the person to whom it is
addressed. If you believe this e-mail was sent to you in error and the e-mail
contains patient information, please contact the Partners Compliance HelpLine at
http://www.partners.org/complianceline . If the e-mail was sent to you in error
but does not contain patient information, please contact the sender and properly
dispose of the e-mail.

[Johannes Schindelin]

Hi Joseph Collin,

On Mon, 30 Dec 2013, Poczatek, Joseph Collin wrote:

> I haven't been able to find this in the docs, but I was wondering what
> the Fiji (or is it IJ2 now?) updater can push to a 3rd party update site.

It is both: the Fiji Updater now *is* the ImageJ updater.

And yes, it can upload to 3rdparty update sites, as detailed in
http://fiji.sc/Adding_Update_Sites

> Poking around I think that only some directories will be looked at:
> Fiji.app/plugins/
> Fiji.app/luts/
> Fiji.app/jars/
> Fiji.app/macros/
> Fiji.app/scripts/
>
> And only file types:
> .class/.jar
> .lut
> .txt
> appropriate macro/script extensions (.ijm, .py, .rb, etc)

Almost correct. The file extensions accepted are dependent on the
top-level directory. In plugins/ for example, .class, .jar, .ijm and
script extensions are allowed, but not .lut. In luts/, only .lut are
allowed. In lib/ (which you did not mention), there is no limitation on
file extensions.

This restrictions are not for dictatorship reasons, BTW, but to prevent
surprises from incorrect usage of the updater.

> Am I correct? What I was attempting was to push a 1-2 bash script that
> was just "ImageJ-linux64 --all-my-special-args..." and having no
> extension or .sh didn't take.

Bash scripts cannot be executed by ImageJ, hence it does not make too much
sense for the updater to ship them. Having said that, you could upload
them into, say, lib/.

> I can think of several workarounds, the most obvious is to create
> Fiji.app/scripts/mything.bsh where I guess the worst that could happen
> is someone tries to run it as a beanshell script.
>
> Is there a better way to do this? I can also think of other use cases
> besides this specific one.

It is a very dangerous thing to let random people specify the way you run
things, therefore my suggested way would be to ship the Bash scripts
separately to the users (so they know they are from a trusted source, and
so they know to to complain to when their Windows machine has no clue how
to run Bash scripts).

Ciao,
Johannes

[Poczatek, Joseph Collin]

Hi Johannes,

> Almost correct. The file extensions accepted are dependent on the
> top-level directory. In plugins/ for example, .class, .jar, .ijm and
> script extensions are allowed, but not .lut. In luts/, only .lut are
> allowed. In lib/ (which you did not mention), there is no limitation on
> file extensions.
>
> This restrictions are not for dictatorship reasons, BTW, but to prevent
> surprises from incorrect usage of the updater.

Ok, that makes sense. I didn't mention lib/ because it isn't in a fresh
Fiji install. Is it deprecated, or is it sticking around?

After that I got a little confused... Just to talk this out so I'm not
missing something.

>> Am I correct? What I was attempting was to push a 1-2 bash script that
>> was just "ImageJ-linux64 --all-my-special-args..." and having no
>> extension or .sh didn't take.
> Bash scripts cannot be executed by ImageJ, hence it does not make too much
> sense for the updater to ship them. Having said that, you could upload
> them into, say, lib/.

Couldn't you say the same thing about Fiji shipping with a .desktop
file? It's an analogous situation I think. We just want to make it easy
to launch Fiji in a certain way.

>> I can think of several workarounds, the most obvious is to create
>> Fiji.app/scripts/mything.bsh where I guess the worst that could happen
>> is someone tries to run it as a beanshell script.
>>
>> Is there a better way to do this? I can also think of other use cases
>> besides this specific one.
> It is a very dangerous thing to let random people specify the way you run
> things, therefore my suggested way would be to ship the Bash scripts
> separately to the users (so they know they are from a trusted source, and
> so they know to to complain to when their Windows machine has no clue how
> to run Bash scripts).

Maybe I should say that nothing I'm talking about is forced on the
user. They could still run our plugin from the plugins menu like
normal. Putting a .sh file in lib/ sounds like the best option and we
don't have to use an incorrect extension. Thanks for pointing that out.

Happy New Year,

[Johannes Schindelin]

Hi Joseph Collin,

On Tue, 31 Dec 2013, Poczatek, Joseph Collin wrote:

> > Almost correct. The file extensions accepted are dependent on the
> > top-level directory. In plugins/ for example, .class, .jar, .ijm and
> > script extensions are allowed, but not .lut. In luts/, only .lut are
> > allowed. In lib/ (which you did not mention), there is no limitation
> > on file extensions.
> >
> > This restrictions are not for dictatorship reasons, BTW, but to
> > prevent surprises from incorrect usage of the updater.
>
> Ok, that makes sense. I didn't mention lib/ because it isn't in a fresh
> Fiji install. Is it deprecated, or is it sticking around?

It is not used by default because we do not ship any platform-dependent
libraries by default. But it is added to the java.library.path (to be
precise, a platform-dependent subdirectory is added) so that it is
possible to ship platform-dependent libraries from update sites.

> >> Am I correct? What I was attempting was to push a 1-2 bash script
> >> that was just "ImageJ-linux64 --all-my-special-args..." and having no
> >> extension or .sh didn't take.
> >
> > Bash scripts cannot be executed by ImageJ, hence it does not make too
> > much sense for the updater to ship them. Having said that, you could
> > upload them into, say, lib/.
>
> Couldn't you say the same thing about Fiji shipping with a .desktop
> file?

It does not ship with a .desktop file. It generates it upon startup in
Linux. (To be precise, the ImageJ launcher does.)

> It's an analogous situation I think. We just want to make it easy to
> launch Fiji in a certain way.

You are welcome to do that, bash scripts are not the way, however. A
better way would be to patch the ImageJ launcher to make it possible to
ship *limited* configuration via update sites that affects the way Fiji is
started.

So far, I am quite doubtful, however, that such a support is needed. I
might be wrong, but then, I have not been graced with the information
about the intended use case requiring those bash scripts.

Ciao,
Johannes

[Poczatek, Joseph Collin]

Hi Johannes,

Thanks for indulging me in this conversation.

Couldn't you say the same thing about Fiji shipping with a .desktop
file?

It does not ship with a .desktop file. It generates it upon startup in
Linux. (To be precise, the ImageJ launcher does.)

That makes more sense, and I should have realized that looking at the executable path in the .desktop file. Maybe I should think about having the scripts generated...

You are welcome to do that, bash scripts are not the way, however. A
better way would be to patch the ImageJ launcher to make it possible to
ship *limited* configuration via update sites that affects the way Fiji is
started.

I can see that making sense in that it's cross platform (since the launcher is cross platform), but I can't see how that would get you any granularity. Meaning I want to start fiji in say 2 ways that would be equivalent to:
ImageJ-launcher -flagA
ImageJ-launcher -flagB
And not overshadow starting with no flags.

So far, I am quite doubtful, however, that such a support is needed. I
might be wrong, but then, I have not been graced with the information
about the intended use case requiring those bash scripts.

Ok, I was trying to keep my questions narrowly focused, but I guess I ended up too vague. This is related to a conversation on the list from this spring (*) about nrrd files and handleExtraFileTypes. I agree that what I'm doing isn't the cleanest/best but I think it's the lesser evil given all the following facts/constraints (and the ones I forgot):

- I need to bypass the standard IJ-io/extraFileTypes/LOCI chain and pass a file arg directly to our plugin. Which is called OpenMIMS (**) btw.

- Architecturally our plugin has gotten a little cluttered over the years and while we're trying to refactor things, I don't have the man power to refactor out our file readers right now.

- Besides myself I would say that all our users use Fiji without starting OpenMIMS <1% of the time. So they don't really want to start Fiji per se.

- I seem to be categorically incapable of keeping even all the Fiji installs in the lab up-to-date/symmetric, let alone those outside the lab, so why not take advantage of the updater?

- Like I mentioned above there are 2 ways (sets of flags) we start our plugin with. So we would need 2 "executables".

- Our "users demand" a high level of symmetry between at least Linux and OsX in terms of how OpenMIMS/Fiji runs. For example breaking the "one instance of an application" constraint on OsX. And if I have to do crazy things like that, best to have a parallel way of starting Fiji, right? (I know I need more than just a bash script.)

- I'm not stepping on/overshadowing any part of Fiji. Or forcing any of this to be used.

- Even if I make a mess of things or get to the point I can undo this kludge, the updater makes it a lot easier to back out.

So in conclusion, yes I agree that it's not the best but it's probably manageable.

Cheers,
Collin

(*) http://imagej.1557.x6.nabble.com/Fiji-the-nrrd-file-format-and-HandleExtraFileTypes-td5002602.html

(**)
http://nrims.harvard.edu/about-mims
http://nrims.partners.org/wiki/index.php/OpenMIMS_Manual

[Unruh, Jay]

I would add to this conversation that it would be very useful for other developers to see what Collin has developed in terms of the Fiji launcher script.  I have had situations where I wanted to launch in a custom way not provided by the built-in launcher.  No reason to figure this out if Collin already has.  Collin could label it “experimental” to prevent naïve users from accidentally using it.  Most of my plugins fall into the “experimental” category anyway—if they didn’t I probably wouldn’t rely so much on ImageJ.

 

Jay