upgrade to CDK 2

[egonw]

This turns out to be a bit harder than expected, as it simultaneously needs updating of JChemPaint and AMBIT ...

[johnmay]

not an "issue"... this is a ToDo

[johnmay]

Have unsubscribed from all nodes3knime related updates now :-). So feel free to use this is a todo list

[rajarshi]

Are there any updates on this?

[egonw]

No :(

[egonw]

I have recently looked into updating JChemPaint to CDK 2.1 and 2.0, but there are regressions. See JChemPaint/jchempaint#191

[webbres]

Is JChemPaint the blocker and if so is this still the case?

Could we rebrand the existing nodes legacy nodes and create a new plugin based on CDK 2.x?

[egonw]

@webbres, that's exactly what Daria and I were discussing yesterday.

[webbres]

👍 happy to contribute to that effort if it's done

[egonw]

I've forked a repo for this: https://github.com/cdk/nodes4knime-cdk2

But the wifi here is too slow to set up the KNIME SDK

[johnmay]

Why did you fork it Egon? The API should be compatible enough that it didn't need a fork. Any changes are likely unspecified invariants being missed by the callee.

[webbres]

I think the main issue is JChemPaint and Ambit don't work with CDK 2, so upgrading loses that functionality which breaks backwards compatibility with existing workflows.

You can't deprecate the nodes as they don't work anymore.

[egonw]

Why did you fork it Egon? The API should be compatible enough that it didn't need a fork. Any changes are likely unspecified invariants being missed by the callee.

Think of it as the migration path from Python2 to Python3: there were so many dependencies, many tools could not easily migrate to Python3. Similarly, there is functonality in the CDK-1.5-based KNIME nodes that are not easily migrated.

The idea of the fork is to have both world in parallel, allowing people to use CDK-2.x-based KNIME nodes whenever possible, but at the same time being able to install the CDK-1.5-based KNIME nodes when needed.