Re: [DISCUSS] Supported filename convention for Deploy Jars functionality

[Udo Kohlmeyer]

Thank you for the input.

@Owen, just is not a pressing issue that I have, I was just in the code, saw 
the test, that seemed "incorrect" in the determination of version and/or 
artifact name of a jar file.
@Dan, I agree with you I don't want to introduce a breaking change for no 
reason. Bad experience.

What is evident from some testing that I've been doing, is that we do have an 
undocumented feature and format that Geode will accept. So maybe Step1 in this 
case is to document the file format that we currently "support". As it is VERY 
close to the one that I've been suggesting. In addition, we need something that 
resembles consistency. 

E.g
The system will "detect" similar artifact names if the following formats are 
used:

{artifact_name}.jar
{artifact_name}-0.0.0.jar

But not when using:

{artifact_name}.v1.jar

Which means that in 1 case the artifact name is determined and can be 
"upgraded" and in the other not. But maybe going forward this file format is 
documented as a preferred format. Maybe that is a gentler way of changing the 
format.

But I think for future use, there should be no restriction on filename format. 
As consistency of experience is important. A more explicit jar deploy command 
is required, similar to that of maven's install jar format.. artifact name + 
version, explicitly required when deploying the file. Deploying from maven with 
dependencies does sound inviting.

But thank you for all the input.

--Udo

On 10/10/20, 8:16 AM, "Dan Smith"  wrote:

I also don't see a pressing need for a breaking change here. It's unlikely 
the current behavior is going to cause any problems for users with "standard" 
jar file names. On the other hand, having failures or new, weird classpath 
issues on upgrade for users with non-standard jar names doesn't seem like a 
good UX.

I do like the idea of moving forward to a better way of specifying artifact 
names and versions than parsing a file name. Maybe jigsaw module names, or 
maybe supporting deploying a maven artifact (and its dependences??).

-Dan

From: Owen Nichols 
Sent: Wednesday, October 7, 2020 7:24 PM
To: dev@geode.apache.org 
    Subject: Re: [DISCUSS] Supported filename convention for Deploy Jars 
functionality

I do not feel that we need to restrict the names of jar files that users 
may deploy.  GEODE-7436 does the most reasonable thing in the vast majority of 
cases, but a user is always free to override the default logic, either by 
manually un-deploying some existing jar before deploying a new one, or renaming 
one of them if they truly require both of two lookalike jars deployed 
simultaneously.  This is consistent with the ideal of making simple things 
easy, but hard things possible.

I fail to see a problem here that rises to the level of justifying 
"breaking changes" with "no transition ability".

@Udo, the work you are citing in conjunction with this appears to be 
related to classloader changes.  Can you clarify whether your proposed 
restrictions on jar names are essential to implement your classloader changes, 
or just an unrelated thing you happened to notice in the course of that work?

On 10/7/20, 4:45 PM, "Udo Kohlmeyer"  wrote:

@Owen, not sure if I'd use "harmless". I'd use "unlikely", rather than 
"harmless", as it can still have harmful consequences.

I think the "intuitive" nature of the versioning means we have to have 
a standard jar file format, so that the system can intuitively understand that 
"some-jar-0.2" is the update to "some-jar-0.1". There HAS to be some form of 
format for the auto-version-update to work, otherwise one could never compare.

Maybe I'm just trying to be more explicit. That way, any implementation 
of the "deploy jar" functionality can rely on a single fact, that the jar files 
will be in a known format.

The alternative is maven-like in behavior... then we don't have to deal 
with explicit file formats. When a jar is deployed, the feature behaves more 
maven-like, and "artifact name", "version" and file path is required. That way, 
the jar file does not ever have to meet the required format. All information 
required has been provided by the user. Removes the false-positives that could 
be introduced.

As there is no public API here, the only change we would have to deal 
with is the gfsh scripting, which I assume is not so horrible.

Anyway.. just thoughts..

--Udo

On 10/8/20, 9:57 AM, "Owen Nichols"  wrote:

The goal of the GEODE-7436 change is that when user deploys 
some-jar-0.1, then later deploys some-jar-0.2, we will do the intuitive thing 
and treat it as an update.  In Geode 1.11 and earlier, we instead wound up with 
*both

