Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
Subject: Re: [math] Smaller Packages / Artifacts / Dependencies
To: Commons Developers List <dev@commons.apache.org>
References: <563D165B.3080809@gmail.com>
 <49456c0a458b88b2faadb583f4538df1@scarlet.be>
From: Ole Ersoy <ole.ersoy@gmail.com>
Message-ID: <56410BD1.6030502@gmail.com>
Date: Mon, 9 Nov 2015 15:10:41 -0600
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <49456c0a458b88b2faadb583f4538df1@scarlet.be>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit


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