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,

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

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

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

@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

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

@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

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

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

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

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

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

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

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

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

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

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 "."

[DISCUSS] Supported filename convention for Deploy Jars functionality

Hi there Geode Dev List, Whilst doing work on GEODE-8466 and looking at the functionality that the ClassPathLoader.java,

Re: [Discussion] RFC to make Geode's working directory configurable

Hi Jake, Production code will use it. In my initial (very cursory) scan of current uses of user.dir, it looked as if some uses were in places that didn't have ready access to a cache or other good source for this property. It may have been hasty for me to leap to a singleton. I will take a

Re: [Discussion] RFC to make Geode's working directory configurable

Dale, I have few questions that I have added as comments to the RFC. On 10/6/20, 5:24 PM, "Jacob Barrett" wrote: Do we expect this to be used by production code or just test code? If this is going to be used by production code I am concerned with introducing another singleton class into