These are chat archives for fiji/fiji

20th
Dec 2018
turekg
@turekg
Dec 20 2018 08:45
At some point you have to weigh the effort needed to maintain backward compatibility vs demand. In order to do that properly we need some stats but I don’t think any of the tools at this time are collecting any usage data? For a tool of such popularity I would suggest collecting stats is probably an important step forward I think we talked about this before @ctrueden
Stefan Helfrich
@stelfrich
Dec 20 2018 09:07
@turekg 3.. 2.. 1.. Discussion on controversial topic incoming!
turekg
@turekg
Dec 20 2018 09:36
Ouch :-)
Jean-Yves Tinevez
@tinevez
Dec 20 2018 10:09
We had "the talk" already on the then forum.imagej.net.
I could not find the thread again, and it went berserk.
Stefan Helfrich
@stelfrich
Dec 20 2018 10:14
@tinevez Wasn’t “the talk” on the mailing list?
Jean-Yves Tinevez
@tinevez
Dec 20 2018 10:36
I don't remember where. You are probably right.
turekg
@turekg
Dec 20 2018 10:41
I’de be interested in perousing the thread if I could be pointed to it. I can see how this topic could be “controversial” but a minimal amount of stat info (aggreed upon by the community) could be really helpful. Like the version of the app being fired up. After all this info is being sent back anyhow to figure out update status
Michael Doube
@mdoube
Dec 20 2018 10:51
That's the one
turekg
@turekg
Dec 20 2018 10:52
Ta
turekg
@turekg
Dec 20 2018 12:17
Nothing new there, all valid arguments…. And the data being collected has the needed info (and more besides) to make at least a semi-informed decision about version usage (since the data collection was implemented that is, and keeping in mind opt-outs)
Curtis Rueden
@ctrueden
Dec 20 2018 15:31
Also worth mentioning: because ImageJ does not do any of its own usage collection, some plugins have started doing their own, sometimes (AFAICT) secretly. E.g. https://github.com/HenriquesLab/NanoJ-Core/blob/bf9c03f7a1ae4ecbcab62096a9949e6869d8d497/Core/src/nanoj/core2/NanoJUsageTracker.java
Josh Moore
@joshmoore
Dec 20 2018 15:44
Flipping back to updater issues: the latest milestone of Bio-Formats (6.0.0-m4) is ready for pushing to the dev update site, but it contains new jar dependencies (https://github.com/minio/minio-java/blob/master/build.gradle#L55). Is there any changes/new strategy that should be considered before doing so?
Curtis Rueden
@ctrueden
Dec 20 2018 15:46
@joshmoore It should be fine as long as you also upload those JARs to the update site with it.
The only trouble would be if there is a JAR that is obsolete with BF6 and should not appear in the installation anymore. There is currently no mechanism for a downstream update site to mark a JAR from an upstream site as obsolete.
This is what bit us with the BF5 changes with ome-common et al., together with the fact that ImageJ/Fiji sites maintain the J6-compatible stuff while Java-8 site provides J8 versions.
Josh Moore
@joshmoore
Dec 20 2018 15:48
:+1: Don’t need to remove anything at this point. I guess there’s some change that I’d need to rollback this addition if we decide that that minio S3 library isn’t the best choice.
Curtis Rueden
@ctrueden
Dec 20 2018 15:48
Fortunately, this situation will be resolved with the V2 updater work that has now begun.
Josh Moore
@joshmoore
Dec 20 2018 15:48
Very excited!
(I’ve had an internal drumroll going since the announcement at DevDays)
Curtis Rueden
@ctrueden
Dec 20 2018 15:48
Me too; finally, the Java-8 update site will go away. Hopefully before end of 2019, though it all depends on how rapidly the development progresses.
Josh Moore
@joshmoore
Dec 20 2018 15:48
And nothing to note/try in terms of detecting potential jar conflicts?
Curtis Rueden
@ctrueden
Dec 20 2018 15:48
We came up with a nice design in Dresden.
Josh Moore
@joshmoore
Dec 20 2018 15:49
(Or would it be “safer” to put all of this in a special updater site just for this dependency?)
Curtis Rueden
@ctrueden
Dec 20 2018 15:49
Hmm... well, how is the BF6 API? Breaking backwards compatibility?
Josh Moore
@joshmoore
Dec 20 2018 15:49
It’s an implementation detail of a new Handle class returned by Location.
(i.e. not part of the API)
Curtis Rueden
@ctrueden
Dec 20 2018 15:50
If it breaks things, then there are probably a lot of ImageJ plugins, Fiji components, etc., that would all need to be updated.
If you expect things to still be binary compatible, then I think there is not much cause for concern.
But if you want to test it, we could do a "melt" of Fiji with BF6.
Josh Moore
@joshmoore
Dec 20 2018 15:51
Hmm….. is that something it’d be helpful if we did when testing potential release candidates?
(i.e. slightly late in this case, but still before we push to even the dev update site)
in which case, is fiji/fiji@d35f4f1 where I should be looking?
Josh Moore
@joshmoore
Dec 20 2018 15:57
(Been asked to go afk for a stroll through the village. Here’s to RL; back later)
Curtis Rueden
@ctrueden
Dec 20 2018 16:03
That script is a starting point. You can clone fiji/fiji, edit the POM to add <bio-formats.version>6.0.0-m3</bio-formats.version> to the <properties>, and then try bin/melt.sh. Or you could try passing the updated artifacts explicitly with -c ome:formats-api:6.0.0-m3,ome:formats-bsd:6.0.0-m3,ome:turbojpeg:6.0.0-m3,ome:formats-gpl:6.0.0-m3,ome:bio-formats_plugins:6.0.0-m3 and maybe also the -p flag so that it only lumps in components that depend on those changed artifacts. I haven't tested that feature in quite some time, though.
The -s flag is also helpful to stop after constructing the melting pot structure, without doing an actual build. Then you can look around in there, see what it did, maybe tweak things, and run build.sh when ready.
Josh Moore
@joshmoore
Dec 20 2018 17:18
(Noted. Thanks)