Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 13:50
    elect86 synchronize #410
  • 13:50

    elect86 on gradleCatalog

    trying to drop bdv snapshots (compare)

  • 13:37

    Domino2357 on protein_rollercoaster

    Rollercoaster: first sketch. Set up example for the rollerco… (compare)

  • 11:50

    skalarproduktraum on volumemanager-computeshader-fix

    (compare)

  • 11:50

    skalarproduktraum on master

    VolumeManager/Volume: Fix issue… Merge pull request #386 from sc… (compare)

  • 11:50
    skalarproduktraum closed #386
  • 08:46

    moreApi on bdv_bridge

    wip (compare)

  • May 17 17:04
    skalarproduktraum labeled #422
  • May 17 17:04
    skalarproduktraum assigned #422
  • May 17 17:04
    skalarproduktraum opened #422
  • May 17 17:03

    skalarproduktraum on fix-vulkanrenderer-screenshot-overwriting

    VulkanRenderer: Fix issue where… (compare)

  • May 17 14:54
    elect86 synchronize #410
  • May 17 14:54

    elect86 on gradleCatalog

    OpenVRHMD: Improve sync behavio… VRControllerExample: Improve li… VulkanNodeHelpers/OpenGLRendere… and 20 more (compare)

  • May 17 10:10
    skalarproduktraum commented #418
  • May 17 10:07

    skalarproduktraum on update-to-spirvcrossj-0.8.0

    (compare)

  • May 17 10:07

    skalarproduktraum on master

    Build: Bump spirvcrossj to 0.8.… Gradle: Remove staging reposito… Merge pull request #420 from sc… (compare)

  • May 17 10:07
    skalarproduktraum closed #420
  • May 17 10:05

    skalarproduktraum on actions-add-jdk8-builds

    (compare)

  • May 17 10:05

    skalarproduktraum on improve-openvr-button-handling

    (compare)

  • May 17 10:04

    skalarproduktraum on openvr-sync-fixes

    (compare)

Jan T
@moreApi
to the timeline demo
Giuseppe Barbieri
@elect86
can you push in another branch?
Jan T
@moreApi
frist i try another jdk version :D
Giuseppe Barbieri
@elect86
good idea
Ulrik Günther
@skalarproduktraum
it'd say it's not the jdk version, but rather a missing dep on an imglib2 lib
Giuseppe Barbieri
@elect86

imglib2-ui is actually there, but its transitive deps get updated for version conflict

|    +--- 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 (*)

I tried to force them, but it fails because it's impossible given the actual dependency tree

Kyle I S Harrington
@kephale
imglib2-ui is deprecated i believe
Giuseppe Barbieri
@elect86
even better
Jan T
@moreApi
So what are my options? Sry, I dont understand much of this dependency stuff.
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