commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles <gil...@harfang.homelinux.org>
Subject Re: [text] TEXT-36 (Was: [text] 1.0 release progress)
Date Fri, 30 Dec 2016 22:14:50 GMT
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...
If you prefer it to a modular setup, that's fine for me too.

Gilles

>
> Regards,
> Gilles
>
>>
>> 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