Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Gabriel Selzer
    @gselzer
    In conjunction with the other Discoverer implementations
    Giuseppe Barbieri
    @elect86
    so my idea was: avoid that in toto and catch two birds with one stone (actually three :D):
    • lighter repo, less code
    • no maintenance
    • all corner cases covered
    Gabriel Selzer
    @gselzer
    The idea is that we might have multiple ways (e.g. ServiceLoader, Therapi, manually registered, potentially Spring) of declaring Ops, OpCollections, etc and we want to support all of them. That is the point of Discoverer
    To provide an abstraction for all of these methods to report their discoveries in a uniform manner
    This allows users to plug in any Discoverers they are interested in using, and I see (naively, I haven't looked too hard at Classgraph) Classgraph being a good fit among the other Discoverers
    Giuseppe Barbieri
    @elect86
    can you give me a short tour about the relevant code for that?
    maybe with a call when you have a moment?
    Gabriel Selzer
    @gselzer

    can you give me a short tour about the relevant code for that?

    See Discoverer for the interface and PluginBasedDiscoverer for an implementation

    I don't have time for a call anytime soon, feel free to discuss here
    Giuseppe Barbieri
    @elect86
    ok
    Curtis Rueden
    @ctrueden

    all corner cases covered

    I don't think we can go to classgraph only because it's a dependency, and one of our requirements is to have a dependency-free way to discover ops, for those who do not wish to add any dependencies but still expose their algorithms as ops.

    So that's why we have the therapi-based thing. It's the "least bad" way we could come up with to do this.
    Giuseppe Barbieri
    @elect86
    not wishing to add any dependency looks quite naive
    Curtis Rueden
    @ctrueden
    Assuming other developers are naive for their design decisions looks quite naive. :stuck_out_tongue_winking_eye:
    In seriousness: I am a huge fan of dependency management systems, making things small and modular, etc., but I have to admit that there is a lot of power in dependency-free libraries, still. They are vastly simpler, because they avoid the necessary deployment complexity imposed by any dependency management system.
    Giuseppe Barbieri
    @elect86
    yeah, but that means additional (necessary?) burden
    Curtis Rueden
    @ctrueden
    So I do think there is value in having a way to declare ops dependency-free.
    Giuseppe Barbieri
    @elect86
    also, what is the deployment complexity you are referring to?
    Curtis Rueden
    @ctrueden
    Having multiple JAR files?
    Or building uber-JARs?
    Whatever, it's more complicated than having one JAR that is the thing.
    There is a reason ij.jar is still a single JAR after all these years. It brings a lot of downsides, but also advantages.
    Giuseppe Barbieri
    @elect86
    JARs should be handled automatically by the management system, uber-JARs are nice but conceptually wrong
    Curtis Rueden
    @ctrueden
    My point is: if you have no dependencies, you don't need a management system at all. Which is simpler.
    Giuseppe Barbieri
    @elect86
    simpler for dependency management side, worst for the code side
    but I dont want to argue further :p
    Curtis Rueden
    @ctrueden
    Yeah, me either.
    Giuseppe Barbieri
    @elect86
    I'll try the update script stuff
    Curtis Rueden
    @ctrueden
    @/all I have published a draft of the SciJava Incubator README. It is incomplete, but still maybe useful to start grokking what the point of the scijava/incubator is. It describes motivations, requirements, and so forth, for the next Java-11-based set of SciJava libraries currently in the works.
    Gabriel Selzer
    @gselzer
    @ctrueden you saw scijava/incubator#40, yeah?
    17 replies
    Giuseppe Barbieri
    @elect86
    if I may,regarding the dev process: you don't need any real "beast", with gradle would be enough to simply have just a bare repo having only build configuration files, then on the side all the major projects (scijava/scifio/imagej/fiji). All these projects have to be of course checked out to the right experimental branch and then the "beast" would simply include their build (composite build in gradle terms).
    1 reply
    Giuseppe Barbieri
    @elect86
    Also, jitpack is awesome, but for simple projects, as soon as you have complicate and advanced projects then you start hitting its limitations (I created a curated list here). Moreover, jitpack builds on the first request. Our (sciview/scenery) build process is the following, you push and then you pull from the other project. At that time jitpack starts building (there is a way to build ahead, but then you cannot rely on the commit id, but you have to use -SNAPSHOT, which of course doesn't always guarantees it fetches what you are thinking). However, gradle request goes in overtime and then the synchronization gets interrupted as unresolved and you have to trigger it again.
    Moreover, this is a pure waste if you think about it, because the artifact is already built (also much faster) locally on your machine.
    The ideal process would be to simply publish the very artifact you just build as a snapshot with a super simple versioning, ie: ${lastTag}+$numberOfCommits and then you can immediately consume somewhere else
    1 reply
    Giuseppe Barbieri
    @elect86
    Also2, the beast should be used to resolve any conflict and sort out the "melting pot", releasing then the POM(/platform)
    Also3, Java 17 is out, take the chance and use that last LTS as base developing jdk, providing a -jdk8 variant (Maven should have something similar but I dont know the term for that) for retro-compatibility
    14 replies
    Gabriel Selzer
    @gselzer
    @ctrueden writing a SciJava Ops Engine integration test now, what is the preferred package structure for those?
    I currently have src/it/discovery-test, should I put the tests in there?
    Gabriel Selzer
    @gselzer
    Well, I'll write them now in src/test/java, we can move them later
    17 replies
    Gabriel Selzer
    @gselzer

    So I currently have regression tests for:

    • Determining the number of Ops/OpInfos discoverable using ServiceLoader
    • Determining the number of OpCollections/OpInfos discoverable using ServiceLoader
    • Determining the number of Ops/OpInfos discoverable using Therapi (this number is currently zero)

    Do we want a matching regression test? If so, what Ops should be tested? There are some math Ops which make sense to test, but what about adapt Ops? simplify Ops?

    10 replies
    Time to switch ImageJ Ops2 over to Therapi!
    Gabriel Selzer
    @gselzer
    @ctrueden I think you'll be proud of this :smiley: scijava/incubator@c23f4ab
    8 replies
    Will finish tomorrow
    Giuseppe Barbieri
    @elect86
    @gselzer I can provide you an easy kotlin script for that, what do you want to achieve exactly? All the reference for each file under imagej/imagej-ops2/ switching double quote with single quote, and what about priority?
    Giuseppe Barbieri
    @elect86
    Screenshot from 2021-11-12 07-15-11.png
    Gabriel Selzer
    @gselzer

    Will finish tomorrow

    Nearly finished, a couple tests broke when I migrated OpFields to therapi generation. I'll have to finish next week

    See scijava/incubator@94523aa for progress
    Curtis Rueden
    @ctrueden
    @gselzer scijava/scijava-maven-plugin@8f5fa90 Yaaay \^.^/
    1 reply
    Giuseppe Barbieri
    @elect86
    https://discuss.kotlinlang.org/t/idea-python-backend/19852/13?u=krzema12
    Giuseppe Barbieri
    @elect86
    what about merging all the scijava-core and fiji-core plugins in one project each?
    Since they are quite simple and small, I think this might make sense, or?
    13 replies
    Gabriel Selzer
    @gselzer
    @ctrueden the incubator works just fine with SciJava Maven Plugin
    Going to do the rebasing now