Port to conda
TDClarke opened this issue · comments
I have struggled to get this to work with Anaconda, but scijava-jupyter-kernel is on conda forge.
i was wondering if you could add the project to Conda-forge?
I managed to package IJava on conda-forge from our fork:
https://anaconda.org/conda-forge/ijava
Thanks, I've just done a fresh install of anaconda and it runs on the jypter 7.0.8.
I have some imports needed to run my old projects (opencv), so will try that later in the week :)
I recommend creating a new environment with https://github.com/conda-forge/miniforge
Hi @mkitti , @TDClarke , apologize for hijacking this issue. But there's no option to start a discussion on the https://github.com/JaneliaSciComp/IJava fork, so I figured I'd mention it here. Myself and DFLib project recently committed to maintain a supported fork of iJava and keep the development going:
I hope there's a synergy with the work done on the JaneliaSciComp fork, and we can combine the efforts to go from multiple forks to a single community producing a quality kernel. If you are interested, we can take the discussion over to https://github.com/dflib/jjava/discussions (or continue it here 🙂 )
Thnx
Andrus
I see that you encountered problems with transitive dependencies, but I'm not sure how you resolved them.
We have found differences in how Apache Ivy and Maven handle transitive dependencies especially when classifiers are involved. Resolving this also required changes to Apache Ivy, which we have also forked.
Honestly, I think that package resolution should probably return to using Maven directly rather than using Ivy to emulate Maven.
I see that your fork does not preserve the original commit history.
I see that you encountered problems with transitive dependencies, but I'm not sure how you resolved them. We have found differences in how Apache Ivy and Maven handle transitive dependencies especially when classifiers are involved. Resolving this also required changes to Apache Ivy, which we have also forked.
Upgrading to Ivy 2.5.2 fixed this for us completely.
Honestly, I think that package resolution should probably return to using Maven directly rather than using Ivy to emulate Maven.
Probably a good idea, but so far Ivy 2.5.2 is holding up.
I see that your fork does not preserve the original commit history.
Yeah, with renaming to JJava (which was done to avoid confusion with distribution), the history has become unmergeable anyways, so we figured we'd start with a clean slate.
@mkitti .. BTW, just posted a new release of JJava, with internal build system switched to Maven (so it no longer requires a specific version of Java to build) and support for passing JVM params to the kernel via the JJAVA_JVM_OPTS var (i.e. things like -Xmx and --add-opens=..)
I described the transitive dependency issues here:
https://lists.apache.org/thread/j2gw1rt1xl9f4126cmhqb9gd2oz51c4k
Also see the post about Ivy maintainership here:
https://lists.apache.org/thread/h372vt1ztd6gfmgmfkmqzrksx6fpw97g
The point is that if we continue with Ivy as a dependency, we may also have to work on maintaining Ivy.
Interesting. We had a very similar issue related to Maven classifiers (slf4j-api was overwritten with slf4j-api:tests), and that got fixed by Ivy 2.5.2 (included in JJava). I wonder if that "fix" was just incidental, as I assume 2.5.2 doesn't work for you?
And yes, the state of Ivy is concerning (thanks for sharing the link!). I think we should start looking in the direction of Maven. I opened a task in JJava - dflib/jjava#23 . If you have any suggestions, or maybe already started some work in that direction, your insights will be greatly appreciated,
Previously, MavenResolver actually did use maven:
4d1ee69
Part of the work might just involve reverting the switch to Ivy.