unsignedshould be brought in at your newly released version?
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?
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
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?
SourceAndConverterinput, but once I've selected the parameter to Batch, what is displayed is the
Fileswing widget instead of the
SourceAndConverterwhich I would like (which gives very different objects...). Is there a way to do it ? And why is the
Filewidget appearing ?
FileBatchServiceis accepting the
batchService.runcall 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
batch-processoris set up currently.