A plugin framework and application container with built-in extensibility mechanism.
Stiff ongoing ?
still
In the meantime feel free to cut it out of Mastodon for yourself.
@NicoKiaru @tinevez About the progress bars: my vision was to have a
TaskService that lets you register Task objects and a task can have subtasks recursively, and then we can have a GUI that shows a progress bar for a task with an expandable triangle widget to show the next layer of progress bars below it. And to replace ImageJ's current progress bar with this better one. But as with so much in SciJava, this work was never completed.
(But it is likely not practical for a little while :sweat_smile:)
@tinevez It was started—there is a
TaskService in SciJava Common now with Task objects that you can create—and the DownloadService uses it. I'd be happy to chat about requirements and whatnot any time, if you or @NicoKiaru or anyone has time and interest to develop it further. Perhaps all that would be needed is the user-interface portion of it now.
I wrote some code for ImageJ-TensorFlow that hooks up the
DownloadService tasks to the StatusService.
This is totally the wrong place for logic like this... but until SciJava Common and SciJava UI Swing have better support for the
TaskService directly, this is where we are.
21 replies
TIL: attempting to outsmart limitations of the GitHub issue transfer mechanism is not a good idea! I had five issues in imagej/imagej-ui-swing with label
component:script-editor, from back when the Script Editor lived in imagej-ui-swing. Since then, it moved to its own repository at scijava/script-editor, since it is more general than images. I wanted to transfer those five issues from imagej-ui-swing to script-editor, but you can only transfer an issue between repos of the same org. So! I created a new repo imagej/scijava-issue-shuttle and moved the five issues there. Then transferred scijava-issue-shuttle from imagej to scijava. But now, I'm not able to transfer the issues again from scijava-issue-shuttle to script-editor; no repositories appear on the list. Furthermore, two of the issues seem to have partially incomplete transfers, such that they still say they are "transferring" at the bottom. I fear they may be hosed now. So the end result is five deleted issues, i.e. five broken links, without successfully landing them at their new destinations in the end.
I solved it! I tried using
gh issue transfer command line function, and it gave me an informative error: "Old issue cannot be transferred from private repository to public repository". Once I changed scijava-issue-shuttle to public, I was able to move them to the script-editor repo. Next time I'll try that command directly across orgs, and see if it works.
Above you can see a small demo of multiple progress bars for async tasks. It seems to work quite well. I will probably do an experimental demo update site and a forum post for those who want to test it. I've included it in by default in the batch processor, but with little effort, such a task specific progress bar can be added to any script or command.
Sorry for the recent maven.scijava.org downtime. The increased memory fix I had implemented was lost when I upgraded to the latest version the other day. I have now fixed the upgrade script to set the memory needs correctly, so future upgrades should not suffer from this issue.
Hello everybody, I've made a PR in scijava-common: scijava/scijava-common#432. It is needed to add progress bars like the ones demoed in this post: https://forum.image.sc/t/demo-and-proposal-new-progress-bars-for-fiji/64956. Other PRs are needed outside scijava-common, but this is the main one. It shouldn't break anything since only new methods with default empty implementations are added.
@axtimwalde the plan is to usher all scijava content through to Java 11 with https://github.com/scijava/incubator. Once ready for release, that content will be migrated to https://github.com/scijava/scijava. SciJava Common et. al will not be migrated to Java 11; instead, the migrated components will form SciJava 3
I know that @ctrueden has written more about this. The incubator README contains a lot of his thoughts
But there is no timeline and it contains goals that I do not fully support because they lead to eternal stasis: e.g https://github.com/scijava/incubator/blob/main/README.md#backwards-compatibility is unrealistic in a changing world, I agree that one should minimize this but it is necessary to break things if the old stuff is in the way and makes everything bad
I also don't see who is actually working on this to make it happen, from the fiji meetings I read that you guys are all about doing pyimagej and writing papers at this time. Our own Fiji independent projects are currently using pom-scijava but we have bumped the release version so we can use modern stuff on the side of 8-compatible libraries (which works fine).
This is impossible for ImgLib2 or BigDataViewer though because they are locked in as dependencies of others in pom-scijava, so here we depend on the community. I'd be more than happy to discuss this either in the Fiji dev call on Monday or in a separate meeting. We are happy to help where there are obvious resource gaps.
But there is no timeline and it contains goals that I do not fully support because they lead to eternal stasis: e.g https://github.com/scijava/incubator/blob/main/README.md#backwards-compatibility is unrealistic in a changing world, I agree that one should minimize this but it is necessary to break things if the old stuff is in the way and makes everything bad
Yeah, the timeline is unfortunately vague as I am transitioning to other projects in our community (e.g. napari-imagej), and @ctrueden has been stretched thin. The driving project behind SciJava 3, SciJava Ops and ImageJ Ops2, is nearly ready, but it of course depends on a bunch of components in SciJava 3.
I am fairly certain that the point @ctrueden was making about backwards compatibility was that if you needed to do it, make a new project version. For example, one component in the incubator is SciJava Log2, which is a new version of the
log package in SciJava Common. It breaks backwards compatibility, naturally. Once SciJava Log2 has been released, any desired breaking changes would warrant SciJava Log3.
(@ctrueden please step in if I'm wrong here)
I also don't see who is actually working on this to make it happen, from the fiji meetings I read that you guys are all about doing pyimagej and writing papers at this time. Our own Fiji independent projects are currently using pom-scijava but we have bumped the release version so we can use modern stuff on the side of 8-compatible libraries (which works fine).
I was/am the driving force behind this, but now I'm only spending about one day a week on it. Furthermore, the incubator projects are in serious need of code review.
Thanks @gselzer for the explanations, and linking the incubator writeup. I just want to clarify that there are multiple phases here:
- There's making Fiji ship with Java 11, and fixing the Updater to support 6 vs 8 vs 11 as separate JAR sources. Like we did for 6 vs 8, but better separated between ImageJ2 and Fiji. So that people can start deploying Java-11-based libraries to Fiji, or even upgrade core libraries like ImgLib2 and then the Java 8 version of Fiji will be frozen at the last Java-8-compatible versions.
- And there's updating the entire SciJava library foundation to Java 11, which is what's in the incubator right now, and is far from ready still.
@axtimwalde I have a pretty clear vision for how to achieve the former, but it's a matter of personnel. We should definitely discuss on today's call!
Hello ImageJ admins. I am a bit late to the Travis -> GitHub Actions party and I see that I should ask here for help to "add the authentication secrets for deployment to your organization". This is for https://github.com/bonej-org