Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    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
    I don't know enough about that repo to make that call\
    Gabriel Selzer
    @gselzer
    @ctrueden my scijava-maven-plugin build is failing locally
    Curtis Rueden
    @ctrueden
    Failing build? Or failing tests?
    Gabriel Selzer
    @gselzer
    Failing integration test 
    [INFO] [INFO] Compiling 1 source file to /mnt/c/Code/scijava/scijava-maven-plugin/target/it/populate-app/target/classes
[INFO] [INFO] -------------------------------------------------------------
[INFO] [ERROR] COMPILATION ERROR :
[INFO] [INFO] -------------------------------------------------------------
[INFO] [ERROR] Source option 5 is no longer supported. Use 6 or later.
[INFO] [ERROR] Target option 1.5 is no longer supported. Use 1.6 or later.
[INFO] [INFO] 2 errors
[INFO] [INFO] -------------------------------------------------------------
[INFO] [INFO] ------------------------------------------------------------------------
[INFO] [INFO] BUILD FAILURE
[INFO] [INFO] ------------------------------------------------------------------------
[INFO] [INFO] Total time:  1.568 s
[INFO] [INFO] Finished at: 2021-11-16T12:17:37-06:00
[INFO] [INFO] ------------------------------------------------------------------------
[INFO] [ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.1:compile (default-compile) on project Example_PlugIn: Compilation failure: Compilation failure:
[INFO] [ERROR] Source option 5 is no longer supported. Use 6 or later.
[INFO] [ERROR] Target option 1.5 is no longer supported. Use 1.6 or later.
[INFO] [ERROR] -> [Help 1]