scenerygraphics/SciView

Come for the sciview, stay for the scenery

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.

Giuseppe Barbieri

@elect86

https://github.com/scenerygraphics/SciView/tree/TransformListenerClassNotFound

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

Giuseppe Barbieri

@elect86

is imglib2-ui at the end deprecated or not?

Philipp Hanslovsky

@hanslovsky

@skalarproduktraum I installed SciView (from the SciView update site) and scripting-kotlin (from the ntakt) update site and I saw that SciView installs kotlin-compiler-embeddable and other jars that are part of the shaded scripting-kotlin jar. There may be some friction there.

Kyle I S Harrington

@kephale

@hanslovsky the SciView update site is being deprecated

https://docs.scenery.graphics/sciview/development/update-sites

try https://sites.imagej.net/sciview-ageratum/

we've switched to using a new update site for each major release

Philipp Hanslovsky

@hanslovsky

Thanks @kephale I will try when I get a chance

Ulrik Günther

@skalarproduktraum

@kimmy_costa_gitlab the gamepad should actually work right out of the box. if it's connected e.g. via bluetooth on your master node (you have an xbox controller, right?), then you should be able to move around using it. for customization of gamepad control, have a look at ProteinComparisonExample which is in the latest commit on the branch that's running on your cave, serialization-improvements, and also here

Kimmy Costa

@kimmy_costa_gitlab

@skalarproduktraum yes that's what I thought by looking at the code ! We do have an xbox controller and we connected it to our master which is why I found weird that I didn't work right away.

@skalarproduktraum we will try to look at the example thanks !

Tobias Pietzsch

@tpietzsch

@elect86

is imglib2-ui at the end deprecated or not?

yes, it is deprecated

Giuseppe Barbieri

@elect86

thanks Tobias

Where communities thrive

People

Repo info

Activity