scijava/scijava-common

A plugin framework and application container with built-in extensibility mechanism.

Curtis Rueden

@ctrueden

This sounds like exactly how we do it now: if unsigned and glm were part of pom-scijava, you'd simply bump unsigned in pom-scijava, and you are done. The master branch of pom-scijava now declare the new unsigned with the existing glm, and anyone extending this new pom-scijava would receive those versions (even though glm itself declares an older unsigned version, the BOM overrides it with the newer one, as desired).

Giuseppe Barbieri

@elect86

if unsigned gets a new feature or a bug fix, I don't need to publish a new pom

Curtis Rueden

@ctrueden

and published also the platform listing the new unsigned version

Yes, that's cutting a new pom-scijava release, indeed.

and then impmort this finally into the last glm and so on

You don't have to do that part, though. Anything extending the new pom-scijava will get the new unsigned and the existing glm. Right?

How does downstream software know it's safe to use the new unsigned, then?

Giuseppe Barbieri

@elect86

tests

Curtis Rueden

@ctrueden

No, sorry, I don't mean "how do we test that it's safe"

I mean: how does the tooling of a downstream project know that unsigned should be brought in at your newly released version?

When they are using a BOM that says otherwise?

Just because you manually say so in this lock file, right?

Giuseppe Barbieri

@elect86

if there are no breaking changes, it's safe to silently update it, otherwise a new release is safer

Curtis Rueden

@ctrueden

That's no different than using a version pin in the pom.xml of a downstream project, if so.

What I'm wondering is: are you saying there is some common place to put "version pins" of this nature, for e.g. a new unsigned, that does not require publishing a new BOM, but does allow downstream code to in general infer that they can update unsigned? If not, then it's just a manual override per project, fine. Or if this mechanism is general/extensible in that way, then it sounds like just another BOM layered on top of the BOM?

Giuseppe Barbieri

@elect86

you can interpret it as bom hierarchy

Oh, I guess you are talking about polling the pom-scijava repository for changes, and wanting to instead commit something (what?) along side? But why do you need this?

I mean merging the current scijava-catalog/platform inside the bom project. So, whenever you add a new commit to the bom, github action may trigger automatically the code generation for gradle as well, propagating the new change immediately. I know this would add quite some files, polluting the repo, so we could think of having everthing inside a dedicated sub-directory, if this may be acceptable for you.. Don't hesitate to say no if you don't feel it

Curtis Rueden

@ctrueden

What I'd rather do is add an action to ping a downstream repository. So that your repo can build in response to pom-scijava pushes.

Giuseppe Barbieri

@elect86

also, I need to look into that though. Never done before

but I know there are some manual webhooks

Curtis Rueden

@ctrueden

One easy way is for the pom-scijava build to just push something to your repo. Whatever makes sense.

Giuseppe Barbieri

@elect86

I think the right way is using a webhook event, I'd try this first

Curtis Rueden

@ctrueden

Here is one way, with repository_dispatch: https://blog.marcnuri.com/triggering-github-actions-across-different-repositories

Giuseppe Barbieri

@elect86

cool, thanks

Curtis Rueden

@ctrueden

And I guess this action might be useful in combination with it: https://github.com/peter-evans/repository-dispatch

I think the peter-evans action makes this a lot simpler.

Giuseppe Barbieri

@elect86

yep, I think so too

Giuseppe Barbieri

@elect86

I see you already pushed the new naming convention, nice

Giuseppe Barbieri

@elect86

is there a reason why this

                <artifactId>3D_Blob_Segmentation</artifactId>
                <version>${sc.fiji.Fiji_3D_Blob_Segmentation.version}</version>

isn't sc.fiji.3D_Blob_Segmentation? Because of the leading digit?

Giuseppe Barbieri

@elect86

also, why this is padded with ImageJ_ instead Fiji_?

                <groupId>sc.fiji</groupId>
                <artifactId>3D_Objects_Counter</artifactId>
                <version>${sc.fiji.ImageJ_3D_Objects_Counter.version}</version>

Curtis Rueden

@ctrueden

