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".
Regards,
Gilles
Cheers,
Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
