Given the wide variety of filenames possible do we even need a classification scheme? IOW, why not just take what the user gives us and say thank you :-). Is this restriction imposed by our *implementation* choices?
Anthony > On Oct 7, 2020, at 3:24 PM, Jinmei Liao <jil...@vmware.com> wrote: > > Wait, that reason doesn't make much sense either. Dale/Darrel, do you > remember why we did what we did? > > On 10/7/20, 3:12 PM, "Jinmei Liao" <jil...@vmware.com> wrote: > > 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=02%7C01%7Cbakera%40vmware.com%7C039c005932cf452eae1a08d86b0fd26a%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637377062979521227&sdata=CVDbR9YZqWaA1EkLsu5ROExmEzA6USoCMTzugC7uENI%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=02%7C01%7Cbakera%40vmware.com%7C039c005932cf452eae1a08d86b0fd26a%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637377062979521227&sdata=cdsjg1t510rPd%2FSB49AKCi%2BMoeOQRScJ%2BdFjacKxZl4%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=02%7C01%7Cbakera%40vmware.com%7C039c005932cf452eae1a08d86b0fd26a%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637377062979521227&sdata=ExCXhCbQvEXdObvGLDfAO5FrKSraUelPBcX0u1ahuhs%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=02%7C01%7Cbakera%40vmware.com%7C039c005932cf452eae1a08d86b0fd26a%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637377062979521227&sdata=cqUbHdC07CSEIzkH%2BOQRO8r8lcmypEXGYSLnzza033w%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=02%7C01%7Cbakera%40vmware.com%7C039c005932cf452eae1a08d86b0fd26a%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637377062979521227&sdata=jzWHk6yYryiKAG3Xai%2B34rtwwOD2cea5JgRyQuzfJPs%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=02%7C01%7Cbakera%40vmware.com%7C039c005932cf452eae1a08d86b0fd26a%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637377062979531223&sdata=uM34xKV8I7ylvYRuJoUbQS9jUP9TPR3pgplT2yLrMHQ%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 > > >
