RuoshanLan on eyetracking-update
add raivoulmesampling example a… (compare)
moreApi on branch-of-jan
(buffered)Volume: check if volu… (compare)
skalarproduktraum on spirv_version
skalarproduktraum on master
ShaderCompiler: changes spirv v… (compare)
moreApi on branch-of-jan
SceneryBase.kt, VolumeManager.k… (compare)
moreApi on branch-of-jan
Settings: jvmOverloads for cons… (compare)
PowerOfNames on simvis
Properties: Correctly persist c… Merge branch 'master' into fix/… Merge pull request #432 from sc… and 4 more (compare)
moreApi on branch-of-jan
Java8 compatibility (compare)
Domino2357 on flythrough
Flythrough: first working proto… FlythroughExample: example for … Helix, Rollercoaster: minor fix… (compare)
moreApi on branch-of-jan
triggering jitpack rebuild (compare)
moreApi on branch-of-jan
Settings: Allow other prefixes,… (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