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
    what's going on?
    Tobias Pietzsch
    @tpietzsch
    releasing stuff is such a timesink
    grml
    Tobias Pietzsch
    @tpietzsch
    hmmmm
    did I miss maven.imagej.net being deprecated or something like that?
    Tobias Pietzsch
    @tpietzsch
    @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]
    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...
    Tobias Pietzsch
    @tpietzsch
    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.