Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Tobias Pietzsch
    @tpietzsch
    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]
    I didn't specify anywhere that I want 1.8
    So must be somewhere in the parent poms?
    How should I resolve this?
    I need help...
    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 :(
    Curtis Rueden
    @ctrueden
    @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.
    Tobias Pietzsch
    @tpietzsch
    @ctrueden that's cool with the local repo cache
    can we alternatively move imglib2 builds to 1.8?
    Curtis Rueden
    @ctrueden
    Sure. I would prefer that honestly but understand if you want to keep 1
    .6 compatible for now.
    Tobias Pietzsch
    @tpietzsch
    @ctrueden and thanks for the quick reply!!!
    Curtis Rueden
    @ctrueden
    Always glad to help :-)
    Tobias Pietzsch
    @tpietzsch
    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)?
    Curtis Rueden
    @ctrueden
    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.
    Tobias Pietzsch
    @tpietzsch
    I agree
    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
    Curtis Rueden
    @ctrueden
    @tpietzsch We should talk about the melting pot I wrote at Janelia last year.
    I will be in the office in 15 min or so.
    Tobias Pietzsch
    @tpietzsch
    ok!
    Curtis Rueden
    @ctrueden
    OK, I am here. Sorry for the delay.
    @tpietzsch Do you know about the melting-pot.sh script?
    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.
    I would caution against doing "staged" releases of things locally, or anything like that.
    Just test against a big ol' bag of SNAPSHOTs—that's what they are for.
    Tobias Pietzsch
    @tpietzsch
    @ctrueden I know that you made meting-pot but I never used it
    Curtis Rueden
    @ctrueden
    Yeah, I haven't used it a lot either. There are integrations tests with cram in the repo, so I know it works (at least ostensibly).
    We planned to set up a Jenkins job to do it for all of ImageJ2 core, and all of Fiji.
    But I never got around to it.
    But it sounds like exactly what you need, given your comments above.
    The only other thing we are missing is a way to cut multiple releases at the same time. There are lots of edge cases with that though, which make it harder to automate well.
    Tobias Pietzsch
    @tpietzsch
    reading through the doc now
    Curtis Rueden
    @ctrueden
    See also the cram tests for examples.
    Happy to beef up the docs if things are opaque.
    I'd also be happy to create a Jenkins job that regularly tests whatever component(s) you want, however you want, within the powers of that script.