@Anthony, it seems the classification complexity is imposed by our
*implementation* when the file is processed, extract the "base name" and
"version" and then append "our" (Geode) version (v1,v2) on each file of the
same name, to track some form of version.
This happens for all file "formats"... Which is why I suggest that we stick to
accepting 1 format, which is "almost" industry standard and accepted, rather
than just supporting any format that the customer chooses to use.
That is why I'm suggesting
“<artifact name>[ - <major> . <minor> . <patch> [ - <Release Tag> ] ] .jar”
Given this announcement from Git 2014, they are adopting a similar approach..
More Semver-like in its approach.
Java 9 Modularity also has a similar approach to but according to them, they
only deal with <major>.<minor>.<patch>.
Maybe this is a completely moot point, as JBoss modules determines uniqueness
by including version number in the "artifact name". Thus forcing the user to
first undeploy the previous jar before deploying the new version of it.
But having some form of consistency is good... Especially considering the our
testing is already broken in this following case:
assertThat(JarDeployer.getArtifactId("spark-network-common_2.11-2.3.1.jar")).isEqualTo("spark-network-common_2");
--Udo
On 10/8/20, 9:45 AM, "Anthony Baker" <bak...@vmware.com> wrote:
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%7Cudo%40vmware.com%7C5ce7e9c6e33a47c302c808d86b12af97%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637377075284402146&sdata=Rd0xwyMA89YBBAxWhYyb7qwqCub0rgSPlRnIJcvUpNI%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%7Cudo%40vmware.com%7C5ce7e9c6e33a47c302c808d86b12af97%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637377075284402146&sdata=3OPOy7kS9N1xn1T2EofJNXZiz4%2FXO0MEUSBLYgXmzMs%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%7Cudo%40vmware.com%7C5ce7e9c6e33a47c302c808d86b12af97%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637377075284412146&sdata=X%2BJg7JZFzZDCZLR3MR%2Fx9CkbfezWTOSb5IVbtTpTfkw%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%7Cudo%40vmware.com%7C5ce7e9c6e33a47c302c808d86b12af97%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637377075284412146&sdata=6tbMVL6NKQAlleg9B%2BQA%2FdRHdirCKBF1smGC7On2KJ8%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%7Cudo%40vmware.com%7C5ce7e9c6e33a47c302c808d86b12af97%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637377075284412146&sdata=zFHj8EXRrtCH2nS11NsPrZ83CJQBZ%2BLZwPyCw2rG%2By4%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%7Cudo%40vmware.com%7C5ce7e9c6e33a47c302c808d86b12af97%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637377075284412146&sdata=9qK%2Bx9wKBGmHkvx4r%2Blxfh22UTcTkDj9nwSOSi%2BE1Qk%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
>
>
>
