Currently, we have multiple disparate metadata sources:
jjava-kernel-metadata.json with variables substituted during build by Maven and packaged in the jar. It is redundant. Using Maven module name as the "project" name is not we want and version can be taken from Maven metadata (see below).kernel-metadata.json is not something known or required by Jupyter, is not a part of our distro, and is fully external the project. I think it came from the Kaggle world, and the assumption of its presence on the Kernel classpath is entirely unwarranted. Let's remove this mechanism completely.
Instead, let's prvide the kernel name in the "main" menthod starting the kernel, and take version from Maven the metadata in the jar (e.g., META-INF/maven/org.dflib.jjava/jjava/pom.properties)
Currently, we have multiple disparate metadata sources:
jjava-kernel-metadata.jsonwith variables substituted during build by Maven and packaged in the jar. It is redundant. Using Maven module name as the "project" name is not we want andversioncan be taken from Maven metadata (see below).kernel-metadata.jsonis not something known or required by Jupyter, is not a part of our distro, and is fully external the project. I think it came from the Kaggle world, and the assumption of its presence on the Kernel classpath is entirely unwarranted. Let's remove this mechanism completely.Instead, let's prvide the kernel name in the "main" menthod starting the kernel, and take
versionfrom Maven the metadata in the jar (e.g.,META-INF/maven/org.dflib.jjava/jjava/pom.properties)