These are chat archives for fiji/fiji

12th
Jul 2017
Stephan Preibisch
@StephanPreibisch
Jul 12 2017 09:01
Hi @ctrueden, we would like to make a new pom-scijava project for the BigStitcher (migrate it from its current parent pom-fiji), however, its master branch still depends on a branch of SPIM_Registration (accumulative-stitching), which we have on the BigStitcher update site. So both branches are working in parallel. So in order to do make BigStitcher a parent of pom-scijava we would have two Travis versions on SPIM_Registration (master and accumulative-stitching). Would this work? Thanks so much!!
Stephan Preibisch
@StephanPreibisch
Jul 12 2017 10:46
I already made a Travis version of the branch, but travis seems to ignore compiling it: https://github.com/fiji/SPIM_Registration/commits/accumulative-stitching-travis Is there a trigger? It tried to compile some versions from the other branch: https://github.com/fiji/SPIM_Registration/commits/accumulative-stitching
Ai P. Vardhanabindu
@Aivard_twitter
Jul 12 2017 12:37
Thanks @kephale . @krzysg Thanks very much. I have tried it and it works now
Curtis Rueden
@ctrueden
Jul 12 2017 13:05
@StephanPreibisch You can use a different artifactId or a version suffix. Both have pros and cons. Getting Travis to build that branch requires a change to the Travis config.
I would recommend against multiple integration branches if you can avoid it.
Stephan Preibisch
@StephanPreibisch
Jul 12 2017 16:54
Thanks a lot @ctrueden .. we could wait transforming the BigStitcher into a pom-scijava child until we finally release it. Could we maybe already set it up as travis job that crashes for now due to the pom-fiji, but so we can quickly change the state? Does that make sense?
Curtis Rueden
@ctrueden
Jul 12 2017 19:13
@StephanPreibisch I took a quick look at these repos. I see that the SPIM_Registration branch also depends on net.imglib2.simulation:multiview-simulation:1.0.1 which also does not exist.
Maybe it makes more sense to use your own groupId like de.mdc-berlin.preibischlab for all your stuff?
Then you can have de.mdc-berlin.preibischlab:multiview-simulation and de.mdc-berlin.preibischlab:SPIM_Registration and de.mdc-berlin.preibischlab:BigStitcher?
And you can use master branch for all of those (fork SPIM_Registration from fiji into the PreibischLab org).
I'm happy to file the PRs needed so that Travis can build and deploy the respective master branches of those to the ImageJ Maven repository for you.
This would also be nice because the SPIM_Registration fork, even though the groupId is changed, would still make a JAR with the same name, and thus be overridden when you replace SPIM_Registration on your update site. (For some definition of "nice"—alternately it might make more sense to change the package prefix and artifactId so that both can coexist without conflict.)