RuoshanLan on eyetracking-update
Gradle: Bump lwjgl to 3.3.1, in… SceneryBase: Do renderer and sc… Renderer: Preliminary support f… and 11 more (compare)
skalarproduktraum on vulkan-macos-and-apple-silicon
Volume: Introduce level limitin… (compare)
skalarproduktraum on vulkan-macos-and-apple-silicon
UpdatableTexture: Handle self-a… (compare)
skalarproduktraum on vulkan-macos-and-apple-silicon
UpdatableTexture: Add option to… (compare)
skalarproduktraum on vulkan-macos-and-apple-silicon
UpdatableTexture: Add option to… (compare)
skalarproduktraum on vulkan-macos-and-apple-silicon
UpdatableTexture: Add option to… (compare)
skalarproduktraum on vulkan-macos-and-apple-silicon
Gradle: Update bigdataviewer-co… (compare)
wbueschel on openxr-support
Gradle: Add OpenXR runtime OpenXRHMD: Add initial sketch a… (compare)
aryaman-gupta on parallel-rendering
changes in benchmarking code (compare)
aryaman-gupta on parallel-rendering
configuration changes and debug… (compare)
aryaman-gupta on parallel-rendering
makes empty space texture optio… (compare)
aryaman-gupta on parallel-rendering
changes work group size calcula… enables device selection by ID,… implements in place handling of… and 1 more (compare)
skalarproduktraum on vulkan-macos-and-apple-silicon
Gradle: Include correct binarie… (compare)
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)
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.
Class-Path
in META-INF/MANIFEST.MF
, but it's not in an ideal form.)
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
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.
ScriptREPL
. (I doubt @hanslovsky tested that.)
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.
ProteinComparisonExample
which is in the latest commit on the branch that's running on your cave, serialization-improvements
, and also here