odule 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 no
__
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 rea
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
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'
@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
@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"...
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-co
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
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
co
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 proba
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 "." follow
11 matches
Mail list logo
