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-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
