Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • May 15 14:43

    Domino2357 on protein_rollercoaster

    Created Rollercoaster class and… (compare)

  • May 15 10:19
    Domino2357 synchronize #414
  • May 15 10:19

    Domino2357 on spaceFillingDia

    StickAndBallProteinModel: renam… (compare)

  • May 15 09:58

    kephale on master

    SciView.kt: add default argumen… Merge pull request #382 from sc… (compare)

  • May 15 09:58
    kephale closed #382
  • May 15 09:58
    kephale opened #382
  • May 15 09:55
    kephale opened #421
  • May 15 09:16
    Domino2357 edited #414
  • May 15 08:54

    kephale on screenshot-default-overwrite

    SciView.kt: add default argumen… (compare)

  • May 15 08:46

    kephale on master

    - Gradle 7.0 - Gradle Catalog c… Merge branch 'master' into grad… bumping scenery and 11 more (compare)

  • May 15 08:46
    kephale closed #379
  • May 15 08:31

    kephale on gradle-catalog-screenshot

    SciView.kt: add default argumen… (compare)

  • May 11 17:07
    Domino2357 commented #418
  • May 11 17:06
    Domino2357 commented #418
  • May 11 16:33
    Domino2357 synchronize #418
  • May 11 16:33

    Domino2357 on boundingBoxBugBrotein

    RibbonDiagramTests: fixed range… (compare)

  • May 11 16:16
    Domino2357 synchronize #418
  • May 11 16:16

    Domino2357 on boundingBoxBugBrotein

    RibbonDiagramTests: extended te… ProteinTests: added test for op… (compare)

  • May 11 13:54
    skalarproduktraum opened #420
  • May 11 13:53

    skalarproduktraum on update-to-spirvcrossj-0.8.0

    Build: Bump spirvcrossj to 0.8.… (compare)

Giuseppe Barbieri
@elect86
it's out of our hands
or set strictly version by version till
  • the class is there
  • the conflict passes the constraints
I pushed, you can use my modifications to play with
run dependencies and search for imglib2. If you get +--- net.imglib2:imglib2:5.8.0 FAILED then it's still bad news.
Append --scan when you run the task in order to upload the metadata and get a better inspection of what's going on
Giuseppe Barbieri
@elect86
another option would be to get a fat jar with the imglib2 specified and all its deps inside
Kyle I S Harrington
@kephale
@elect86 in maven you can exclude transitive dependencies of a specific package, is there a gradle way to do that?
Giuseppe Barbieri
@elect86
yes, but I dont think that is gonna resolve anything
the problem is what is getting pulled in and used at the end of the versions resolution
Curtis Rueden
@ctrueden

it's out of our hands

If deps are being inferred from a pom-scijava bill of materials (as opposed to cherry-picked manually), then it is a bug—something we need to fix.

Giuseppe Barbieri
@elect86
base is pom-scijava 29.3
Curtis Rueden
@ctrueden
So all versions are inherited from that?
There is no 29.3...
29.2.1, then 30.0.0.
Giuseppe Barbieri
@elect86
by default, but there are some custom dependencies.
it was from the top of my mind, I recall a 29 and a 3
Curtis Rueden
@ctrueden
Which repository should I check?
I'd like to reproduce @moreApi's issue.
it's 29.2.1 indeed
Giuseppe Barbieri
@elect86
I can assist you @ctrueden if you want
Curtis Rueden
@ctrueden
@elect86 So... the problem only occurs when overriding imglib2 to 5.6.3? By default it comes in at a later version, and the problem does not occur?
Or do I misunderstand?
Downgrading versions is likely to result in exactly these sorts of problems, and should not be done without good reason.
Giuseppe Barbieri
@elect86

looking at imglib2-ui, after the conflict resolution, gradle selects higher versions of several of its dependencies based on the dependency graph. This includes

|    +--- net.imglib2:imglib2-ui:2.0.1
|    |    +--- net.imglib2:imglib2:5.6.3 -> 5.11.1
|    |    \--- net.imglib2:imglib2-realtransform:2.2.1 -> 3.1.0 (*)

|    +--- net.imglib2:imglib2-ui:2.0.1 (*)
|    \--- org.scijava:ui-behaviour:2.0.1 -> 2.0.3 (*)

If I start from imglib2 forcing to pick 5.6.3 then if fails because there is no solution based on the constrains of the other dependencies (link above, dependency tree)

