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