kephale on untagged-85b382aaed9556fe41e8
skalarproduktraum on master
Gradle: Only include scenery pr… (compare)
skalarproduktraum on instancing-improvements
OpenVRHMD: Improve sync behavio… Merge branch 'openvr-sync-impro… (compare)
moreApi on master
StackedVolumeExample: stacked, … (compare)
elect86 on gradleCatalog
jitpack jdk11 (compare)
frauzufall on refactor-node
Node: refactoring to support at… Scene: Make instanced nodes sel… (compare)
elect86 on gradleCatalog
up (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