<html>
<head>
<base href="http://fiji.sc/bugzilla/" />
</head>
<body>
<p>
<div>
<b><a class="bz_bug_link
bz_status_NEEDSINFO "
title="NEEDSINFO - Cannot run commands from the ijpb/MorphoLibJ plugin in --headless mode using --jython script option"
href="http://fiji.sc/bugzilla/show_bug.cgi?id=1107#c10">Comment # 10</a>
on <a class="bz_bug_link
bz_status_NEEDSINFO "
title="NEEDSINFO - Cannot run commands from the ijpb/MorphoLibJ plugin in --headless mode using --jython script option"
href="http://fiji.sc/bugzilla/show_bug.cgi?id=1107">bug 1107</a>
from <span class="vcard"><a class="email" href="mailto:ghv2@psu.edu" title="Greg Von Kuster <ghv2@psu.edu>"> <span class="fn">Greg Von Kuster</span></a>
</span></b>
<pre>Hi Curtis,
(In reply to Curtis Rueden from <a href="show_bug.cgi?id=1107#c8">comment #8</a>)
<span class="quote">> Thanks Greg. To be clear, the continuous release of Fiji is not a
> "development build" -- each update is a reproducible version (i.e., all
> release versions of JAR files) built from Fiji's master branch.</span >
Thanks for the clarification on this, but when building tools for Galaxy, we
build them in such a way that all dependencies come with the tool when it is
installed from the Galaxy tool shed (<a href="https://toolshed.g2.bx.psu.edu">https://toolshed.g2.bx.psu.edu</a>) into a
Galaxy instance. The Galaxy wrappers for the Imagej2 tools I'm building define
a dependency on the Fiji package using an installation recipe within an xml
file. This xml file has a tag set that looks l-soemthing like this:
<a href="http://fiji.sc/downloads/Life-Line/fiji-linux64-20141125.tar.gz">http://fiji.sc/downloads/Life-Line/fiji-linux64-20141125.tar.gz</a>
This URL always guarantees that specific build of Fiji, so if the Galaxy
administrator uninstalls a tool and its required Fiji package from their Galaxy
instance, they are guaranteed to get the exact same version of the required
Fiji package when they re-install the tool.
Using the latest stable build URL will not guarantee this behavior.
<span class="quote">>
> The ImageJ2 development build is _not_ reproducible, but I think the
> Downloads page is pretty clear about that.
>
> The main problem with the Fiji continuous releases is that they are not
> currently archived anywhere and you can't downgrade. So to actually roll
> back you'd need to know which commit hash you were on and rebuild Fiji using
> Maven. Someday we hope to have a rollback feature, but it's probably not
> going to happen this year.
>
> As for when we do another Life-Line version: we try to do one just before
> making disruptive changes. The next disruptive change will certainly be the
> switch over to Java 8 with a new deployment scheme that retires the ImageJ
> Launcher. We hope to roll that out before September.</span >
This is really good to know - it helps clarify some of my upcoming development
plans.
I have tried using the latest stable release of Fiji for these plugins that
I've found that do not produce output images that I expect, and it has made no
difference.
I've also looked into using xvfb to see if it will work for what I'm doing, but
I've discovered it really won't. So I guess I just won't be able to wrap some
of the plugins into Galaxy tools. This is unfortunate, but understandable.
There are still very many useful ImageJ tools that I can wrap.
I have not yet figured out an easy way to determine if a plugin command will
run successfully from the command line without getting pretty far down the
"finished wrapper" path so that it can be tested. If you have any ideas about
this, I would greatly appreciate them.
I appreciate all of your help on this ticket - you can close it when
convenient. Please let me know if there is something else I should do
regarding its status.
Thanks again!
Greg Von Kuster</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the assignee for the bug.</li>
</ul>
</body>
</html>