Re: [DISCUSS] Supported filename convention for Deploy Jars functionality

[Dan Smith]

I also don't see a pressing need for a breaking change here. It's unlikely the 
current behavior is going to cause any problems for users with "standard" jar 
file names. On the other hand, having failures or new, weird classpath issues 
on upgrade for users with non-standard jar names doesn't seem like a good UX.

I do like the idea of moving forward to a better way of specifying artifact 
names and versions than parsing a file name. Maybe jigsaw module names, or 
maybe supporting deploying a maven artifact (and its dependences??).

-Dan

From: Owen Nichols 
Sent: Wednesday, October 7, 2020 7:24 PM
To: dev@geode.apache.org 
Subject: Re: [DISCUSS] Supported filename convention for Deploy Jars 
functionality

I do not feel that we need to restrict the names of jar files that users may 
deploy.  GEODE-7436 does the most reasonable thing in the vast majority of 
cases, but a user is always free to override the default logic, either by 
manually un-deploying some existing jar before deploying a new one, or renaming 
one of them if they truly require both of two lookalike jars deployed 
simultaneously.  This is consistent with the ideal of making simple things 
easy, but hard things possible.

I fail to see a problem here that rises to the level of justifying "breaking 
changes" with "no transition ability".

@Udo, the work you are citing in conjunction with this appears to be related to 
classloader changes.  Can you clarify whether your proposed restrictions on jar 
names are essential to implement your classloader changes, or just an unrelated 
thing you happened to notice in the course of that work?

On 10/7/20, 4:45 PM, "Udo Kohlmeyer"  wrote:

@Owen, not sure if I'd use "harmless". I'd use "unlikely", rather than 
"harmless", as it can still have harmful consequences.

I think the "intuitive" nature of the versioning means we have to have a 
standard jar file format, so that the system can intuitively understand that 
"some-jar-0.2" is the update to "some-jar-0.1". There HAS to be some form of 
format for the auto-version-update to work, otherwise one could never compare.

Maybe I'm just trying to be more explicit. That way, any implementation of 
the "deploy jar" functionality can rely on a single fact, that the jar files 
will be in a known format.

The alternative is maven-like in behavior... then we don't have to deal 
with explicit file formats. When a jar is deployed, the feature behaves more 
maven-like, and "artifact name", "version" and file path is required. That way, 
the jar file does not ever have to meet the required format. All information 
required has been provided by the user. Removes the false-positives that could 
be introduced.

As there is no public API here, the only change we would have to deal with 
is the gfsh scripting, which I assume is not so horrible.

Anyway.. just thoughts..

--Udo

On 10/8/20, 9:57 AM, "Owen Nichols"  wrote:

The goal of the GEODE-7436 change is that when user deploys 
some-jar-0.1, then later deploys some-jar-0.2, we will do the intuitive thing 
and treat it as an update.  In Geode 1.11 and earlier, we instead wound up with 
*both* deployed, which is bad!

In the weird example below of spark-network-common_2.11-2.3.1.jar, it 
is harmless that we stem it as spark-network-common_2 (*if* for some very crazy 
reason a user NEEDS both spark-network-common_2.11-0.0.0.jar and 
spark-network-common_2.12-0.0.0.jar deployed side-by-side, they can simply 
rename the jar to something more sane)

On 10/7/20, 3:45 PM, "Anthony Baker"  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  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"  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"  wrote:
>
>Hi there Geode Dev List,
>
>Whilst doing work on 
GEODE-8466<http

Re: [DISCUSS] Supported filename convention for Deploy Jars functionality

[Owen Nichols]

I do not feel that we need to restrict the names of jar files that users may 
deploy.  GEODE-7436 does the most reasonable thing in the vast majority of 
cases, but a user is always free to override the default logic, either by 
manually un-deploying some existing jar before deploying a new one, or renaming 
one of them if they truly require both of two lookalike jars deployed 
simultaneously.  This is consistent with the ideal of making simple things 
easy, but hard things possible.

I fail to see a problem here that rises to the level of justifying "breaking 
changes" with "no transition ability".

