@Gabriel Beims Bräscher <gabrasc...@gmail.com>, I would agree that just
standardising could work as well, but only if we sanction just a single
implementation. This has proven to be hard in the past. I say, let's do
both;
- Let's make a facade. If names are good, do a transparent passthrough, if
not the best let's use our own, as Rohit suggested.
- If lang3 indeed provides all that we need from any library, let's
standardise on it.
Note that stringutils are just a simple albeit annoying example. We have
some more similar jobs to do, some of which involve message format or other
things and are quite risky.



On Mon, Sep 13, 2021 at 10:13 AM Suresh Anaparti <
suresh.anapa...@shapeblue.com> wrote:

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

-- 
Daan

Reply via email to