@elect86 Thanks for catching those mistakes! I guess the thinking was that having properties starting with numbers is not OK. But I just tested it, and Maven seems to allow it just fine. So I think those prefixes were always(?) unnecessary. And should certainly be removed at this point.

Giuseppe Barbieri

@elect86

np
Ps: I was trying to move scijava-catalog and platform from a custom github repo to the gradle portal, but they rejected their id (scijava-) because it doesnt match the organization (scenery). May I move those repo under the scijava organization to try and see if then they'll get accepted?

Curtis Rueden

@ctrueden

Feel free to transfer them to the scijava org if it helps you. I can approve the transfers, and make sure you have admin access to them.

Giuseppe Barbieri

@elect86

thanks

@skalarproduktraum, I don't have anymore root priviledge on them since they have been moved to scenery, could you help me?

Curtis Rueden

@ctrueden

@elect86 scijava/pom-scijava@d0bf752

Giuseppe Barbieri

@elect86

super fast, nice

Ulrik Günther

@skalarproduktraum

@elect86 what do you need transferred to the scijava org?

Giuseppe Barbieri

@elect86

let's start with scijava-platform

Nicolas Chiaruttini

@NicoKiaru

@imagejan is there a way to make a certain scijava parameter from a certain class batchable ? I would like to have every command with a SourceAndConverterinput parameter executable in batch mode. I already have a widget for SourceAndConverter[].

Jan Eglinger

@imagejan

@NicoKiaru yes, of course! :smile: You need to implement BatchInputProvider; see FileBatchInputProvider and DatasetBatchInputProvider for examples.

It would be amaazing if this gets used as intended, and maybe the batch processor can be improved over its current prototype state.

Nicolas Chiaruttini

@NicoKiaru

@imagejan Thanks for the info! I tried, and now I can click the batch button when a SourceAndConverterinput, but once I've selected the parameter to Batch, what is displayed is the File[] swing widget instead of the SourceAndConverter[] which I would like (which gives very different objects...). Is there a way to do it ? And why is the File[] widget appearing ?

Jan Eglinger

@imagejan

@NicoKiaru I guess FileBatchService is accepting the batchService.run call because it gets your handler. I’m not sure how to solve it, need to dig a bit, but it might be a design flaw that we have no way of knowing the input type when we just extend AbstractHandlerService<BatchInput, BatchInputProvider<?>> without being able to specify File or SourceAndConverter...

@ctrueden might be able to advise a good way to improve this, but I’m afraid it would also take him some time to remember how batch-processor is set up currently.

Curtis Rueden

@ctrueden

I'm looking...

Curtis Rueden

@ctrueden

Sorry, ran out of time for today. @NicoKiaru an MCVE would be helpful to dig more quickly.

Nicolas Chiaruttini

@NicoKiaru

No pb. Thanks for looking, I'll make a minimal example next week

Mark Kittisopikul

@mkitti

I'm catching up up on the jhdf5 19.04 saga from February 2021. Looks like there was a massive API change with this commit in updating the library to HDF5 1.10
https://sissource.ethz.ch/sispub/jhdf5/-/commit/20212c5f7ff8b492761d51e6e9e7939809ff24c6

Mark Kittisopikul

@mkitti

Most of the methods that were in individual classes (H5D.java) were migrated to a single H5.java
https://sissource.ethz.ch/sispub/jhdf5/-/blob/19.04.0/source/java/hdf/hdf5lib/H5.java
This seems to correspond to incorporation of the hdf.hdf5lib into the main HDF5 repository:
https://github.com/HDFGroup/hdf5/blob/develop/java/src/hdf/hdf5lib/H5.java

46 replies

Curtis Rueden

@ctrueden

Interesting blog post on using .java sources with shebang as executable scripts: https://shekhargulati.com/2020/10/26/writing-scripts-in-java-11-and-beyond/

8 replies

Gabriel Selzer

@gselzer

@ctrueden I think as far as scijava packages rules go, it does probably make sense to move them into scijava-maven-plugin

7 replies

Unless you see someone wanting to use the rules without the rest of the stuff in that repo

2 replies

Where communities thrive

People

Repo info

Activity