Curtis Rueden
@ctrueden
@elect86 Thanks for the explanation. Ideally, gradle should not be selecting/overriding/upgrading any version of any dependencies. All should be specified in / inherited from the pom-scijava BOM. I will play around with gradle's dep resolution, and compare with Maven, to see what's happening, so I understand it better. If Gradle and Maven differ in behavior on which versions are selected for given release artifacts, that is a huge problem, which we'll need to solve somehow. One idea I have had for a long time, but not implemented yet, is deploying a dedicated thing analogous to JavaScript's package-lock.json which explicitly enumerates the build versions of all dependencies at build+release time for every release, so there is no more ambiguity or relying on tooling to reason about this.
(We sort of have it already with the Class-Path in META-INF/MANIFEST.MF, but it's not in an ideal form.)
Giuseppe Barbieri
@elect86
maven has the shortest path resolution, gradle has full resolution with default to highest
Curtis Rueden
@ctrueden
But my point is: if all deps are managed by a BOM, that should win for either.
I.e.: what's the point of a BOM if the tooling just overrides what's specified there?
Giuseppe Barbieri
@elect86
it's a fragile situation, shortest path is order declaration dependent, to say. To simulate what maven is picking I think the best shot is to have a maven version, make it executed and copy paste the versions

I.e.: what's the point of a BOM if the tooling just overrides what's specified there?

to use it as a base to leverage things up

Giuseppe Barbieri
@elect86
The Scijava environment is so huge (Fiji, Scifio, etc), I think the simplest solution would be to have a single mother project including all root projects where (single) libraries upgrades get tested in the whole environment before bumping them up, this means, first of all, compile-time check (jan issue would have been caught there to say) and test check.
This, of course, shall also be integrated with a state-of-the-art mechanism to implement upcoming incubating (breaking) and deprecation changes (Kotlin and Gradle manage that pretty well)
Curtis Rueden
@ctrueden
Maybe I'm not making myself clear. The BOM avoids "shortest path" versus "full resolution with default to highest."

I think the simplest solution would be to have a single mother project including all root projects where (single) libraries upgrades get tested in the whole environment before bumping them up, this means, first of all, compile-time check (jan issue would have been caught there to say) and test check.

Yes, I fully agree. That's pom-scijava, and the melting-pot / mega-melt script. It exists.

Giuseppe Barbieri
@elect86

Maybe I'm not making myself clear. The BOM avoids "shortest path" versus "full resolution with default to highest."

Ok, so locally the bom will completely overwrite maven shortest path? Good. Sorry for not getting that earlier

I'd go back then and strictly enforce whatever is specified in the bom
Curtis Rueden
@ctrueden
:+1: Sounds good.
Ulrik Günther
@skalarproduktraum
thanks for figuring this nasty stuff out, @elect86 and @ctrueden, very much appreciated! :+1:
Ulrik Günther
@skalarproduktraum
@hanslovsky i can't find the messages anymore, but i've read somewhere that scripting-kotlin now kinda works, is that correct? does it work with the ScriptREPL?
Kyle I S Harrington
@kephale
i think that was in scijava-common
Curtis Rueden
@ctrueden
@skalarproduktraum You can test scijava/scripting-kotlin#8
If you build it, and add it to your environment, I'd love to know whether Kotlin then works in the ScriptREPL. (I doubt @hanslovsky tested that.)
Ulrik Günther
@skalarproduktraum
@ctrueden @hanslovsky just tried with the latest commit from that PR, doesnt work with the ScriptREPL. everything i evaluate only leads to an NPE
Curtis Rueden
@ctrueden
@skalarproduktraum Too bad; thanks for testing.
Ulrik Günther
@skalarproduktraum
:+1: i realised just now thoughh that i might have some outdated deps, i'll test again and let you know of the result
Philipp Hanslovsky
@hanslovsky
@skalarproduktraum can you share the stacktrace?
Ulrik Günther
@skalarproduktraum
@hanslovsky would love to, but there's no stacktrace, only java.lang.NullPointerException on the REPL output xD
as said, the source might be garbled deps, i'll fix that and try it again
Kimmy Costa
@kimmy_costa_gitlab
Hi everyone !
We have a small trouble figuring out how to integrate a gamepad on Scenery. Does anyone have a clue ? Thanks in advance !
Giuseppe Barbieri
@elect86
@skalarproduktraum