I'm +1 to this change, I would be more than happy to lend my hands to help on this front. pardon me for being quite because some heavy work on my day job.
I don't want to fork this thread to different discussion but I have one simple doubt that rather creating whole new component why don't we just create maven modules within CM ? I understand that release becomes easy with different component and some more other advantages but same can be done within single project. this is obvious question and which you guys might have discussed before but I didn't found it in past mail archives, though I saw a fork of CM made last year and "that" code base is doing exactly what my doubt is. i.e sub-component as maven module. Regards, Amey On Tue, Aug 15, 2017 at 7:56 PM, Gilles <gil...@harfang.homelinux.org> wrote: > Hello. > > [Time for a new episode in our "Ripping CM" series.] > > How about creating "Commons Geometry"? > > The rationale is comprised of the usual suspects: > * Smaller and more focused component, hence: > - Consistent development and maintenance. > - Consistent release schedule, not encumbered by > changes (and endless discussions) in _totally_ > unrelated code. > - Potential for attracting contributors not > interested in maintaining the (growing) backlog > of CM. > * Self-contained: 96.3% of the "o.a.c.math4.geometry" > package have no dependency except: > - 4 classes now in "Commons Numbers". > - 2 methods and 1 constant in "MathUtils". > - CM exceptions. [Creating alternatives for those > will probably be the most time-consuming part of > the porting work.] > > Moreover, none of the code in the "o.a.c.math4.geometry" > package is used by another package of CM. > > A new component would give the "geometry" codes a much > better chance of being (confidently[1]) released, since > CM is "stuck" for the foreseeable future.[2] > > WDYT? > > Gilles > > [1] There seems to be only one issue reported in JIRA > that pertains to "geometry". > [2] 54 issues yet to be fixed before the 4.0 release; > which, at the current rate, would lead to after 2025 > (a very rough guess, I admit). > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > -- --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