@Udo, the work you are citing in conjunction with this appears to be related to 
classloader changes.  Can you clarify whether your proposed restrictions on jar 
names are essential to implement your classloader changes, or just an unrelated 
thing you happened to notice in the course of that work?

On 10/7/20, 4:45 PM, "Udo Kohlmeyer"  wrote:

@Owen, not sure if I'd use "harmless". I'd use "unlikely", rather than 
"harmless", as it can still have harmful consequences. 

I think the "intuitive" nature of the versioning means we have to have a 
standard jar file format, so that the system can intuitively understand that 
"some-jar-0.2" is the update to "some-jar-0.1". There HAS to be some form of 
format for the auto-version-update to work, otherwise one could never compare.

Maybe I'm just trying to be more explicit. That way, any implementation of 
the "deploy jar" functionality can rely on a single fact, that the jar files 
will be in a known format. 

The alternative is maven-like in behavior... then we don't have to deal 
with explicit file formats. When a jar is deployed, the feature behaves more 
maven-like, and "artifact name", "version" and file path is required. That way, 
the jar file does not ever have to meet the required format. All information 
required has been provided by the user. Removes the false-positives that could 
be introduced.

As there is no public API here, the only change we would have to deal with 
is the gfsh scripting, which I assume is not so horrible.

Anyway.. just thoughts..

--Udo

On 10/8/20, 9:57 AM, "Owen Nichols"  wrote:

The goal of the GEODE-7436 change is that when user deploys 
some-jar-0.1, then later deploys some-jar-0.2, we will do the intuitive thing 
and treat it as an update.  In Geode 1.11 and earlier, we instead wound up with 
*both* deployed, which is bad!

In the weird example below of spark-network-common_2.11-2.3.1.jar, it 
is harmless that we stem it as spark-network-common_2 (*if* for some very crazy 
reason a user NEEDS both spark-network-common_2.11-0.0.0.jar and 
spark-network-common_2.12-0.0.0.jar deployed side-by-side, they can simply 
rename the jar to something more sane)

On 10/7/20, 3:45 PM, "Anthony Baker"  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  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"  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"  wrote:
> 
>Hi there Geode Dev List,
> 
>Whilst doing work on 
GEODE-8466
 and looking at the functionality that the 
ClassPathLoader.java,
 

Re: [DISCUSS] Supported filename convention for Deploy Jars functionality

[Jinmei Liao]

Oh, I think I remember there are some customers who has jar files that don't 
quite follow the industry standard that would use a "-" before the versions, 
like abc.1.0.jar, they would like abc.1.1.jar to replace abc.1.0.jar.

On 10/7/20, 4:45 PM, "Udo Kohlmeyer"  wrote:

@Owen, not sure if I'd use "harmless". I'd use "unlikely", rather than 
"harmless", as it can still have harmful consequences. 

I think the "intuitive" nature of the versioning means we have to have a 
standard jar file format, so that the system can intuitively understand that 
"some-jar-0.2" is the update to "some-jar-0.1". There HAS to be some form of 
format for the auto-version-update to work, otherwise one could never compare.

Maybe I'm just trying to be more explicit. That way, any implementation of 
the "deploy jar" functionality can rely on a single fact, that the jar files 
will be in a known format. 

The alternative is maven-like in behavior... then we don't have to deal 
with explicit file formats. When a jar is deployed, the feature behaves more 
maven-like, and "artifact name", "version" and file path is required. That way, 
the jar file does not ever have to meet the required format. All information 
required has been provided by the user. Removes the false-positives that could 
be introduced.

As there is no public API here, the only change we would have to deal with 
is the gfsh scripting, which I assume is not so horrible.

Anyway.. just thoughts..

--Udo

On 10/8/20, 9:57 AM, "Owen Nichols"  wrote:

The goal of the GEODE-7436 change is that when user deploys 
some-jar-0.1, then later deploys some-jar-0.2, we will do the intuitive thing 
and treat it as an update.  In Geode 1.11 and earlier, we instead wound up with 
*both* deployed, which is bad!

