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 Sat, 31 Dec 2016 00:24:22 GMT
Gilles wrote:

> On Fri, 30 Dec 2016 23:05:25 +0100, Gilles wrote:
>> On Fri, 30 Dec 2016 20:00:50 +0100, Jörg Schaible wrote:
>>> 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.
>>
>> Obviously!
>>
>> FTR: I'm +1 for a hard dependency on "Commons RNG".
>>
>> The bridge is an alternate solution to satisfy those who (rather
>> mysteriously) would prefer to offer the possibility to use a bad
>> algorithm. ;-)
>>
>>> 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.
>>
>> The modular setup is done once, whereas IIUC, every app developer
>> will be forced to implement his own version of the bridge code.
>> IMO, that's not "user-friendly".
> 
> I've just read
>   
> https://maven.apache.org/guides/introduction/introduction-to-optional-and-excludes-dependencies.html
> 
> IIUC (now), we can provide all the bridges in a non-modular
> component...

That's what I would have done here.

> If you prefer it to a modular setup, that's fine for me too.


Seems overkill to me.

But it's just my opinion.

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