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
    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]
    Curtis Rueden
    @ctrueden
    Blech.
    You are building with a too-new version of Java. Use Java 8.
    Gabriel Selzer
    @gselzer
    Hmm, Java 8 supports Java 5 source/target?
    Curtis Rueden
    @ctrueden
    • 8: 1.2
    • 11: 6
    • 17: 7
    (Version: minimum source/target version)
    Gabriel Selzer
    @gselzer
    Aha
    Should we make an issue to update?
    Or maybe SciJava Maven Plugin2 can enter the incubator :sweat_smile:
    Curtis Rueden
    @ctrueden
    I don't understand....
    Gabriel Selzer
    @gselzer
    Do we not want to migrate all SciJava code to Java 11?
    Curtis Rueden
    @ctrueden
    Nope!
    Gabriel Selzer
    @gselzer
    What is your reasoning?
    Curtis Rueden
    @ctrueden
    scijava-maven-plugin is part of the current generation of libraries we support, and is built on java 8.
    It is weird that you get that error about 1.5.
    I don't see anywhere in the scijava-maven-plugin code where source or target of 1.5 is being passed!
    Gabriel Selzer
    @gselzer

    It is weird that you get that error about 1.5.

    Yeah, I couldn't find that either

    Curtis Rueden
    @ctrueden
    Ah, it's probably just because some IT doesn't extend pom-scijava.