In the weird example below of spark-network-common_2.11-2.3.1.jar, it 
is harmless that we stem it as spark-network-common_2 (*if* for some very crazy 
reason a user NEEDS both spark-network-common_2.11-0.0.0.jar and 
spark-network-common_2.12-0.0.0.jar deployed side-by-side, they can simply 
rename the jar to something more sane)

On 10/7/20, 3:45 PM, "Anthony Baker"  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  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"  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"  wrote:
> 
>Hi there Geode Dev List,
> 
>Whilst doing work on 
GEODE-8466
 and looking at the functionality that the 
ClassPathLoader.java,
 
JarDeployer.java
 and 
DeployedJar.java
 provide around the “Deploy Jar” functionality, we came 

Re: [DISCUSS] Supported filename convention for Deploy Jars functionality

[Udo Kohlmeyer]

@Owen, not sure if I'd use "harmless". I'd use "unlikely", rather than 
"harmless", as it can still have harmful consequences. 

I think the "intuitive" nature of the versioning means we have to have a 
standard jar file format, so that the system can intuitively understand that 
"some-jar-0.2" is the update to "some-jar-0.1". There HAS to be some form of 
format for the auto-version-update to work, otherwise one could never compare.

Maybe I'm just trying to be more explicit. That way, any implementation of the 
"deploy jar" functionality can rely on a single fact, that the jar files will 
be in a known format. 

The alternative is maven-like in behavior... then we don't have to deal with 
explicit file formats. When a jar is deployed, the feature behaves more 
maven-like, and "artifact name", "version" and file path is required. That way, 
the jar file does not ever have to meet the required format. All information 
required has been provided by the user. Removes the false-positives that could 
be introduced.

As there is no public API here, the only change we would have to deal with is 
the gfsh scripting, which I assume is not so horrible.

Anyway.. just thoughts..

--Udo

On 10/8/20, 9:57 AM, "Owen Nichols"  wrote:

The goal of the GEODE-7436 change is that when user deploys some-jar-0.1, 
then later deploys some-jar-0.2, we will do the intuitive thing and treat it as 
an update.  In Geode 1.11 and earlier, we instead wound up with *both* 
deployed, which is bad!

In the weird example below of spark-network-common_2.11-2.3.1.jar, it is 
harmless that we stem it as spark-network-common_2 (*if* for some very crazy 
reason a user NEEDS both spark-network-common_2.11-0.0.0.jar and 
spark-network-common_2.12-0.0.0.jar deployed side-by-side, they can simply 
rename the jar to something more sane)

On 10/7/20, 3:45 PM, "Anthony Baker"  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  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"  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"  wrote:
> 
>Hi there Geode Dev List,
> 
>Whilst doing work on 
GEODE-8466
 and looking at the functionality that the 
ClassPathLoader.java,
 
JarDeployer.java
 and 
DeployedJar.java
 provide around the “Deploy Jar” functionality, we came 

Re: [DISCUSS] Supported filename convention for Deploy Jars functionality

[Udo Kohlmeyer]

@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 

“[ -  .  .  [ -  ] ] .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 ...

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"  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  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"  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"  wrote:
> 
>Hi there Geode Dev List,
> 
>Whilst doing work on 
GEODE-8466
 and looking at the functionality that the 
ClassPathLoader.java,
 
JarDeployer.java
 and 
DeployedJar.java
 provide around the “Deploy Jar” functionality, we came across some interesting 
“supported” filename patterns.
> 
>According to the 
JarDeployerFileTest.java
 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");
>

Re: [DISCUSS] Supported filename convention for Deploy Jars functionality

[Owen Nichols]

The goal of the GEODE-7436 change is that when user deploys some-jar-0.1, then 
later deploys some-jar-0.2, we will do the intuitive thing and treat it as an 
update.  In Geode 1.11 and earlier, we instead wound up with *both* deployed, 
which is bad!

In the weird example below of spark-network-common_2.11-2.3.1.jar, it is 
harmless that we stem it as spark-network-common_2 (*if* for some very crazy 
reason a user NEEDS both spark-network-common_2.11-0.0.0.jar and 
spark-network-common_2.12-0.0.0.jar deployed side-by-side, they can simply 
rename the jar to something more sane)

