commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jörg Schaible <joerg.schai...@gmx.de>
Subject Re: [text] TEXT-36 (Was: [text] 1.0 release progress)
Date Fri, 30 Dec 2016 19:00:50 GMT
Hi Gilles,

Gilles wrote:

> On Fri, 30 Dec 2016 17:03:56 +0100, Jörg Schaible wrote:
>> Gilles wrote:
>>
>>> Hi.
>>>
>>> On Fri, 30 Dec 2016 09:40:20 -0500, Rob Tompkins wrote:
>>>> Hello all,
>>>>
>>>> Personally, I would like to resolve the TEXT-36 and TEXT-42 Jira
>>>> tickets before proceeding with the release, but I wanted to check
>>>> to
>>>> see if anyone else has any opinions on what work needs to be
>>>> completed
>>>> before the release.
>>>>
>>>> Regarding TEXT-36: 'Dependency on “Commons RNG” ‘, I’m relatively
>>>> indifferent here, I just want some other’s to weigh in as to their
>>>> thoughts before deciding to leave in the dependency
>>>
>>> I don't follow.
>>> Currently, there is no dependency towards RNG.
>>>
>>> Personally, I'm in favour of an API that "advertizes" and recommends
>>> usage of its RNG sibling component.  [As [TEXT] is, admittedly, a
>>> high-level component (and it already depends on [LANG]).]
>>>
>>> However a consensual proposal would be to define a custom interface
>>> (see JIRA discussion), and define the API around it.
>>>
>>> [TEXT] should be made "multimodule"; it could then provide bridges
>>> (cf. JIRA comment) in separate modules:
>>>
>>>   * commons-text-core (algos)
>>>   * commons-text-commons-rng-bridge (from
>>> "o.a.c.rng.UniformRandomProvider")
>>>   * commons-text-jdk-bridge (from "java.util.Random")
>>>
>>> The dependency towards Commons RNG thus becomes optional.
>>> But application developers have to explicitly choose an
>>> implementation (which is good).
>>
>> You can achieve something similar by declaring commons-rng as
>> optional. If
>> you introduce an API for the random functionality and one
>> implementation is
>> based on commons-rng, any user will have to declare this dependency
>> on his
>> own if he like to use this implementation.
> 
> I don't follow; do you suggest something like letting the JVM throw
> "ClassNotFoundException" at runtime?

Yes, that's the consequence. Therefore it has to be a specific 
implementation that depends on rng and not the RandomStringUtils class 
itself. Have a look at the POM of vfs core. The dependencies for *all* 
provider specific implementations are optional.

Such a setup might also fit for this case.

>> We have a similar setup in vfs where you have to declare jsch as
>> dependency
>> on your own if you want SSH support for the protocol in use.
> 
> Isn't it similar to what I proposed? [I.e. declare a dependency on
> the "commons-text-*-bridge" if one wants to use its contents.
> Or I don't follow...

RNG is no longer optional for commons-text if that interface is used in a 
method signature of RandomStringUtils. However, if commons-text has its own 
minimal abstraction layer, we can use the optional declaration and avoid a 
multi-project setup just for a single implementation.

Cheers,
Jörg


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message