I believe we did this for a reason, can't remember exactly what though. Most
probably drive by user's existing filenames. I believe we are probably
concerned that user's jar name might contain "_" or "-" themselves, like
common-logging.jar etc. So we had to resort to finding the first "." followed
by a digit to determine where the version pattern begins.
On 10/7/20, 1:44 PM, "Udo Kohlmeyer" <u...@vmware.com> wrote:
Hi there Geode Dev List,
Whilst doing work on
GEODE-8466<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.apache.org%2Fjira%2Fbrowse%2FGEODE-8466&data=04%7C01%7Cjiliao%40vmware.com%7C9dcbfe84c1d3440b350a08d86b01bec9%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637377002529341072%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Gc9WxdmegKea6T4OXKL4VUQ0mv6qDj2u9LmpSo3JR8Y%3D&reserved=0>
and looking at the functionality that the
ClassPathLoader.java<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Fblob%2Fdevelop%2Fgeode-core%2Fsrc%2Fmain%2Fjava%2Forg%2Fapache%2Fgeode%2Finternal%2FClassPathLoader.java&data=04%7C01%7Cjiliao%40vmware.com%7C9dcbfe84c1d3440b350a08d86b01bec9%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637377002529341072%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=ovqr1m9yWMrvvEzAi2M85wm0cmbbetsWgVxgvFnR0JQ%3D&reserved=0>,
JarDeployer.java<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Fblob%2Fdevelop%2Fgeode-core%2Fsrc%2Fmain%2Fjava%2Forg%2Fapache%2Fgeode%2Finternal%2FJarDeployer.java&data=04%7C01%7Cjiliao%40vmware.com%7C9dcbfe84c1d3440b350a08d86b01bec9%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637377002529341072%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=T7Ha6K8dLsXAT410lHLi4L8aPIWbz8yHhP9w0uEUvus%3D&reserved=0>
and
DeployedJar.java<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Fblob%2Fdevelop%2Fgeode-core%2Fsrc%2Fmain%2Fjava%2Forg%2Fapache%2Fgeode%2Finternal%2FDeployedJar.java&data=04%7C01%7Cjiliao%40vmware.com%7C9dcbfe84c1d3440b350a08d86b01bec9%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637377002529341072%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=yMz6yQyiV122Yx%2BT2g2kHkYYFeAfFZl%2FbSIQgMSciXI%3D&reserved=0>
provide around the “Deploy Jar” functionality, we came across some interesting
“supported” filename patterns.
According to the
JarDeployerFileTest.java<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Fblob%2Fdevelop%2Fgeode-core%2Fsrc%2FintegrationTest%2Fjava%2Forg%2Fapache%2Fgeode%2Finternal%2FJarDeployerFileTest.java&data=04%7C01%7Cjiliao%40vmware.com%7C9dcbfe84c1d3440b350a08d86b01bec9%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637377002529341072%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=wiUgaTQ3J%2F%2FhP4CDcLPcEliKTfGQzMhHHWh3z7mmKZI%3D&reserved=0>
the “supported” formats are as follows:
assertThat(JarDeployer.getArtifactId("abc.jar")).isEqualTo("abc");
assertThat(JarDeployer.getArtifactId("abc-1.jar")).isEqualTo("abc");
assertThat(JarDeployer.getArtifactId("ab.c.1.jar")).isEqualTo("ab.c");
assertThat(JarDeployer.getArtifactId("abc.v1.jar")).isEqualTo("abc.v1");
assertThat(JarDeployer.getArtifactId("abc-1.0.snapshot.jar")).isEqualTo("abc");
assertThat(JarDeployer.getArtifactId("abc-1.0.v1.jar")).isEqualTo("abc");
assertThat(JarDeployer.getArtifactId("spark-network-common_2.11-2.3.1.jar"))
.isEqualTo("spark-network-common_2");
Which don’t make any sense. As the generally accepted norm for a version
jar file would be: “<artifact name>[ - <major> . <minor> . <patch> - <Release
Tag> ] .jar”. (note the syntax in red)
I want to suggest that we DISCONTINUE supporting all jar name formats other
than the one mentioned above IMMEDIATELY. As the supported name format is just
“funky” but also wrong and can lead to misclassification of the artifact name….
as some of you with a keen eye would have spotted already 😉
For those who did not spot the mistake…
“spark-network-common_2.11-2.3.1.jar” is incorrectly classified and has the
WRONG artifact name. As “spark-network-common_2.11” is the correct artifact
name NOT “spark-network-common_2”!
I would like to introduce this change with
GEODE-8466<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.apache.org%2Fjira%2Fbrowse%2FGEODE-8466&data=04%7C01%7Cjiliao%40vmware.com%7C9dcbfe84c1d3440b350a08d86b01bec9%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637377002529341072%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Gc9WxdmegKea6T4OXKL4VUQ0mv6qDj2u9LmpSo3JR8Y%3D&reserved=0>.
This would be a “breaking” change, but we should change this sooner than
later. There is no transition ability here, as it would be too hard to have
Geode support both, as there is no simple way for the system to decide if the
name conforms to the “correct” format or not.
DISCUSS!!!
--Udo