On 10/7/20, 3:45 PM, "Anthony Baker"  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  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"  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"  wrote:
> 
>Hi there Geode Dev List,
> 
>Whilst doing work on 
GEODE-8466
 and looking at the functionality that the 
ClassPathLoader.java,
 
JarDeployer.java
 and 
DeployedJar.java
 provide around the “Deploy Jar” functionality, we came across some interesting 
“supported” filename patterns.
> 
>According to the 
JarDeployerFileTest.java
 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: “[ -  .  .  - 
 ] .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 

Re: [DISCUSS] Supported filename convention for Deploy Jars functionality

[Anthony Baker]

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  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"  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"  wrote:
> 
>Hi there Geode Dev List,
> 
>Whilst doing work on 
> GEODE-8466
>  and looking at the functionality that the 
> ClassPathLoader.java,
>  
> JarDeployer.java
>  and 
> DeployedJar.java
>  provide around the “Deploy Jar” functionality, we came across some 
> interesting “supported” filename patterns.
> 
>According to the 
> JarDeployerFileTest.java
>  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: “[ -  .  .  - 
>  ] .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.
>  This would be a “breaking” change, but we should 

Re: [DISCUSS] Supported filename convention for Deploy Jars functionality

[Udo Kohlmeyer]

Jinmei, thank you for that. Whilst I believe supporting existing users custom 
formats sound nice, it does complicate the whole process too much.
As can be seen from the example code that I posted, the test is already 
retrieving the wrong artifact name, as there is no way to determine what the 
correct format should be if there are many.

I think it is reasonable to standardize on a format. Document said format and 
then apply the pattern consistently. Then adding that to the notes.

It even simplifies the logic where we have to deal with non-versioned jars and 
we then append the ".v + {version}" to make sure we can handle versions, etc... 
As this can now be adapted to "abc.jar" being converted to "abc-1.0.0.jar". 
Thus being able to add a version to an unversioned jar. In addition a standard 
way to determine a version,etc...

As I said, unfortunately the is no simple way to deal with this transition and 
transitioning to a standard by ripping off the bandaid in one go is sometime 
preferable.

--Udo

On 10/8/20, 9:25 AM, "Jinmei Liao"  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"  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"  wrote:

Hi there Geode Dev List,

Whilst doing work on 
GEODE-8466
 and looking at the functionality that the 
ClassPathLoader.java,
 
JarDeployer.java
 and 
DeployedJar.java
 provide around the “Deploy Jar” functionality, we came across some interesting 
“supported” filename patterns.

According to the 
JarDeployerFileTest.java
 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: “[ -  .  .  - 
 ] .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 

Re: [DISCUSS] Supported filename convention for Deploy Jars functionality

[Jinmei Liao]

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"  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"  wrote:

Hi there Geode Dev List,

Whilst doing work on 
GEODE-8466
 and looking at the functionality that the 
ClassPathLoader.java,
 
JarDeployer.java
 and 
DeployedJar.java
 provide around the “Deploy Jar” functionality, we came across some interesting 
“supported” filename patterns.

According to the 
JarDeployerFileTest.java
 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: “[ -  .  .  - 
 ] .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.
 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

Re: [DISCUSS] Supported filename convention for Deploy Jars functionality

[Jinmei Liao]

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"  wrote:

Hi there Geode Dev List,

Whilst doing work on 
GEODE-8466
 and looking at the functionality that the 
ClassPathLoader.java,
 
JarDeployer.java
 and 
DeployedJar.java
 provide around the “Deploy Jar” functionality, we came across some interesting 
“supported” filename patterns.

According to the 
JarDeployerFileTest.java
 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: “[ -  .  .  -  ] .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.
 This would be a “breaking” change, but we should change this sooner 

[DISCUSS] Supported filename convention for Deploy Jars functionality

[Udo Kohlmeyer]

Hi there Geode Dev List,

Whilst doing work on 
GEODE-8466 and looking at the 
functionality that the 
ClassPathLoader.java,
 
JarDeployer.java
 and 
DeployedJar.java
 provide around the “Deploy Jar” functionality, we came across some interesting 
“supported” filename patterns.

According to the 
JarDeployerFileTest.java
 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: “[ -  .  .  -  
] .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. 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