On 11/07/2015 04:00 AM, Gilles wrote:
On Fri, 6 Nov 2015 15:06:35 -0600, Ole Ersoy wrote:
If math is broken up into smaller artifacts it will make it easier
for users to upgrade, even if it it breaks compatibility, as well as
speed up the release frequency. So for example:
commons-math-optimization (Or even more granular
commons-math-optimization-lp, commons-math-optimization-ga,
commons-math-optimization-nlp, etc)
commons-math-simulation
commons-math-statistics
commons-math-ai (Neural Networks, ...)
etc.
I also believe that modularity is a worthy goal.
A first step would be to collect some statistics on inter-package
dependencies.
Personally I like modules and repositories that are very small and focused with
as few dependencies as possible. I'm probably in the extreme bulleye of the
circle on this. The reason I like it is because I can read a few usage lines
in the github README.md and go. It's easy to contribute to and minimizes
indirection. For example I think the optimizers are complex enough to warrant
their own module. The distributions probably belong in a single module, etc.
I'm still in the process of getting a demo repository setup, but it will be
along these lines. Once that's done it should make it really simple for
someone to just clone, build, and get to work. It's nice if it's on Maven, but
if the module is tiny, and easy to verify visually, then cloning and building
is a reasonable way to get things done.
There will certainly be a "commons-math-core" containing packages
like "o.a.c.m.util" and "o.a.c.m.exception".
[At some point, releasing separate JARs could also provide us with
indirect feedback on which parts of CM are actually used.]
And the stars on github are a pretty good indicator as well.
Cheers,
- Ole
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
