Where communities thrive


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

    Domino2357 on peptide_chain

    BondTree: added id ThreeDimensionalMolecularStruct… CyclicMolecularStructure: fixed… and 6 more (compare)

  • Jan 15 22:53

    Domino2357 on peptide_chain

    CyclicMolecularStructure: remov… BondTree: Removed redundant par… (compare)

  • Jan 15 21:47

    Domino2357 on peptide_chain

    GlutamineExample, minor chsanges Mostly useless stuff. (compare)

  • Jan 15 15:24

    Domino2357 on peptide_chain

    ThreeDimensionalMolecularStruct… CyclicMolecularStructures: inte… BondTreeCycle: added counter fo… and 1 more (compare)

  • Jan 14 16:31

    Domino2357 on peptide_chain

    CyclicMolecularStructure: fixed… CircularMolecularStructureExamp… (compare)

  • Jan 14 16:10

    Domino2357 on peptide_chain

    CircularMolecularStructure: deb… (compare)

  • Jan 14 15:25

    Domino2357 on peptide_chain

    CircularMolecularStructure: add… CircularMolecularStructure: res… (compare)

  • Jan 14 11:54

    Domino2357 on peptide_chain

    CircularMolecularStructure: add… CircularMolecularStructure: rem… CircularMolecularStructure: res… (compare)

  • Jan 14 10:44

    aryaman-gupta on parallel-rendering

    generalizes dataset generalizes window size (compare)

  • Jan 13 23:21

    aryaman-gupta on parallel-rendering

    removes bugs in supseg search incorporates empty supsegs into… corrects and generalizes calcul… and 1 more (compare)

  • Jan 13 18:48

    Domino2357 on peptide_chain

    CircularMolecularStructureExamp… CircularMolecularStructure: fix… (compare)

  • Jan 13 17:24

    Domino2357 on peptide_chain

    ThreeDimensionalMolecularStruct… CircularMolecularStructure: add… (compare)

  • Jan 10 12:13
    frauzufall opened #430
  • Jan 10 12:06
    frauzufall synchronize #411
  • Jan 10 12:06

    frauzufall on add-slicing-options

    Properties, VolumeSelectorWidge… AddSlicingPlane, MenuWeights.kt… AddSlicingPlane: Add handle to … and 1 more (compare)

  • Jan 07 15:26

    moreApi on synchonization-volume

    (compare)

  • Jan 07 15:25

    moreApi on synchronization-volume

    (compare)

  • Jan 07 15:19

    moreApi on synchonization-volume

    Volume.kt: formatting Volume.kt, VolumeManager.kt, Sc… WIP Network: SpimDataExample Vo… (compare)

  • Jan 07 15:17
    moreApi opened #467
  • Jan 06 21:56

    Domino2357 on peptide_chain

    CircularMolecularStructure: fir… CircularMolecularstructureExamp… ThreeDimensionalStructure: mini… (compare)

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
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