did I miss maven.imagej.net being deprecated or something like that?
@ctrueden@hinerm I'm trying to release imglib2 core
I released pom-imagej 15.5.0
Then I released pom-imglib2 7.1.0 having the new pom-imagej 15.5.0 as a parent
Now I'm stuck on imglib2 (core), which Jenkins will not compile because: [ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.1:compile (default-compile) on project imglib2: Fatal error compiling: invalid target release: 1.8 -> [Help 1]
This is upstream of other stuff I want to release. The sad thing is that I expected this whole process to take an hour or so. Now it already took an afternoon and who knows whether I will get it done today :(
@tpietzsch Sorry for the frustration. The new pom-imagej sets scijava.jvm.version to 1.8. Since you updated imglib2's pom ancestry, it now inherits that.
To fix, you can set that property back to 1.6 in the imglib2 pom.
Next time, to save time, either ask us to do it, or do it during U.S. business hours so we can help faster.
The imagej.maven.net is of course not deprecated. It mirrors OSS sonatype and maven central. Bit this process is not instantaneous. There is a delay.
However, you can still do chained releases without waiting because Jenkins maven node has all it built before in the local repo cache.
@ctrueden that's cool with the local repo cache
can we alternatively move imglib2 builds to 1.8?
Sure. I would prefer that honestly but understand if you want to keep 1
.6 compatible for now.
@ctrueden and thanks for the quick reply!!!
Always glad to help :-)
Then let's move it to 1.8
I would also prefer that
How can I do that (re-configuring the jenkins jobs, I guess)?
Yeah just edit the imglib2 jenkins job changing the JVM to OpenJDK8.
I didn't want to do it accross the board yet since some projects are atill 1.6
if imglib2 is moving to j8 then maybe its time to just flip that switch. The other holdout is SJC but it would be nice to migrate it soon.
maintaining the two versions (partially) in parallel is mostly unnecessary complication
is the jenkins repo cache somehow exposed publicly?
my workflow is more or less: figure out in which oder and which versions of stuff i want to release
then do it one by one and check whether anything breaks for me locally
for the checking it would be cool to have jenkins' cached artefacts
@tpietzsch We should talk about the melting pot I wrote at Janelia last year.
The goal is to let you compile and run unit tests for all your stuff in one go. So you actually unit test at runtime what (e.g.) ImageJ users will have at runtime.
And it frees you from the (untenable) burden of needing every component to always be pinned against its latest upstream dependencies.
In general, there is a dichotomy/conflict between compile time—when you want to ensure building works against the oldest compatible/required version—and runtime—when you want to test again the newest compatible/available version.