It's always good to move to the updated libraries, and I agree on upgrading to 
lang3 library (from lang).

We can continue use/improve our facade 'com.cloud.utils.StringUtils' for 
readability, custom utils from third party libs, this will be a single point of 
update whenever any util library is upgraded in future. 

Regards,
Suresh

On 10/09/21, 11:00 PM, "Gabriel Bräscher" <gabrasc...@gmail.com> wrote:

    I do understand that a facade adds great value in many situations.

    However, I am afraid that this could escalate up to a point of us
    maintaining multiple facades of well-known libraries that in the end
    already offer us what we need.
    Such libraries tend to be stable; as an example, lang3 was launched in 2011
    and has been rock solid since then.
    If we get into upgrading, at least in the "apache.commons.lang3" example,
    wpiçd be a "find and replace" operation [see:
    https://commons.apache.org/proper/commons-lang/article3_0.html].

    I am inclined into adopting "apache.commons.lang3" and then upgrading all
    occurrences of "apache.commons.lang" (as mentioned, "find and replace"
    operation). But I would be OK in moving into a facade.
    My main concern/goal is to adopt a pattern ASAP, and I would be +1 both
    ways as long as we ensure a standard in the current and future codebase.

    Em qua., 8 de set. de 2021 às 12:21, Daan Hoogland <daan.hoogl...@gmail.com>
    escreveu:

    > Daniel et al,
    > I've no preference and don't mind multiple dependencies when they supply
    > overlapping features. I do want to keep 3rd party libraries in facade
    > projects at all times. It keeps maintenance surface small and it is easier
    > to see conflicts happening (a good reason to reduce dependencies btw, me
    > contradicting me).
    > Both your and Rohit's points make sense to me.
    >
    > On Wed, Sep 8, 2021 at 2:36 PM Nicolas Vazquez <
    > nicolas.vazq...@shapeblue.com> wrote:
    >
    > > Hi Daniel,
    > >
    > > I don't have a preference either, but the work you are proposing on your
    > > PR makes sense to me.
    > >
    > >
    > > Regards,
    > >
    > > Nicolas Vazquez
    > >
    > > ________________________________
    > > From: Rohit Yadav <rohit.ya...@shapeblue.com>
    > > Sent: Wednesday, September 8, 2021 5:05 AM
    > > To: dev@cloudstack.apache.org <dev@cloudstack.apache.org>
    > > Subject: Re: [Discussion] String libs
    > >
    > > I don't have any specific inclination, I would use whatever becomes a
    > > standard.
    > >
    > > However, I prefer the readability of a utility method that is readable
    > and
    > > easy to understand such as isNullOrEmpty (which suggests it's doing a
    > null
    > > check) versus isEmpty.
    > >
    > > I suppose a refactoring exercise can be done by picking whatever
    > favourite
    > > dependency community consensus is built for (if at all) and then write a
    > > utility method in something like StringsUtil in cloud-utils and use it
    > > throughout the codebase so in future if we want to move to something
    > else -
    > > all you do is replace your favourite dependency with something new only
    > in
    > > StringsUtils of cloud-utils.
    > >
    > > ... and update the cloudstack-checkstyle to enforce the new agreed upon
    > > rule and also update -
    > >
    > https://cwiki.apache.org/confluence/display/CLOUDSTACK/Coding+conventions
    > >
    > >
    > > Regards.
    > >
    > > ________________________________
    > > From: Daniel Augusto Veronezi Salvador <gutoveron...@apache.org>
    > > Sent: Tuesday, September 7, 2021 04:37
    > > To: dev@cloudstack.apache.org <dev@cloudstack.apache.org>
    > > Subject: [Discussion] String libs
    > >
    > > Hi all,
    > >
    > > Currently, the main String libs we are using are "commons.lang" and
    > > "commons.lang3" (either directly or by our facade, "com.cloud.utils"). 
We
    > > have a current discussion about using them directly or via a facade 
(such
    > > as "com.cloud.utils"); however, a third implementation has been added
    > > (google.common.base), which adds more to the discussion. "commons.lang"
    > > already implement all we need; therefore, adding a third one does not
    > seem
    > > to add/improve/help with anything, but adding more moving parts and
    > > libraries that we need to watch out for (managing versions, checking for
    > > security issues, and so on).
    > >
    > > I created a PR (https://github.com/apache/cloudstack/pull/5386) to
    > > replace "google.common.base" with "commons.lang3". However, and as Daan
    > > suggested too, I'd like to go forward and revisit this discussion to
    > > standardize our code. To guide it, I'd like to start with what I think 
is
    > > the main topic:
    > >
    > > - Should we use a facade to "commons.lang"? Which are the pros and cons,
    > > according to your perspective?
    > >
    > > Best regards,
    > > Daniel.
    > >
    > >
    > >
    > >
    > >
    > >
    > >
    >
    > --
    > Daan
    >


 

Reply via email to