A plugin framework and application container with built-in extensibility mechanism.
In scijava/pom-scijava#181 above, some of the projects in a list have an exclusion: https://github.com/fiji/register_virtual_stack_slices/blob/c6dc334fde7f764f029c3965ec165c204eba4d83/pom.xml#L156-L160
I'm assuming nothing has to be done there with regard to jhdf5 19.04?
I'm assuming nothing has to be done there with regard to jhdf5 19.04?
Good morning @ctrueden , I sent some PRs related to scijava/pom-scijava#181 . Let me know if you would to discuss these at some point.
same question here: https://github.com/scijava/pom-scijava/issues/181#issuecomment-1030203786
2 replies
@ctrueden , what else needs to be done for scijava/pom-scijava#181 ? I have pull requests for most of the initial list and have a general idea how to fix other cases.
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).