On Thu, 11 Aug 2016 21:07:05 +0300, Artem Barger wrote:
How do you differ between core and tools? What should be included in
each? Do you mean to further split up current commons-rng?
Not split the _current_ codebase (which is "core").
If non-core tools (e.g. syntactic sugar like "Stream"s or
utilities like CM "RandomUtils" class) are provided, they should
come in a separate JAR, so that adding new utilities does not
entail releasing a new version of the "core".
Regards,
Gilles
Sounds possible once decided how you'd like to divide it.
Отправлено с iPhone
11 авг. 2016 г., в 20:44, Gilles <gil...@harfang.homelinux.org>
написал(а):
On Thu, 11 Aug 2016 09:02:34 +0300, Artem Barger wrote:
11 авг. 2016 г., в 2:08, Rob Tompkins <chtom...@gmail.com>
написал(а):
I would guess that we would want to be compatible with the oldest
version of Java possible dictated out of necessity. By that I mean
if there's something of considerable substance that a newer version
affords us, then we should upgrade. But that's only really the
thought that runs through my head. I'm not really tied to it.
I think it could make sense to provide support to something similar
to SplittableRandom while releasing a new PRNG components within
commons. Which available from JDK 1.8.
Excerpt from the commit log:
---CUT---
commit ed083eaf22c4c8403660c48bee7945d40edee6d9
Author: Gilles <gil...@harfang.homelinux.org>
Date: Tue Aug 9 19:03:39 2016 +0200
Bumped JDK dependency to Java 6 (due to "Arrays.copyOf").
Unlikely to loose many potential users w.r.t. Java 5.
commit bb0886f84ba23032306c6376987f92ce653f181d
Author: Gilles <er...@apache.org>
Date: Tue Aug 9 16:02:08 2016 +0200
Make codebase Java 5 compatible.
The public API is comprised of 1 enum (with factory methods) and
2 interfaces.
The "internal" classes would not gain tremendously from more
recent programming constructs (cf. changes in this commit).
Additional RNG implementations would be mostly low-level code
(e.g. bit manipulation) also unlikely to be dependent on a modern JDK.
If and when considered, higher level utilities (e.g.
"Stream"-based) could be implemented in another module, with more
stringent requirements.
---CUT---
So, we could readily experiment with a multi-modules project.
I guess that the pom.xml needs further adjustment to generate
several JARs (say "commons-rng-core" and "commons-rng-tools").
First question: is it possible?
Regards,
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
